Date   

[PATCH 1/1] create-pull-request: detect trailing white space

nitin.a.kamble@...
 

From: Nitin A Kamble <nitin.a.kamble@intel.com>

Add logic in the create-pull-request to detect the trailing white space
inserted by patches.

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
---
scripts/create-pull-request | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/scripts/create-pull-request b/scripts/create-pull-request
index 9a8913d..c35c427 100755
--- a/scripts/create-pull-request
+++ b/scripts/create-pull-request
@@ -173,7 +173,6 @@ mkdir $ODIR
# Generate the patches and cover letter
git format-patch -M40 --subject-prefix="$PREFIX" -n -o $ODIR --thread=shallow --cover-letter $RELATIVE_TO..$COMMIT_ID > /dev/null

-
# Customize the cover letter
CL="$ODIR/0000-cover-letter.patch"
PM="$ODIR/pull-msg"
@@ -229,3 +228,15 @@ Review their content, especially the summary mail:
When you are satisfied, you can send them with:
send-pull-request -a -p $ODIR
EOM
+
+# Check the patches for trailing white space
+echo
+egrep -nH -e "^\+\s+$" $ODIR/* > /dev/null
+if [ $? -ne 1 ]; then
+ echo "WARNING: Trailing white space detected at these locations"
+ egrep -nH -e "^\+\s+$" $ODIR/*
+else
+ echo "Note: No trailing white space is detected in these patches :)"
+fi
+
+
--
1.7.3.4


[PATCH 0/1] Misc: detect trailing space in the patches

nitin.a.kamble@...
 

From: Nitin A Kamble <nitin.a.kamble@intel.com>

This commit is for detecting trailing white space in the create-pull-request script.

Thanks,
Nitin

The following changes since commit 381c4b69c7e8b452f4d3de2f8214e6e5f6a9abe7:

sstate.bbclass: fix detection of owners matching sstate files (2012-12-05 15:34:07 +0000)

are available in the git repository at:
git://git.pokylinux.org/poky-contrib nitin/misc
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=nitin/misc

Nitin A Kamble (1):
create-pull-request: detect trailing white space

scripts/create-pull-request | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)

--
1.7.3.4


Re: [PATCH] Fix incompatibility with jre1.6 support for typed HashMap

Zhang, Jessica
 

Hi Ioana,

None of your patches of today apply so there seems to be some rebase issue. Also, I've added headless build support changes for windows BC plugin, so can you rebase against jzhang/windows-build and resubmit the patch series?

Thanks,
Jessica

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Ioana Grigoropol
Sent: Wednesday, December 05, 2012 2:41 AM
To: yocto@yoctoproject.org
Subject: [yocto] [PATCH] Fix incompatibility with jre1.6 support for typed HashMap

Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@intel.com>
---
.../remote/utils/YoctoHostShellProcessAdapter.java | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShellProcessAdapter.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShellProcessAdapter.java
index 9ab43cf..2dba0a6 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShellProcessAdapter.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShe
+++ llProcessAdapter.java
@@ -34,6 +34,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {

private Semaphore sem;

+
public YoctoHostShellProcessAdapter(IHostShell hostShell, ProcessStreamBuffer processStreamBuffer, CommandResponseHandler commandResponseHandler) throws IOException {
super(hostShell);
this.processStreamBuffer = processStreamBuffer; @@ -41,7 +42,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {
this.calculator = new GitCalculatePercentage();
this.sem = new Semaphore(1);
this.command = "";
- this.commandMonitors = new HashMap<>();
+ this.commandMonitors = new HashMap<String, IProgressMonitor>();
}

public String getLastCommand() {
@@ -50,7 +51,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {

public synchronized void setLastCommand(String lastCommand) {
try {
- // there are still some processes that might take a long time and if we do not wait for them,
+ // there are still some processes that might take a long time and if
+we do not wait for them,
// then the semaphore will not be released, because an interrupted exception will occur
Thread.sleep(2000);
isFinished = false;
@@ -70,6 +71,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {

private class GitCalculatePercentage implements ICalculatePercentage {
final Pattern pattern = Pattern.compile("^Receiving objects:\\s*(\\d+)%.*");
+ @Override
public float calWorkloadDone(String info) throws IllegalArgumentException {
Matcher m = pattern.matcher(info.trim());
if(m.matches()) {
@@ -88,13 +90,16 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {
}

private void updateMonitor(final int work){
+
Display.getDefault().asyncExec(new Runnable() {
+
@Override
public void run() {
if (getMonitor() != null) {
getMonitor().worked(work);
}
}
+
});
}

@@ -124,7 +129,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {
updateMonitor(delta);
reportedWorkload += delta;
}
-
+
if (reportedWorkload == RemoteHelper.TOTALWORKLOAD)
doneMonitor();
}
@@ -152,8 +157,9 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {
continue;
}
setCommandPrompt(value);
+
if (commandPrompt != null && endChar != null && command != null && processStreamBuffer != null &&
- value.startsWith(commandPrompt) && value.endsWith(endChar) &&
+ value.startsWith(commandPrompt) && value.endsWith(endChar) &&
!value.endsWith(command) && processStreamBuffer.getLastOutputLineContaining(command) != null /*&& waitForOutput*/) {
sem.release();
isFinished = true;
@@ -165,7 +171,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {
this.commandResponseHandler.response(value, false);
}
}
-
+
}
private void setCommandPrompt(String value) {
if (commandPrompt == null) {
@@ -178,7 +184,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {
commandPrompt = value.substring(0, end);
endChar = PROMPT_USER_CH;
}
-
+
}
}
public boolean isFinished() {
--
1.7.9.5

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


Re: Need for offline binary configuration

Mark Hatle <mark.hatle@...>
 

On 11/29/12 5:09 AM, Venkata ramana gollamudi wrote:
Added few more thoughts
Looking for possible options to implement Offline Configuration Tool requirement. please check and comment on it.

Configuration flow:

a) Task do_createconfig will generate data to configure. This serves as input for configuration UI in OCT.
Using tasks to control the configuration elements will require the build system and recipes. This is really good for the existing workflow, but doesn't help with the blessed binaries situation.

What I'd love to see (but don't expect) is a way for the binary packages to document he configuration files and options in a way that the UI can load this information, give the user simple check-box/drop down style configuration -- or simply a text editor with the end result something that gets back to the target environment.

b) OCT UI will read that config data(from step(a)) to show it in GUI. User configures using GUI inputs. Stores the user OCT configuration to OCT config file. (Note user can directly modify the OCT config file, if User is familier with it)

c) preinst, postinst, prerm, postrm, or a do_applyconfig(without bb files reparse), can read OCT config file content (using a library) and apply necessary changes.
I'm not sure pre/post is the right place to do these changes. Typically I've seen the default configuration files marked as such within the package system and then the modifications are made externally. Sometimes they're made in ancillary packages or just made raw on the disk. Most package management systems I'm aware of can handle this just fine.

My concern with modifying the defaults is that the feed become project specific, and again it requires input during the build process as opposed to the install process.

Now we can look into possibility of using a specific configuration UI implementation or a generic configuration model or combination of both.

1) Using a specific configuration GUI implementation:
do_createconfig generates the configuration information, in format like datafile/xml and OCT reads this config data and provides a GUI to modify or configure the features.

