Re: [yocto] I hate busybox!

2015-09-16 Thread Mike Looijmans 

On 16-09-15 03:13, Khem Raj wrote:

On Sep 15, 2015, at 7:47 AM, Trevor Woerner  wrote:
On 09/15/15 04:26, Paul D. DeRocco wrote:

My embedded system has enough room in it for full-featured command line
tools,...
"Embedded" in my world is not about RAM or disk size. It's about 
building a device that has a set task in life, and nothing is as 
important as that one task. Whether that's running on an i7 or an M3 is 
irrelevant.


For a system to acquire and process sensor data, record your favorite TV 
shows, or guide a missile, there's no need for a full fledged bash shell 
interpreter. It just needs a bit of plumbing to get the application up 
and running, and that's about it.


Busybox is for systems like that. For these systems, anything more is 
overkill, and will waste resources and increase the boot time.



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

[yocto] Opportunity for Yoto developer (m/f)

2015-09-16 Thread Sarah Hindermann 
Hello Yocto Fans,

I am   looking for a Yocto /   Linux developer (m/w) for a   Project in Germany.

I am interested in permanent employees or contractors who know  Yocto well.



Concerning contractors part time support would also be an option  as  well as 
remote  possibility after a view weeks.

The project is about developing the new product concerning datalogger in  C++.



German language skills are a benefit but not a must. English is sufficient.

 More information at:

 
https://www.xing.com/communities/posts/embedded-linux-entwickler-mit-yocto-w-strich-m-in-darmstadt-asap-remote-mgl-1010137514



 If you have a friend or colleague who might be interested  feel free to  
forward my message.

 Thank you.

 I wish you a wonderful Wednesday!

Sarah


Sarah Hindermann
Recruitment Consultant for Contractors

T: +49  (0) 693 650 650 55
F: +49  (0) 693 650 650 57
M: s.hinderm...@roc-search.de
X: 
www.xing.com/profile/Sarah_Hindermann
H: www.roc-search.de

[Description: Description: Description: Description: Description: Description: 
Description: Description: Description: Description: 
C:\Users\lucy.meddings\Desktop\New logo\ROC_RGB.png]
Roc Search GmbH - Roßmarkt 10 - 60311 Frankfurt am Main