Pros: Detailed and complex GUIs can be supported which will be user friendly. Ex: User management, network management etc.
Cons: As UI is static, it has to be modified to support new configuration requirements
and UI modifications are generally complex.
Having something like a do_createconfig (or even a do_describeconfig) to generate a file that is later made available to the UI tool is my suggestion. Then the input/output of the tool ends up in the rootfs directly. (The methods to get to the rootfs should be either a specific path, a URL for get/put operations, or a method like tcf/ssh to copy the item to a running target.

Either a custom per-package model or a generic model may be needed. I don't know what the best approach is -- however I know previous attempts to do this have generally resulted in more 'custom' model then generic + config file model.

But in general there seem to be three main types of configuration files that I've seen:

Column/format based -- i.e. /etc/fstab, /etc/exports
Key/Value based -- things like Key=Value, or Key:\nValue, etc..
XML-like -- Highly formatted configuration files like apache.

--Mark

2) A generic configuration model
do_createconfig generates configuration information with presentation information included (like kconfig) and OCT reads this config information and provides a generic UI implementation to modify or config the data like menuconfig.

Pros:
- Generic and dynamic UI allowing the config menus to be added from poky layers providing platform for configuration.
- New features can add new menus configuration options. Feature/package enable and disable can control the configurtion menus.
- So configuration is shown only if feature/package is present/selected.
Cons:
- Generic method of implementing can be complex, specifically for features where configuration is complex ex: User management, network configuration.
- Custom or specific UI will be more user friendly and gives more control to UI designer.

3) Combination of both
Complex features requiring more UI control can implement those features using the method(1) and also providing the plaform for generic UI implementation.
OCT displays both UI configurations.
Ex: Static Image level features like User management, network config can be implemented using method(1)
Service configuration, file system type, hist size configure etc can be implemented using method(2).

Pros: Gives control to project to select the Complex and simple UIs.

Cons: Still needs a OCT UI change if method(1) feature need to be changed.
Drawing a line between complex and simple UI features may not very straight forward.
Adding dynamic Complex UI is not possible to be added from poky layers.

Decision to provide a generic configuration model is mainly based on how much we expect the configuration area to grow along with layers.
Image level features like user management, network management generally are not dynamic features, so having a specific/custom UI implementation looks fine for such features.

Regards,
Ramana


Re: Need for offline binary configuration

Mark Hatle <mark.hatle@...>
 

My apologies for the late response. See below, I'll follow up on your second email as well...

On 11/20/12 9:09 AM, Venkata ramana gollamudi wrote:
Poky allows to build custom Linux for you, but we have cases where the post
build customization is required, like user-addition, network configuration,
service control. Even selecting the required packages can be a post build activity.
One of the objectives that we are currently working toward is being able to start with the package feed (doesn't matter if it's rpm, deb or ipk files), generate a rootfs, configure the rootfs and then deploy the rootfs into an image.

The above should be able to be done on both a cross-configured environment or on the target via a traditional installer like mechanism.

The current model requires the image to be rebuilt to support these configuration.
The current model can avoid many of the tasks associated with the build by using sstate-cache, but I agree that is not optimal for users who want to start with a known set of binaries and then tailor from that point. (This includes users expecting a more traditional Linux install experience or users who need immutable software from an upstream vendor.)

Offline Configuration tool (OCT), which allows a binary image customization
before making a final target image. This case will be more evident in larger
companies, where platform teams, product teams , application teams are
distributed and Linux build from source will be owned and lab tested by a single
team, like platform team. Other teams just configure to use it for product
variants from same platform build.
This was factored into the work we are doing. I know many companies have an outside OSV that provides the build environment, support, etc.. and they feed into an Operating Systems group (or similar). This group then prepares the software according to the corporate guidelines (license restrictions, quality assurance, etc) and repackages it for consumption by others in the organization. Often time the output of the Operating System group is either a blessed source based system -- or a set of binaries that are blessed as being in conformance with that companies guidelines. This process repeats through the platform group and even individual projects -- with the eventual output being a product image including the blessed binaries, custom applications and configurations -- and a matching SDK.

Detailed use cases can be found in enhancement bug:3252

OCT should work on the binary pool of compiled packages generated from poky.

The basic operations that can be supported includes
For the next section, I'm going to assume the pool of binary packages is what we refer to as the package feeds in OpenEmbedded. This is simple a collection of binary packages that have been built from the build system that can be used to construct the rootfs. Each package feed is constructed based on a single "distribution" configuration file which sets the policies for the packages in the feed and distribution wide options, such as selinux, pam, etc.

a) Select/deselect required packages from pool of binary packages into final target image.
The above is definitely considered in the work we've been talking about. This will require software that will take a list of the available items in the feed, present the user/developer with a way to enable the components they want on the target. (Note, there is an inherit requirement here that dependencies also be met, so things the user/developer may not have selected will either have to be installed to meet dependencies or will have to generate an error that dependencies can't be met.)

b) Provision to select external binary packages like ADT compiled applications as input and add them to final target image.
As long as the external package is in the same format as the rest of the feeds, this should be easy to do. And I certainly expect that it will be needed.

c) Binary level Offline configuration can includes
Configure the users/passwords
Configure the network
Configure the host name
Select the services to be started by default
The above are things we've talked about, but I don't believe there have been any formal plans to implement them at this time. The components necessary for the binary package based install -> rootfs generation have taken up most of our planning time at this point.

One thing I would love to see is a set of standard components (or a framework) that could be used for this type of configuration. But I believe it's very important that the configuration work both within the OpenEmbedded environment and externally in the "installer" like environment.

Security related configuration
This is something that I don't believe has really been addressed at all, but like the above we need a way to implement it.

Generate initrd in ramfs/ext3/... format
etc..
We are already considering how to go from rootfs to deployable image. initrd just happens to be one of many potential image types. We've specified hard disk image (partition map, bootloader, individual partitions that comprise one or more rootfs). A flash based image -- instruction for flashing, and individual flash 'partitions' that will work similarly to the hard drive. A CD/DVD/USB based bootable system. And finally as a component of these an initrd rootfs that can be used as a component of the others are separately to instantiate the system before handing off control to one of the other types.

We have a huge advantage in OE that we can generate multiple rootfses from a given distribution configuration, we just don't currently have the tooling to put those rootfses together into the various images. I know Darren Hart at Intel is working on some of the ground work for the hard disk style images.

Considering the methods to support these in our current yocto model, following changes can be done.
The first thing we would like to see is a -single- rootfs creation model for all of the modes. Build system, cross-install, and target-based-install. The way that I'm approaching this right now is by attempting to abstract out just the rootfs generation capabilities within the current build system. The intention is that you will be able to access interfaces to get a list of whats available to be installed, (what may be already installed,) a way to pass what to install and where to the environment. Then the same code will be executed to perform these actions. The actions will be designed to be package type agnostic as well.

Early R&D work is going on there, just to see if I can come up with something reasonable.

1) HOB can be the tool which can be extended to support these
Poky can generate a binary package pool as one if its output and Hob can work on this package pool to select packages, configure and generate image.
So HOB can support opening HOB in Binary(or OCT) mode i.e., without build options but only with binary package selection. Configuration GUI needs to be added to HOB.
Note:HOB+OCT is together or separate, needs a bit more thought and overall organization as they will be intended for different users.
I'm not sure HOB itself is the right tool for this, but there are certainly facets of HOB that would be needed in this kind of tool. The package selection, etc.