[IIP_LOGO_BLUE_CMYK] [Description: Description: 
C:\Users\lucy.meddings.ROCSEARCH\AppData\Local\Microsoft\Windows\Temporary 
Internet Files\Content.Outlook\10TW11RW\APSCo stacked JPEG for high res 
printing (2) (2).JPG]  [Description: 2012 Fast Track 100 logo (7)] 
[http://www.roc-search.com/File.ashx?path=Root/Images/2013_Fast_Track_100_logo.jpg]

Click Here to check out the 
latest News at Roc Search...

Whether you work with or for us, whether we place you or place people for you, 
at Roc Search our passion is for people and the placements we make. As clients 
and candidates you can be sure we'll take nothing for granted and take the time 
you and we need, to build mutual insight and trust. The smallest new start-ups 
and the largest corporates, the experienced professional and ambitious 
beginner: whoever you are and whatever your story, we believe you deserve a 
flexible, responsive and personal service which delivers the results you need.
At Roc Search we guarantee that's exactly what you can expect.
The information contained in this email may be privileged and is intended for 
the personal and confidential use of the recipient(s) named above. If the 
reader of this message is not the intended recipient or an agent responsible 
for delivering it to the intended recipient, you are hereby notified that you 
have received this email in error and that any review, dissemination or copying 
of this message is strictly prohibited. If you have received this email in 
error, please notify us immediately.
This message and any attachments are believed to be free of any virus or defect 
that might affect any computer system into which it is received and opened. 
However, it is the responsibility of the recipient to ensure that it is virus 
free; therefore, no responsibility is accepted for any loss or damage in any 
way arising from its use
Roc Search Limited. Registered address: The Blade, Abbey Square, Reading, 
Berkshire, RG1 3BE Company Registration number: 06044636.

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

Re: [yocto] Dumping sysvinit

2015-09-16 Thread Burton, Ross 
On 15 September 2015 at 17:27, Trevor Woerner  wrote:

> I think if you remove/comment-out the last of those 3 lines or install
> your host's SDL-devel package you'll solve this issue (?)
>

Yes, that's right.  Either disable the graphical qemu support, or install
the host's sdl-devel package so it can build.

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

Re: [yocto] Dumping sysvinit

2015-09-16 Thread Andy Pont 
Hello all,

> > I think if you remove/comment-out the last of those 3 lines or install
> > your host's SDL-devel package you'll solve this issue (?)
> >
> Yes, that's right.  Either disable the graphical qemu support, or install
> the host's sdl-devel package so it can build.

On my CentOS 6.7 host system running the package manager reports that SDL-devel 
is already installed:

# yum install SDL-devel
Package SDL-devel-1.2.14-6.el6.x86_64 already installed and latest version
Nothing to do

This is probably something to do with the fact that in order to get Fido to 
build I have to use the devtoolset-2.1 package to get a recent gcc version and 
it probably isn't aware of the standard SDL-devel libraries.

Commenting out just the last line of the 3 QEMU/SDL related lines throws out a 
couple of errors whereas removing all of them gives me a build.

Now to figure out why the tar.gz file for the root file system has grown from 
just under 3MiB to almost 15MiB!

Thanks for all the help and advice.

Andy.




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

Re: [yocto] Dumping sysvinit

2015-09-16 Thread Burton, Ross 
On 16 September 2015 at 10:24, Andy Pont  wrote:

> Now to figure out why the tar.gz file for the root file system has grown
> from just under 3MiB to almost 15MiB!
>

That would be systemd... it pulls in a lot of libraries that are fairly
common on complex systems but on a minimal image less so.

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

Re: [yocto] Dumping sysvinit

2015-09-16 Thread Andy Pont 
Ross wrote...

> > Now to figure out why the tar.gz file for the root file system has grown 
> > from just under 3MiB to almost 15MiB!
> 
> That would be systemd... it pulls in a lot of libraries that are fairly common
> on complex systems but on a minimal image less so.

Back to plan A then, trying to figure out how to get Busybox init and mdev as 
the defaults in the image.

Thanks for the feedback!

Andy.

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

Re: [yocto] I hate busybox!

2015-09-16 Thread Khem Raj 
On Wed, Sep 16, 2015 at 2:07 PM, Paul D. DeRocco  wrote:
> Do you mean systemd or syslinux?

none of these it was typo it should be read as 'systems'
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH] Bluetooth: Delay check for conn->smp in smp_conn_security()

2015-09-16 Thread Bruce Ashfield 

On 15-09-15 05:10 AM, Wu Zheng wrote:

From: Johan Hedberg 

There are several actions that smp_conn_security() might make that do
not require a valid SMP context (conn->smp pointer). One of these
actions is to encrypt the link with an existing LTK. If the SMP
context wasn't initialized properly we should still allow the
independent actions to be done, i.e. the check for the context should
only be done at the last possible moment.


I've staged the commit. When my build tests pass, I'll push it to
the servers. Should be out by tomorrow.

Bruce



Reported-by: Chuck Ebbert 
Signed-off-by: Johan Hedberg 
Signed-off-by: Marcel Holtmann 
---
  net/bluetooth/smp.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index ad82324..0510a57 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -2311,12 +2311,6 @@ int smp_conn_security(struct hci_conn *hcon, __u8 
sec_level)
if (!conn)
return 1;

-   chan = conn->smp;
-   if (!chan) {
-   BT_ERR("SMP security requested but not available");
-   return 1;
-   }
-
if (!hci_dev_test_flag(hcon->hdev, HCI_LE_ENABLED))
return 1;

@@ -2330,6 +2324,12 @@ int smp_conn_security(struct hci_conn *hcon, __u8 
sec_level)
if (smp_ltk_encrypt(conn, hcon->pending_sec_level))
return 0;

+   chan = conn->smp;
+   if (!chan) {
+   BT_ERR("SMP security requested but not available");
+   return 1;
+   }
+
l2cap_chan_lock(chan);

/* If SMP is already in progress ignore this request */



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

Re: [yocto] I hate busybox!