2) Binary package pool can be a minimal/partial sstate-cache, as complete sstate-cache is quite big and not required for product teams as they are not expected to build but just need to select and configure.
I think it is sufficient to keep the minimal binaries from sstate-cache which are required to execute image.bbclass, do_rootfs task to generate image.
There are multiple steps of binary package pool, each I think are valid. For someone wanting a source based system, with prebuilt binaries that can be locally modified -- sstate-cache is by far the best way to do this. For an applications group that needs to generate images and SDKs, but is never allowed to use anything but the corporate blessed binary packages, a different mechanism (package based) is likely what is needed. There is a lot of area though where either method may be needed (or desired).

My experience shows people familiar with traditional workstation based systems prefer the binary RPM approach, while hard-core embedded developers prefer source based systems. The reality is the world has fewer hard-code embedded developers and more folks used to the traditional environments, add to that the capabilities of today's embedded systems and it makes sense for a lot of people to start with blessed binaries, tailored for embedded systems, and simple add their integration of applications and configurations after.

3) Along with specific configuration UI implementation, a generic configuration model similar to kernel kconfig and menuconfig can be considered, in cases where more detailed offline configurations is required like detailed security configuration.
This is absolutely need, but I think we need to get the general rootfs generation working and figured out before we spend too much time on this. However, if this is a high priority for you, it may make sense to start working on configuration. This is something that is definitely needed, and I don't believe anyone is actively working on.

--Mark

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


Re: problems adding extra packages

Jim Abernathy
 

On 12/05/2012 03:28 PM, Martin Jansa wrote:
On Wed, Dec 05, 2012 at 03:25:52PM -0500, Jim Abernathy wrote:
In the past on denzil, I'd get images working then start adding specific
packages like this:

LICENSE_FLAGS_WHITELIST = "commercial"
CORE_IMAGE_EXTRA_INSTALL ?= "gst-fluendo-mp3"
CORE_IMAGE_EXTRA_INSTALL ?= "web-webkit"
CORE_IMAGE_EXTRA_INSTALL ?= "myvideos"
CORE_IMAGE_EXTRA_INSTALL ?= "myaudios"
did you use '+=' before?

Cheers,
You'd think by now, my keyboard would know to put the + and not the ?. :-)

Thanks for spotting that. I looked right past it.

Jim A

Today, I got chiefriver bsp working on my hardware and then wanted to
add my video and audio files into the image along with extra software.
It didn't get added and the image is basically the same size. No errors
on just bitbaking again. I was trying to avoid deleting tmp and
starting over again. Has something changed with Danny?

Along with the CORE_IMAGE_EXTRA_INSTALL additions, I added my layer in
bblayer.conf to pick up myvideos, etc.

Jim A

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


Re: problems adding extra packages

Martin Jansa
 

On Wed, Dec 05, 2012 at 03:25:52PM -0500, Jim Abernathy wrote:
In the past on denzil, I'd get images working then start adding specific
packages like this:

LICENSE_FLAGS_WHITELIST = "commercial"
CORE_IMAGE_EXTRA_INSTALL ?= "gst-fluendo-mp3"
CORE_IMAGE_EXTRA_INSTALL ?= "web-webkit"
CORE_IMAGE_EXTRA_INSTALL ?= "myvideos"
CORE_IMAGE_EXTRA_INSTALL ?= "myaudios"
did you use '+=' before?

Cheers,

Today, I got chiefriver bsp working on my hardware and then wanted to
add my video and audio files into the image along with extra software.
It didn't get added and the image is basically the same size. No errors
on just bitbaking again. I was trying to avoid deleting tmp and
starting over again. Has something changed with Danny?

Along with the CORE_IMAGE_EXTRA_INSTALL additions, I added my layer in
bblayer.conf to pick up myvideos, etc.

Jim A

_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com


problems adding extra packages

Jim Abernathy
 

In the past on denzil, I'd get images working then start adding specific packages like this:

LICENSE_FLAGS_WHITELIST = "commercial"
CORE_IMAGE_EXTRA_INSTALL ?= "gst-fluendo-mp3"
CORE_IMAGE_EXTRA_INSTALL ?= "web-webkit"
CORE_IMAGE_EXTRA_INSTALL ?= "myvideos"
CORE_IMAGE_EXTRA_INSTALL ?= "myaudios"

Today, I got chiefriver bsp working on my hardware and then wanted to add my video and audio files into the image along with extra software. It didn't get added and the image is basically the same size. No errors on just bitbaking again. I was trying to avoid deleting tmp and starting over again. Has something changed with Danny?

Along with the CORE_IMAGE_EXTRA_INSTALL additions, I added my layer in bblayer.conf to pick up myvideos, etc.

Jim A


FW: Yocto Project 1.4 M1 release readiness meeting

Liu, Song <song.liu@...>
 

When: Thursday, December 06, 2012 8:30 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).
Where: Bridge Info Enclosed
 
Note: The GMT offset above does not reflect daylight saving time adjustments.
 
*~*~*~*~*~*~*~*~*~*
 
 
 
-----Original Appointment-----

From: Liu, Song
Sent: Wednesday, December 05, 2012 11:38 AM
To: 'Anders Darander'; Barros Pena, Belen; Bodke, Kishore K; 'Bruce Ashfield'; 'Daniel Cauchy'; 'deVries, Alex'; 'Dixon, Brad'; Dmytriyenko, Denys; Erway, Tracey M; Flanagan, Elizabeth; Hart, Darren; 'Hatle, Mark'; 'Jeremy Puhlman'; Kridner, Jason; 'Lieu.Ta@...'; Lock, Joshua; 'McCombe, Kevin'; Moeller, Thorsten; 'Sanjay Raina'; Osier-mixon, Jeffrey; 'Polk, Jeffrey'; Purdie, Richard; 'Ranslam, Rob'; Saxena, Rahul; Stewart, David C; Wold, Saul; Zanussi, Tom; Zhang, Jessica; Rifenbark, Scott M; 'Hudson, Sean'; Serban, Laurentiu; Petrisor, Ileana; Damian, Alexandru; Burton, Ross; Mueller, Robert; Arce Moreno, Abraham; 'Ravi Vompolu'; 'Sadiq, Irfan'; Santana Lopez, Mario A; Calles Palacios, Osvaldo; Patel, Keyur R; 'achaudha@...'; Popa, Valentin; Moses, Fred; Iorga, Cristian; SSD-OTC Romania Yocto QA; Palalau, AlexandruX; 'Butler, Paul'; Mirea, Viorel; Kamble, Nitin A; Szankin, Maciej; Moisan, Radu; Grigoropol, IoanaX
Subject: Yocto Project 1.4 M1 release readiness meeting
When: Thursday, December 06, 2012 8:30 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).
Where: Bridge Info Enclosed
 
 
 
 
Thursday, December 06, 2012, 08:30 AM US Pacific Time
916-356-2663, 8-356-2663, Bridge: 3, Passcode: 8458650
Speed dialer: inteldialer://3,8458650 | Learn more
 


Re: sysroot for use with GDB

Mark Hatle <mark.hatle@...>
 

On 12/5/12 6:38 AM, Wolfgang Denk wrote:
Hello,

nobody here who could help out?

In message <20121203124234.6327B200FF8@gemini.denx.de> I wrote:

according to the documentation [1] the right way to debug applications
on the target is to load the target library information in GDB using

set solib-absolute-prefix /path/to/tmp/rootfs

i. e. referring it to the libraries in the target root file system
image. Assuming the target root file system uses by defualt stripped
libraries, we need to set up a copy of the rootfs with debug
information included.

But do we really have to? Why cannot we use the libraries present in
the SDK's sysroot directory (i. e. what OECORE_TARGET_SYSROOT points
to) ?
It appears that documentation and code are inconsistent; at least the
eclipse plugin generates a .gdbinit script which contains a

set sysroot /opt/poky/1.3/sysroots/armv7a-vfp-neon-poky-linux-gnueabi

statement, i. e. it uses OECORE_TARGET_SYSROOT as I thought should
work - but it doesn't.

Trying to do so, we see that it fails. Our current suspicion is that
maybe prelinking of the target images and libraries introduces some
incompatibility. Is this a reasonable assumption, and if so, is this
a problem that should be fixed, or unavoidable for some reason? Or is
there a problem with the libraries in OECORE_TARGET_SYSROOT ?
Prelinking should not cause a problem. GDB knows how to translate the debuginfo addresses to the end runtime addresses.

The only thing I've seen in the past that has caused a problem is when the dbg stuff was not installed into the sysroot. GDB will fall back into loading the binaries from the sysroot, which will not contain the debug info causing problems.

It's best if you can set the sysroot to the same filesystem as being executed, but if you can't this is reasonable.

All help welcome - thanks in advance.

[1] http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#platdev-gdb-remotedebug-launch-gdb
OK, guess I should enter a bug in bugzilla, then?


Best regards,

Wolfgang Denk


Re: mail list for Xilinx Zynq platform?

Philip Balister
 

On 12/05/2012 10:30 AM, Bruce Ashfield wrote:
On 12-12-05 01:15 PM, Philip Balister wrote:
On 12/05/2012 06:46 AM, Bruce Ashfield wrote:
On 12-12-05 09:42 AM, Elvis Dowson wrote:
...


Thanks! Should we go ahead and set the list up so interested parties can
start coordinating our existing work?
I'm good with that. It's no big commitment to anything in particular
to have list available, and hopefully it'll serve to draw the right
folks into the conversation.
Micheal, can you set up a mailing list "mete-zynq" for us? Also, please add this to gmane for people that prefer to read via nntp.

Thanks,

Philip


Cheers,

Bruce


Philip


Cheers,

Bruce


Also, try to ensure that you don't put both the meta-layers in your
bblayers.conf file
while building, and ensure that you set machine as follows in your
local.conf file

MACHINE ?= "zynq-zc702"

Do let me know how it goes!

Best regards,

Elvis Dowson
_______________________________________________
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: mail list for Xilinx Zynq platform?

Bruce Ashfield <bruce.ashfield@...>
 

On 12-12-05 01:15 PM, Philip Balister wrote:
On 12/05/2012 06:46 AM, Bruce Ashfield wrote:
On 12-12-05 09:42 AM, Elvis Dowson wrote:
Hi,

On Dec 5, 2012, at 5:21 PM, Andreas Schweigstill
<andreas@schweigstill.de> wrote:

I have also tried to build a kernel and root filesystem for Zynq but
the kernel
gets stuck when booting, regardless if on the ZC702 board or on Qemu.
I tried
Poky denzil and Poky danny.

Also the alternate meta-zynq layer from git.yoctoproject.org shows
the same
behaviour.

These are the last console messages which I get:
## Booting kernel from Legacy Image at 01000000 ...
Image Name: Linux-3.2.11-yocto-standard
Created: 2012-12-04 20:07:37 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2997472 Bytes = 2.9 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 01a80000
Booting using the fdt blob at 0x1a80000
Loading Device Tree to 0eff8000, end 0efff185 ... OK
Loading Kernel Image ... OK
OK
Loading Device Tree to 0efed000, end 0eff7185 ... OK

Starting kernel ...


Instead of using Linux kernel version 3.5-xilinx I always get
Linux-3.2.11-yocto-standard which is obviously missing the
Zynq patches.

meta-zynq/recipes-kernel-linux-zynq contains the following lines:
LINUX_VERSION ?= "3.5"
LINUX_VERSION_EXTENSION ?= "-xilinx"

How can I force Yocto to build kernel 3.5-xilinx?
From you messages, I infer that you are using the meta-zynq layer
located here:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/

For my builds, I used Philip Ballister's meta-zynq layer located here
for the simple reason that it uses xilinx git repository:

https://github.com/balister/meta-zynq
And in case anyone is wondering, efforts are (still) underway to
get a single unified layer for this board (and others), but getting
all the moving parts organized is taking a bit longer than expected
or than we would like.
Thanks! Should we go ahead and set the list up so interested parties can
start coordinating our existing work?
I'm good with that. It's no big commitment to anything in particular
to have list available, and hopefully it'll serve to draw the right
folks into the conversation.

Cheers,

Bruce


Philip


Cheers,

Bruce


Also, try to ensure that you don't put both the meta-layers in your
bblayers.conf file
while building, and ensure that you set machine as follows in your
local.conf file

MACHINE ?= "zynq-zc702"

Do let me know how it goes!

Best regards,

Elvis Dowson
_______________________________________________
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: mail list for Xilinx Zynq platform?

Philip Balister
 

On 12/05/2012 05:21 AM, Andreas Schweigstill wrote:
Hello!

I personally have used Philip's meta-zynq layer to build a working u-boot and
linux kernel image using Yocto. It works really well.
I have also tried to build a kernel and root filesystem for Zynq but the kernel
gets stuck when booting, regardless if on the ZC702 board or on Qemu. I tried
Poky denzil and Poky danny.
Also, try these instructions. Note they do not use the meta-yocto shim layer (sorry, my customer has been taunting me again).

I feel like the meta-yocto layer is "forcing" the use of "standard" kernels.

Philip


Also the alternate meta-zynq layer from git.yoctoproject.org shows the same
behaviour.

These are the last console messages which I get:
## Booting kernel from Legacy Image at 01000000 ...
Image Name: Linux-3.2.11-yocto-standard
Created: 2012-12-04 20:07:37 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2997472 Bytes = 2.9 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 01a80000
Booting using the fdt blob at 0x1a80000
Loading Device Tree to 0eff8000, end 0efff185 ... OK
Loading Kernel Image ... OK
OK
Loading Device Tree to 0efed000, end 0eff7185 ... OK

Starting kernel ...


Instead of using Linux kernel version 3.5-xilinx I always get
Linux-3.2.11-yocto-standard which is obviously missing the
Zynq patches.

meta-zynq/recipes-kernel-linux-zynq contains the following lines:
LINUX_VERSION ?= "3.5"
LINUX_VERSION_EXTENSION ?= "-xilinx"

How can I force Yocto to build kernel 3.5-xilinx?

With best regards,
Andreas Schweigstill

​--
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstraße 116, D-24118 Kiel, Germany
Phone: (+49) 431 530354-35, Fax: (+49) 431 530354-36
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: mail list for Xilinx Zynq platform?

Philip Balister
 

On 12/05/2012 05:21 AM, Andreas Schweigstill wrote:
Hello!

I personally have used Philip's meta-zynq layer to build a working u-boot and
linux kernel image using Yocto. It works really well.
I have also tried to build a kernel and root filesystem for Zynq but the kernel
gets stuck when booting, regardless if on the ZC702 board or on Qemu. I tried
Poky denzil and Poky danny.

Also the alternate meta-zynq layer from git.yoctoproject.org shows the same
behaviour.

These are the last console messages which I get:
## Booting kernel from Legacy Image at 01000000 ...
Image Name: Linux-3.2.11-yocto-standard
Created: 2012-12-04 20:07:37 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2997472 Bytes = 2.9 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 01a80000
Booting using the fdt blob at 0x1a80000
Loading Device Tree to 0eff8000, end 0efff185 ... OK
Loading Kernel Image ... OK
OK
Loading Device Tree to 0efed000, end 0eff7185 ... OK