2015-09-16 Thread Paul D. DeRocco 
> From: Khem Raj [mailto:raj.k...@gmail.com] 
> 
> Generally when you have systemd which copy images to RAM and then run
> from RAM would not want that extra 50 odd Megs gone
> for storing extra tools in some case.

Do you mean systemd or syslinux?

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

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

Re: [yocto] I hate busybox!

2015-09-16 Thread Khem Raj 
On Wed, Sep 16, 2015 at 9:43 AM, Paul D. DeRocco  wrote:
> If you've got a 1GB eSSD drive, because that's the smallest you can buy,
> having a 382MB image rather than a 346MB image isn't a waste of anything.
> How much boot time increase do you think you'll get from full-featured
> command line tools? I'd be surprised if it was noticeable to anyone.

Thats one usecase and there are so many other. Usually, you want to be
mindful about OS overhead especially in embedded systems
in todays time it may be sufficient you may want to recover that space
in 5 years down the line. It depends on usecases but generally
being mindful about resource usage is always beneficial in products
life cycle embedded systems sometimes live for a very long time in
field

Generally when you have systemd which copy images to RAM and then run
from RAM would not want that extra 50 odd Megs gone
for storing extra tools in some case.

As long as we keep supporting the most common ones along with fringe
cases but with less priority we are OK.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] buildset-config.examples/gitpoller.conf, README-NEW-AUTOBUILDER

2015-09-16 Thread Graydon, Tracy 
[YOCTO #7702]

This patchset provides an example buildset conf for a multi-
branch GitPoller, which may be found in the
build-config.examples directory. The README-NEW-AUTOBUILDER
file has also been updated with this example.

Signed-off-by: Graydon, Tracy 
---
 README-NEW-AUTOBUILDER  | 43 -
 buildset-config.examples/gitpoller.conf | 33 +
 2 files changed, 75 insertions(+), 1 deletion(-)
 create mode 100644 buildset-config.examples/gitpoller.conf

diff --git a/README-NEW-AUTOBUILDER b/README-NEW-AUTOBUILDER
index d519b15..c37c8c4 100644
--- a/README-NEW-AUTOBUILDER
+++ b/README-NEW-AUTOBUILDER
@@ -249,7 +249,7 @@ scheduler: A list of dicts. Each item defines a scheduler 
associated with this
If you are using a SingleBranchScheduler schedule, it is good
practice to force a build to verify the buildset works correctly.
 
-Example:
+Example of PBChangeSource:
 
 [nightly-x86]
 builders: 'builder1'
@@ -276,6 +276,47 @@ scheduler: [{'dev-branch-scheduler' :
  'stable-timer':30,
  'change-password':'secret_change_password'}}]
 
+
+Example of MultiBranch GitPoller:
+
+[git-poller]
+builders: 'example-worker'
+repos: [{'poky-contrib':
+{'repourl':'git://git.yoctoproject.org/poky-contrib',
+ 'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-bsp'},
+ 'branch':'tgraydon/poky'}},
+{'meta-qt3':
+{'repourl':'git://git.yoctoproject.org/poky-contrib',
+ 'branch':'tgraydon/meta-qt3'}}]
+steps: [{'SetDest':{}},
+{'CheckOutLayers': {}},
+{'RunPreamble': {}},
+{'GetDistroVersion' : {'distro': 'poky'}},
+{'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'i686',
+'distro': 'poky'}},
+{'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
+{'BuildImages': {'images': 'core-image-sato'}},
+{'PublishLayerTarballs':{}},
+{'PublishArtifacts': {'artifacts': ['qemux86', 'atom-pc']}}]
+scheduler: [{'git-poller-scheduler':
+{'type':'SingleBranchScheduler',
+ 'changesource':'GitPoller',
+ 'repository':'poky-contrib',
+ 'branch':'tgraydon/poky',
+ 'interval':3600},
+ 'stable-timer':300}}]
+scheduler: [{'git-poller-scheduler':
+{'type':'SingleBranchScheduler',
+ 'changesource':'GitPoller',
+ 'repository':'poky-contrib',
+ 'branch':'tgraydon/meta-qt3',
+ 'interval':3600},
+ 'stable-timer':300}}]
+
+Note that the 'change-password' property is not used for GitPoller. This 
+buildset config may also be found in the build-config.examples directory.
+
+
 Adding Buildsteps
 -
 I've included the basic buildsteps required to do general building as well as 