Starting kernel ...


Instead of using Linux kernel version 3.5-xilinx I always get
Linux-3.2.11-yocto-standard which is obviously missing the
Zynq patches.

meta-zynq/recipes-kernel-linux-zynq contains the following lines:
LINUX_VERSION ?= "3.5"
LINUX_VERSION_EXTENSION ?= "-xilinx"

How can I force Yocto to build kernel 3.5-xilinx?
Urg, I'll have to take a look at that.

Also, you'll need an updated fsbl in the BOOT.BIN file to work with the later kernels. We should probably post one somewhere, although I wish the fsbl license was a little less restrictive.

Philip



With best regards,
Andreas Schweigstill

​--
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstraße 116, D-24118 Kiel, Germany
Phone: (+49) 431 530354-35, Fax: (+49) 431 530354-36
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: mail list for Xilinx Zynq platform?

Philip Balister
 

On 12/05/2012 06:46 AM, Bruce Ashfield wrote:
On 12-12-05 09:42 AM, Elvis Dowson wrote:
Hi,

On Dec 5, 2012, at 5:21 PM, Andreas Schweigstill
<andreas@schweigstill.de> wrote:

I have also tried to build a kernel and root filesystem for Zynq but
the kernel
gets stuck when booting, regardless if on the ZC702 board or on Qemu.
I tried
Poky denzil and Poky danny.

Also the alternate meta-zynq layer from git.yoctoproject.org shows
the same
behaviour.

These are the last console messages which I get:
## Booting kernel from Legacy Image at 01000000 ...
Image Name: Linux-3.2.11-yocto-standard
Created: 2012-12-04 20:07:37 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2997472 Bytes = 2.9 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 01a80000
Booting using the fdt blob at 0x1a80000
Loading Device Tree to 0eff8000, end 0efff185 ... OK
Loading Kernel Image ... OK
OK
Loading Device Tree to 0efed000, end 0eff7185 ... OK

Starting kernel ...


Instead of using Linux kernel version 3.5-xilinx I always get
Linux-3.2.11-yocto-standard which is obviously missing the
Zynq patches.

meta-zynq/recipes-kernel-linux-zynq contains the following lines:
LINUX_VERSION ?= "3.5"
LINUX_VERSION_EXTENSION ?= "-xilinx"

How can I force Yocto to build kernel 3.5-xilinx?
From you messages, I infer that you are using the meta-zynq layer
located here:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/

For my builds, I used Philip Ballister's meta-zynq layer located here
for the simple reason that it uses xilinx git repository:

https://github.com/balister/meta-zynq
And in case anyone is wondering, efforts are (still) underway to
get a single unified layer for this board (and others), but getting
all the moving parts organized is taking a bit longer than expected
or than we would like.
Thanks! Should we go ahead and set the list up so interested parties can start coordinating our existing work?

Philip


Cheers,

Bruce


Also, try to ensure that you don't put both the meta-layers in your
bblayers.conf file
while building, and ensure that you set machine as follows in your
local.conf file

MACHINE ?= "zynq-zc702"

Do let me know how it goes!

Best regards,

Elvis Dowson
_______________________________________________
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: [meta-baryon][PATCH 1/1] proftpd: conditionally remove /usr/libexec

Paul Eggleton
 

On Monday 03 December 2012 15:22:42 Kevin Strasser wrote:
As of poky commit id 1d18224b24a515a07170ce36dbd725cb203d3300
libexecdir has been changed to ${libdir}/${BPN} which is typically
/usr/lib. This change introduces a check to see if /usr/libexec is
being used before attempting to remove it.

Fixes [YOCTO #3504]

Signed-off-by: Kevin Strasser <kevin.strasser@linux.intel.com>
---
recipes-extended/proftpd/proftpd_1.3.4b.bb | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/recipes-extended/proftpd/proftpd_1.3.4b.bb
b/recipes-extended/proftpd/proftpd_1.3.4b.bb index 8ebafbf..2b2b4e2 100644
--- a/recipes-extended/proftpd/proftpd_1.3.4b.bb
+++ b/recipes-extended/proftpd/proftpd_1.3.4b.bb
@@ -34,7 +34,10 @@ FTPGROUP = "ftp"

do_install () {
oe_runmake DESTDIR=${D} install
- rmdir ${D}${libexecdir} ${D}${libdir}/proftpd ${D}${datadir}/locale
+ rmdir ${D}${libdir}/proftpd ${D}${datadir}/locale
+ if [ -d ${D}/usr/libexec ] ; then
+ rmdir ${D}/usr/libexec
+ fi
sed -i '/ *User[ \t]*/s/ftp/${FTPUSER}/' ${D}${sysconfdir}/proftpd.conf
sed -i '/ *Group[ \t]*/s/ftp/${FTPGROUP}/' ${D}${sysconfdir}/proftpd.conf
install -d ${D}${sysconfdir}/init.d
Applied, thanks. I've also sent this over to be applied to meta-networking.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


[PATCH 2/2] Fix synchronous waiting for command prompt in Linux & connection lost when restarting

Ioana Grigoropol <ioanax.grigoropol@...>
 

- when waiting for an command to finish running, we wait to receive a command prompt using the syntax user@host....endChar. This pattern is not always encountered on local or remote connection from linux to linux. Instead echo some terminator value after each command and wait for recieve the value.

- when working on a Linux machine and creating a project using the Local connection, after a restart, the RSE registry fails to find the project's connection using its URI because there is no host set. Manually set the current connection to Localhost

Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@intel.com>
---
.../src/org/yocto/bc/bitbake/BBSession.java | 2 +
.../src/org/yocto/bc/bitbake/ShellSession.java | 24 ++----
.../yocto/bc/remote/utils/ProcessStreamBuffer.java | 14 ++--
.../org/yocto/bc/remote/utils/RemoteHelper.java | 14 ++--
.../remote/utils/YoctoHostShellProcessAdapter.java | 28 +------
.../src/org/yocto/bc/ui/Activator.java | 79 ++++++--------------
.../src/org/yocto/bc/ui/model/ProjectInfo.java | 4 +
.../bc/ui/wizards/NewBitBakeFileRecipeWizard.java | 7 +-
.../ui/wizards/NewBitBakeFileRecipeWizardPage.java | 15 ++--
9 files changed, 60 insertions(+), 127 deletions(-)

diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
index c5354a4..3aa4efe 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/BBSession.java
@@ -439,6 +439,8 @@ public class BBSession implements IBBSessionListener, IModelElement, Map {
}

protected void parse(String content, Map outMap) throws Exception {
+ if (content == null)
+ return;
BufferedReader reader = new BufferedReader(new StringReader(content));
String line;
boolean inLine = false;
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ShellSession.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ShellSession.java
index f143bed..c127c25 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ShellSession.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/bitbake/ShellSession.java
@@ -81,24 +81,13 @@ public class ShellSession {
this.projectInfo = pInfo;
this.root = root;
this.initCmd = initCmd;
-// if (out == null) {
-// this.out = new NullWriter();
-// } else {
-// this.out = out;
-// }
-// if (shellType == SHELL_TYPE_SH) {
-// shellPath = "/bin/sh";
-// }
-// shellPath = "/bin/bash";
-
initializeShell(new NullProgressMonitor());
}

private void initializeShell(IProgressMonitor monitor) throws IOException {
try {
- IHost connection = RemoteHelper.getRemoteConnectionByName(projectInfo.getConnection().getName());
- RemoteHelper.runCommandRemote(connection, new YoctoCommand("source " + initCmd, root.getAbsolutePath(), ""));
- RemoteHelper.runCommandRemote(connection, new YoctoCommand(exportCmd, root.getAbsolutePath(), ""));
+ RemoteHelper.runCommandRemote(projectInfo.getConnection(), new YoctoCommand("source " + initCmd, root.getAbsolutePath(), ""));
+ RemoteHelper.runCommandRemote(projectInfo.getConnection(), new YoctoCommand(exportCmd, root.getAbsolutePath(), ""));
} catch (Exception e) {
e.printStackTrace();
}
@@ -113,9 +102,12 @@ public class ShellSession {
public String execute(String command, boolean hasErrors) throws IOException {

try {
- IHost connection = RemoteHelper.getRemoteConnectionByName(projectInfo.getConnection().getName());
- hasErrors = RemoteHelper.runCommandRemote(connection, new YoctoCommand(command, root.getAbsolutePath() + "/build/", ""));
- return RemoteHelper.getProcessBuffer(connection).getMergedOutputLines();
+ if (projectInfo.getConnection() != null) {
+ IHost connection = RemoteHelper.getRemoteConnectionByName(projectInfo.getConnection().getName());
+ hasErrors = RemoteHelper.runCommandRemote(connection, new YoctoCommand(command, root.getAbsolutePath() + "/build/", ""));
+ return RemoteHelper.getProcessBuffer(connection).getMergedOutputLines();
+ }
+ return null;
} catch (Exception e) {
e.printStackTrace();
}
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/ProcessStreamBuffer.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/ProcessStreamBuffer.java
index 438a5b4..2c6d122 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/ProcessStreamBuffer.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/ProcessStreamBuffer.java
@@ -2,6 +2,7 @@ package org.yocto.bc.remote.utils;

import java.util.ArrayList;
import java.util.List;
+import java.util.regex.Pattern;

public class ProcessStreamBuffer {
private static final String WHITESPACES = "\\s+";
@@ -54,17 +55,16 @@ public class ProcessStreamBuffer {
return null;
}

- public String getOutputLineContaining(String str) {
- int index = 0;
+ public String getOutputLineContaining(String arg, String pattern) {
for (int i = outputLines.size() - 1; i >= 0; i--){
String line = outputLines.get(i);
- if (line.contains(str)) {
- index = i + 1;
- break;
+ if (line.contains(arg)) {
+ String[] tokens = line.split("\\s+");
+ if (Pattern.matches(pattern, tokens[0])) {
+ return tokens[0];
+ }
}
}
- if (index >= 0 && index < outputLines.size())
- return outputLines.get(index);
return null;
}
}
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/RemoteHelper.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/RemoteHelper.java
index f375de1..c230fd6 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/RemoteHelper.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/RemoteHelper.java
@@ -45,6 +45,7 @@ import org.yocto.bc.ui.Activator;
import org.yocto.bc.ui.wizards.install.Messages;

public class RemoteHelper {
+ public static final String TERMINATOR = "234o987dsfkcqiuwey18837032843259d";
public static final int TOTALWORKLOAD = 100;
private static Map<IHost, RemoteMachine> machines;

@@ -95,9 +96,11 @@ public class RemoteHelper {
return null;

String host = uri.getHost();
- if (host == null)
- return null;
-
+ if (host == null) {
+ // this is a local connection
+ ISystemRegistry sr = RSECorePlugin.getTheSystemRegistry();
+ return sr.getLocalHost();
+ }
ISystemRegistry sr = RSECorePlugin.getTheSystemRegistry();
IHost[] connections = sr.getHosts();

@@ -259,8 +262,9 @@ public class RemoteHelper {
public void run() {
try {
YoctoHostShellProcessAdapter adapter = getHostShellProcessAdapter(connection);
- adapter.setLastCommand(remoteCommand);
- getHostShell(connection).writeToShell(remoteCommand);
+ String fullRemoteCommand = remoteCommand + "; echo " + TERMINATOR + ";";
+ adapter.setLastCommand(fullRemoteCommand);
+ getHostShell(connection).writeToShell(fullRemoteCommand);
while (!adapter.isFinished())
Thread.sleep(2);
// return hostShellProcessAdapter.hasErrors();
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShellProcessAdapter.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShellProcessAdapter.java
index 2dba0a6..bb137b1 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShellProcessAdapter.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/remote/utils/YoctoHostShellProcessAdapter.java
@@ -17,10 +17,6 @@ import org.eclipse.rse.services.shells.IHostShellOutputReader;
import org.eclipse.swt.widgets.Display;

public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {
- private String commandPrompt = null;
- private static final String ROOT = "root";
- private static final String PROMPT_USER_CH = "$";
- private static final String PROMPT_ROOT_CH = "#";
private ProcessStreamBuffer processStreamBuffer;
private CommandResponseHandler commandResponseHandler;
private boolean isFinished;
@@ -30,7 +26,6 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {

private String command;
private Map<String, IProgressMonitor> commandMonitors;
- private String endChar = null;

private Semaphore sem;

@@ -57,9 +52,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {
isFinished = false;
sem.acquire();
this.command = lastCommand.trim();
- System.out.println("last command " + lastCommand + getOwnMonitor());
this.commandMonitors.put(command, getOwnMonitor());
-
} catch (InterruptedException e) {
e.printStackTrace();
}
@@ -145,7 +138,6 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {
if (value.isEmpty()) {
continue;
}
- setCommandPrompt(value);
System.out.println(value);
this.processStreamBuffer.addErrorLine(value);
this.commandResponseHandler.response(value, false);
@@ -156,11 +148,7 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {
if (value.isEmpty()) {
continue;
}
- setCommandPrompt(value);
-
- if (commandPrompt != null && endChar != null && command != null && processStreamBuffer != null &&
- value.startsWith(commandPrompt) && value.endsWith(endChar) &&
- !value.endsWith(command) && processStreamBuffer.getLastOutputLineContaining(command) != null /*&& waitForOutput*/) {
+ if (value.endsWith(RemoteHelper.TERMINATOR)) {
sem.release();
isFinished = true;
}
@@ -173,20 +161,6 @@ public class YoctoHostShellProcessAdapter extends HostShellProcessAdapter {
}

}
- private void setCommandPrompt(String value) {
- if (commandPrompt == null) {
- if (value.startsWith(ROOT) && value.indexOf(PROMPT_ROOT_CH) != -1) {
- int end = value.indexOf(PROMPT_ROOT_CH);
- commandPrompt = value.substring(0, end);
- endChar = PROMPT_ROOT_CH;
- } else if (value.indexOf(PROMPT_USER_CH) != -1) {
- int end = value.indexOf(PROMPT_USER_CH);
- commandPrompt = value.substring(0, end);
- endChar = PROMPT_USER_CH;
- }
-
- }
- }
public boolean isFinished() {
return isFinished;
}
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/Activator.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/Activator.java
index 64ca6a7..48c59d5 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/Activator.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/Activator.java
@@ -24,10 +24,8 @@ import org.eclipse.core.resources.IResourceChangeListener;
import org.eclipse.core.resources.ResourcesPlugin;
import org.eclipse.core.runtime.CoreException;
import org.eclipse.core.runtime.IProgressMonitor;
-import org.eclipse.core.runtime.NullProgressMonitor;
import org.eclipse.jface.resource.ImageDescriptor;
import org.eclipse.jface.resource.ImageRegistry;
-import org.eclipse.rse.core.model.IHost;
import org.eclipse.rse.services.files.IHostFile;
import org.eclipse.ui.plugin.AbstractUIPlugin;
import org.osgi.framework.BundleContext;
@@ -68,7 +66,7 @@ public class Activator extends AbstractUIPlugin {

return recipe;
}
-
+
/**
* Get or create a BitBake session passing in ProjectInfo
* @param pinfo
@@ -80,40 +78,36 @@ public class Activator extends AbstractUIPlugin {
if (bbSessionMap == null) {
bbSessionMap = new Hashtable<URI, BBSession>();
}
-
- BBSession bbs = (BBSession) bbSessionMap.get(projectRoot);
-
+
+ BBSession bbs = bbSessionMap.get(projectRoot);
+
if (bbs == null) {
bbs = new BBSession(getShellSession(projectInfo, out, monitor), projectRoot);
bbSessionMap.put(projectRoot, bbs);
}
-
+
return bbs;
}
-
+
/**
* Get or create a BitBake session passing in ProjectInfo
* @param pinfo
* @return
- * @throws Exception
+ * @throws Exception
*/
public static BBSession getBBSession(ProjectInfo projectInfo, IProgressMonitor monitor) throws Exception {
URI projectRoot = projectInfo.getURI();
if (bbSessionMap == null) {
bbSessionMap = new Hashtable<URI, BBSession>();
}
-
- BBSession bbs = (BBSession) bbSessionMap.get(projectRoot);
-
+
+ BBSession bbs = bbSessionMap.get(projectRoot);
+
if (bbs == null) {
bbs = new BBSession(getShellSession(projectInfo, null, monitor), projectRoot);
bbSessionMap.put(projectRoot, bbs);
- } else {
- if (projectInfo.getConnection() == null) {
- throw new Exception("The remote connection is null!");
- }
}
-
+
return bbs;
}

@@ -141,9 +135,7 @@ public class Activator extends AbstractUIPlugin {
if (projInfoMap == null) {
projInfoMap = new Hashtable<URI, ProjectInfo>();
}
-
- ProjectInfo pi = (ProjectInfo) projInfoMap.get(location);
-
+ ProjectInfo pi = projInfoMap.get(location);
if (pi == null) {
pi = new ProjectInfo();
pi.setLocation(location);
@@ -152,13 +144,10 @@ public class Activator extends AbstractUIPlugin {
} catch (IOException e) {
throw new InvocationTargetException(e);
}
- if (pi.getConnection() == null) {
- IHost connection = RemoteHelper.getRemoteConnectionForURI(location, new NullProgressMonitor());
- pi.setConnection(connection);
- }
+
projInfoMap.put(location, pi);
}
-
+
return pi;
}

@@ -175,7 +164,7 @@ public class Activator extends AbstractUIPlugin {
if(bbSessionMap != null) {
iter= bbSessionMap.values().iterator();
while(iter.hasNext()) {
- BBSession p = (BBSession)iter.next();
+ BBSession p = iter.next();
p.changeNotified(added, removed, changed);
}
}
@@ -184,56 +173,31 @@ public class Activator extends AbstractUIPlugin {
/**
* @param absolutePath
* @return a cached shell session for a given project root.
- * @throws IOException
+ * @throws IOException
*/
private static ShellSession getShellSession(ProjectInfo projInfo, Writer out, IProgressMonitor monitor) throws IOException {
URI absolutePath = projInfo.getURI();
if (shellMap == null) {
shellMap = new Hashtable<String, ShellSession>();
}
-
- ShellSession ss = (ShellSession) shellMap.get(absolutePath);
-
+
+ ShellSession ss = shellMap.get(absolutePath);
+
if (ss == null) {
-// if (conn == null)
-// RemoteHelper.getRemoteConnectionByName();
IHostFile remoteHostFile = RemoteHelper.getRemoteHostFile(projInfo.getConnection(), absolutePath.getPath(), monitor);
ss = new ShellSession(projInfo, ShellSession.SHELL_TYPE_BASH, remoteHostFile, ProjectInfoHelper.getInitScriptPath(absolutePath), out);
}
-
+
return ss;
}

-// private static String loadInit(String absolutePath) throws CoreException {
-// IProject [] prjs = ResourcesPlugin.getWorkspace().getRoot().getProjects();
-// IProject foundPrj = null;
-//
-// for (int i = 0; i < prjs.length; ++i) {
-// IProject p = prjs[i];
-//
-// System.out
-// .println(p.getDescription().getLocationURI().getPath());
-//
-// if (p.getDescription().getLocationURI().getPath().equals(absolutePath)) {
-// foundPrj = p;
-// break;
-// }
-// }
-//
-// if (foundPrj == null) {
-// throw new RuntimeException("Unable to find project associated with path! " + absolutePath);
-// }
-//
-// return foundPrj.getPersistentProperty(CreateBBCProjectOperation.BBC_PROJECT_INIT);
-// }
-
public static void putProjInfo(URI location, ProjectInfo pinfo) {
if (projInfoMap == null) {
projInfoMap = new Hashtable<URI, ProjectInfo>();
}
projInfoMap.put(location, pinfo);
}
-
+
/**
* The constructor
*/
@@ -273,6 +237,7 @@ public class Activator extends AbstractUIPlugin {
bbSessionMap.remove(path);
}

+ @Override
protected void initializeImageRegistry(ImageRegistry reg) {
reg.put(IMAGE_VARIABLE, Activator.getImageDescriptor("icons/variable.gif"));
reg.put(IMAGE_FUNCTION, Activator.getImageDescriptor("icons/function.gif"));
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/model/ProjectInfo.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/model/ProjectInfo.java
index 5fc4ba2..4530bb3 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/model/ProjectInfo.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/model/ProjectInfo.java
@@ -13,6 +13,7 @@ package org.yocto.bc.ui.model;
import java.net.URI;

import org.eclipse.core.runtime.IProgressMonitor;
+import org.eclipse.core.runtime.NullProgressMonitor;
import org.eclipse.ptp.remote.core.IRemoteConnection;
import org.eclipse.ptp.remote.core.IRemoteServices;
import org.eclipse.rse.core.model.IHost;
@@ -58,6 +59,9 @@ public class ProjectInfo implements IModelElement {
}

public IHost getConnection() {
+ if (connection == null) {
+ connection = RemoteHelper.getRemoteConnectionForURI(location, new NullProgressMonitor());
+ }
return connection;
}

diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/NewBitBakeFileRecipeWizard.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/NewBitBakeFileRecipeWizard.java
index 57cad18..8457996 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/NewBitBakeFileRecipeWizard.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/NewBitBakeFileRecipeWizard.java
@@ -118,10 +118,7 @@ public class NewBitBakeFileRecipeWizard extends Wizard implements INewWizard {
IProject p = ((IResource)element).getProject();
try {
ProjectInfo projInfo = Activator.getProjInfo(p.getLocationURI());
- if (projInfo.getConnection() == null)
- this.connection = RemoteHelper.getRemoteConnectionForURI(p.getLocationURI(), new NullProgressMonitor());
- else
- this.connection = projInfo.getConnection();
+ this.connection = projInfo.getConnection();
} catch (CoreException e) {
e.printStackTrace();
} catch (InvocationTargetException e) {
@@ -205,7 +202,7 @@ public class NewBitBakeFileRecipeWizard extends Wizard implements INewWizard {
public void run(IProgressMonitor monitor) throws InvocationTargetException {
try {
doFinish(element, monitor);
- RemoteHelper.runCommandRemote(connection, new YoctoCommand("rm -rf temp", element.getMetaDir() + "/temp", ""));
+ RemoteHelper.runCommandRemote(connection, new YoctoCommand("rm -rf " + element.getMetaDir() + "/temp", "", ""));
} catch (Exception e) {
throw new InvocationTargetException(e);
} finally {
diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/NewBitBakeFileRecipeWizardPage.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/NewBitBakeFileRecipeWizardPage.java
index e9dc1f3..a52c2fe 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/NewBitBakeFileRecipeWizardPage.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/NewBitBakeFileRecipeWizardPage.java
@@ -397,22 +397,17 @@ public class NewBitBakeFileRecipeWizardPage extends WizardPage {
updateSrcUri(mirrorTable, srcURI);
populateInheritance(extractDir, monitor);

- String md5Val = retrieveSum(md5YCmd);
+ String md5Val = retrieveSum(srcFileNameExt, md5Pattern);
md5sumText.setText(Pattern.matches(md5Pattern, md5Val) ? md5Val : "");
- String sha256Val = retrieveSum(sha256YCmd);
+ String sha256Val = retrieveSum(srcFileNameExt, sha256Pattern);
sha256sumText.setText(Pattern.matches(sha256Pattern, sha256Val) ? sha256Val : "");
- String checkSumVal = retrieveSum(licenseChecksumCmd);
+ String checkSumVal = retrieveSum(COPYING_FILE, md5Pattern);
checksumText.setText(RemoteHelper.createNewURI(extractDir, COPYING_FILE).toString() + ";md5=" + (Pattern.matches(md5Pattern, checkSumVal) ? checkSumVal : ""));
}

- private String retrieveSum(YoctoCommand cmd) {
+ private String retrieveSum(String arg, String pattern) {
ProcessStreamBuffer buffer = RemoteHelper.getProcessBuffer(this.connection);
- String line = buffer.getOutputLineContaining(cmd.getCommand());
- if (line != null) {
- String[] tokens = line.split(WHITESPACES);
- return tokens[0];
- }
- return "";
+ return buffer.getOutputLineContaining(arg, pattern);
}

private URI extractPackage(URI srcURI) {
--
1.7.9.5


[PATCH 1/2] Remove validation for existing git repository

Ioana Grigoropol <ioanax.grigoropol@...>
 

Signed-off-by: Ioana Grigoropol <ioanax.grigoropol@intel.com>
---
.../yocto/bc/ui/wizards/install/OptionsPage.java | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
index 37c12f8..9e94aea 100644
--- a/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
+++ b/plugins/org.yocto.bc.ui/src/org/yocto/bc/ui/wizards/install/OptionsPage.java
@@ -170,11 +170,11 @@ public class OptionsPage extends FiniteStateWizardPage {
setErrorMessage("Directory " + projectPath + " does not exist, please select git clone.");
return false;
}
- IHostFile gitDescr = RemoteHelper.getRemoteHostFile(connection, projectPath + "/.git", new NullProgressMonitor());
- if (gitDescr == null || !gitDescr.exists()) {
- setErrorMessage("Directory " + projectPath + " does not contain a git repository, please select git clone.");
- return false;
- }
+// IHostFile gitDescr = RemoteHelper.getRemoteHostFile(connection, projectPath + "/.git", new NullProgressMonitor());
+// if (gitDescr == null || !gitDescr.exists()) {
+// setErrorMessage("Directory " + projectPath + " does not contain a git repository, please select git clone.");
+// return false;
+// }

IHostFile validationFile = RemoteHelper.getRemoteHostFile(connection, projectPath + URI_SEPARATOR + InstallWizard.VALIDATION_FILE, new NullProgressMonitor());
if (validationFile == null || !validationFile.exists()) {
--
1.7.9.5


[PATCH 0/2] [eclipse-poky-windows] Fix validation & command running on Linux

Ioana Grigoropol <ioanax.grigoropol@...>
 

- Skip validating an existing git repo and only perform some "sanity" checks
- When waiting for a command to finish executing do not use the command prompt because it can change depending on the target & the connection; instead use a terminator to mark the end of the command execution
- When running from Linux and using a Local connection, after restarting Eclipse RSE does not find the connection - fix it by manually checking for the localhost connection

Ioana Grigoropol (2):
Remove validation for existing git repository
Fix synchronous waiting for command prompt in Linux & connection lost
when restarting

.../src/org/yocto/bc/bitbake/BBSession.java | 2 +
.../src/org/yocto/bc/bitbake/ShellSession.java | 24 ++----
.../yocto/bc/remote/utils/ProcessStreamBuffer.java | 14 ++--
.../org/yocto/bc/remote/utils/RemoteHelper.java | 14 ++--
.../remote/utils/YoctoHostShellProcessAdapter.java | 28 +------
.../src/org/yocto/bc/ui/Activator.java | 79 ++++++--------------
.../src/org/yocto/bc/ui/model/ProjectInfo.java | 4 +
.../bc/ui/wizards/NewBitBakeFileRecipeWizard.java | 7 +-
.../ui/wizards/NewBitBakeFileRecipeWizardPage.java | 15 ++--
.../yocto/bc/ui/wizards/install/OptionsPage.java | 10 +--
10 files changed, 65 insertions(+), 132 deletions(-)

--
1.7.9.5


Re: mail list for Xilinx Zynq platform?

Bruce Ashfield <bruce.ashfield@...>
 

On 12-12-05 09:42 AM, Elvis Dowson wrote:
Hi,

On Dec 5, 2012, at 5:21 PM, Andreas Schweigstill <andreas@schweigstill.de> wrote:

I have also tried to build a kernel and root filesystem for Zynq but the kernel
gets stuck when booting, regardless if on the ZC702 board or on Qemu. I tried
Poky denzil and Poky danny.

Also the alternate meta-zynq layer from git.yoctoproject.org shows the same
behaviour.

These are the last console messages which I get:
## Booting kernel from Legacy Image at 01000000 ...
Image Name: Linux-3.2.11-yocto-standard
Created: 2012-12-04 20:07:37 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2997472 Bytes = 2.9 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 01a80000
Booting using the fdt blob at 0x1a80000
Loading Device Tree to 0eff8000, end 0efff185 ... OK
Loading Kernel Image ... OK
OK
Loading Device Tree to 0efed000, end 0eff7185 ... OK

Starting kernel ...


Instead of using Linux kernel version 3.5-xilinx I always get
Linux-3.2.11-yocto-standard which is obviously missing the
Zynq patches.

meta-zynq/recipes-kernel-linux-zynq contains the following lines:
LINUX_VERSION ?= "3.5"
LINUX_VERSION_EXTENSION ?= "-xilinx"

How can I force Yocto to build kernel 3.5-xilinx?
From you messages, I infer that you are using the meta-zynq layer
located here:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/

For my builds, I used Philip Ballister's meta-zynq layer located here
for the simple reason that it uses xilinx git repository:

https://github.com/balister/meta-zynq
And in case anyone is wondering, efforts are (still) underway to
get a single unified layer for this board (and others), but getting
all the moving parts organized is taking a bit longer than expected
or than we would like.

Cheers,

Bruce


Also, try to ensure that you don't put both the meta-layers in your bblayers.conf file
while building, and ensure that you set machine as follows in your local.conf file

MACHINE ?= "zynq-zc702"

Do let me know how it goes!

Best regards,

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