an
diff --git a/buildset-config.examples/gitpoller.conf 
b/buildset-config.examples/gitpoller.conf
new file mode 100644
index 000..9bf5165
--- /dev/null
+++ b/buildset-config.examples/gitpoller.conf
@@ -0,0 +1,33 @@
+[git-poller]
+builders: 'example-worker'
+repos: [{'poky-contrib':
+{'repourl':'git://git.yoctoproject.org/poky-contrib',
+ 'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-bsp'},
+ 'branch':'tgraydon/poky'}},
+{'meta-qt3':
+{'repourl':'git://git.yoctoproject.org/poky-contrib',
+ 'branch':'tgraydon/meta-qt3'}}]
+steps: [{'SetDest':{}},
+{'CheckOutLayers': {}},
+{'RunPreamble': {}},
+{'GetDistroVersion' : {'distro': 'poky'}},
+{'CreateAutoConf': {'machine': 'qemux86', 'SDKMACHINE' : 'i686',
+'distro': 'poky'}},
+{'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
+{'BuildImages': {'images': 'core-image-sato'}},
+{'PublishLayerTarballs':{}},
+{'PublishArtifacts': {'artifacts': ['qemux86', 'atom-pc']}}]
+scheduler: [{'git-poller-scheduler':
+{'type':'SingleBranchScheduler',
+ 'changesource':'GitPoller',
+ 'repository':'poky-contrib',
+ 'branch':'tgraydon/poky',
+ 'interval':'3600,
+ 'stable-timer':300}}]
+scheduler: [{'git-poller-scheduler':
+{'type':'SingleBranchScheduler',
+ 'changesource':'GitPoller',
+ 'repository':'poky-contrib',
+ 'branch':'tgraydon/meta-qt3',
+ 'interval':'3600,
+ 'stable-timer':300}}]
-- 
1.9.3

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

Re: [yocto] [meta-raspberrypi] du giving non-integer result?

2015-09-16 Thread Jonathan Liu 
On 11 September 2015 at 11:37, Trevor Woerner  wrote:
> From the feedback, it looks like I'm the only one seeing this issue.
> That's okay, but I'll update this issue with new information in case
> it's useful to others. Today I also had some other strangeness with the
> "make sd card image" portion of a build, this time for cubietruck
> (meta-sunxi):
>
>
> ERROR: Error: The image creation script
> 
> '/z/tmp/build/tmp/work/cubietruck-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/create_image.sunxi-sdimg'
> returned 1:
> 0+0 records in
> 0+0 records out
> 0 bytes (0 B) copied, 3.0606e-05 s, 0.0 kB/s
> expr: non-integer argument
> WARNING:
> 
> /z/tmp/build/tmp/work/cubietruck-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/create_image.sunxi-sdimg:1
> exit 1 from
>   parted -s
> 
> /z/tmp/build/tmp/deploy/images/cubietruck/core-image-minimal-cubietruck-20150910182624.rootfs.sunxi-sdimg
> unit KiB mkpart primary ext2 $(expr ${BOOT_SPACE_ALIGNED} \+ 2048)
> $(expr ${BOOT_SPACE_ALIGNED} \+ 2048 \+ 10240.0)
>
>
>
> Not only am I getting the floating point again, but it looks like
> "BOOT_SPACE_ALIGNED" isn't getting expanded!
>
> The frustrating part is that simply rerunning "bitbake
> core-image-minimal" fixes the problem. The second time it completes
> without error.
> --

I sent a patch to openembedded-core mailing list for ROOTFS_SIZE not
being an integer.
It seems 
http://git.openembedded.org/openembedded-core/commit/?id=af37bb8ae71c4f932e2126bb620b3fb2b11cc466
results in ROOTFS_SIZE now being set as a bitbake variable.
meta-raspberrypi will need to be updated to not have a conflicting
ROOTFS_SIZE variable as ${ROOTFS_SIZE} is being substituted by bitbake
instead of the shell there.

Regards,
Jonathan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto