Re: [yocto] Basic failures building 1st Yocto Project and Yocto Raspberry Pi

[Jack Mitchell]

On 02/01/13 21:47, David Evans wrote:

Dear Sirs,

I apologise for asking this question to everyone, but I can't figure 
out who best to direct this question to.


When I build the standard Yocto Project in the Quick-Start guide I get 
the following Warnings.


WARNING: Failed to fetch URL 
http://www.apache.org/dist/subversion/subversion-1.7.6.tar.bz2, 
attempting MIRRORS if available
WARNING: Failed to fetch URL 
ftp://ftp.ossp.org/pkg/lib/uuid/uuid-1.6.2.tar.gz, attempting MIRRORS 
if available
WARNING: Failed to fetch URL 
http://downloads.sourceforge.net/project/libpng/libpng12/1.2.49/libpng-1.2.49.tar.bz2, 
attempting MIRRORS if available


As a complete Newbie to Yocto, having the Quick-Start fail like this 
is killing me, as I have no stable example upon which to build my 
under standing.


My ultimate goal is to run the Raspberry Pi project as outlined at 
http://www.pimpmypi.com/blog/blogPost.php?blogPostID=7, but I am 
seeing the same do_fetch failures as those reported by Ed Nelson at 
https://lists.yoctoproject.org/pipermail/yocto/2013-January/013571.html.


Any help will be much appreciated.


Regards,

David


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


I will try to get round to updating this tutorial soon; as it has become 
a bit dated - however as Alex mentions it should still work fine albeit 
with a few warnings due to unavailable sources.


It should just be a matter of changing a few git revisions, and tweaking 
the wording a bit to involve the new meta-yocto, meta-yocto-bsp split. 
If anyone wishes to step up to the plate the source for this blog post 
is available at [1] and I will happily accept patches.


Cheers,
Jack.

[1] https://github.com/CommunistCode/PimpMyPi-Community-Blog-Posts

--

  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  http://www.embed.me.uk

--

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

Re: [yocto] Basic failures building 1st Yocto Project and Yocto Raspberry Pi

[Alex J Lennon]

On 03/01/2013 10:48, Jack Mitchell wrote:
> On 02/01/13 21:47, David Evans wrote:
>> Dear Sirs,
>>
>> I apologise for asking this question to everyone, but I can't figure 
>> out who best to direct this question to.
>>
>> When I build the standard Yocto Project in the Quick-Start guide I get 
>> the following Warnings.
>>
>> WARNING: Failed to fetch URL 
>> http://www.apache.org/dist/subversion/subversion-1.7.6.tar.bz2, 
>> attempting MIRRORS if available
>> WARNING: Failed to fetch URL 
>> ftp://ftp.ossp.org/pkg/lib/uuid/uuid-1.6.2.tar.gz, attempting MIRRORS 
>> if available
>> WARNING: Failed to fetch URL 
>> http://downloads.sourceforge.net/project/libpng/libpng12/1.2.49/libpng-1.2.49.tar.bz2,
>>  
>> attempting MIRRORS if available
>>
>> As a complete Newbie to Yocto, having the Quick-Start fail like this 
>> is killing me, as I have no stable example upon which to build my 
>> under standing.
>>
>> My ultimate goal is to run the Raspberry Pi project as outlined at 
>> http://www.pimpmypi.com/blog/blogPost.php?blogPostID=7, but I am 
>> seeing the same do_fetch failures as those reported by Ed Nelson at 
>> https://lists.yoctoproject.org/pipermail/yocto/2013-January/013571.html.
>>
>> Any help will be much appreciated.
>>
>>
>> Regards,
>>
>> David
>>
>>
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
> 
> I will try to get round to updating this tutorial soon; as it has become 
> a bit dated - however as Alex mentions it should still work fine albeit 
> with a few warnings due to unavailable sources.
> 
> It should just be a matter of changing a few git revisions, and tweaking 
> the wording a bit to involve the new meta-yocto, meta-yocto-bsp split. 
> If anyone wishes to step up to the plate the source for this blog post 
> is available at [1] and I will happily accept patches.
> 
> Cheers,
> Jack.
> 
> [1] https://github.com/CommunistCode/PimpMyPi-Community-Blog-Posts
> 

Jack,

I found that post hugely helpful thanks, as I'd tried some months before
with the information at Distant Earth (http://www.distant-earth.com/wp/)
and for some reason I just wasn't able to produce an image that booted
on the RPi.

As you mention, I did find those git commits to be a little old and I
wasn't able to get an EFL UI build working from them.

As a result I migrated forward to the latest head commits at the time
and was able to get a build going (running EFL in fact)

I put some notes up here as I went along, which build upon the Pimp My
Pi blog post -

https://www.assembla.com/spaces/ciseco-eve/wiki/Getting_Started

I haven't yet updated those notes to reflect the newer Git commits I was
using but I've noted them down here -

https://www.assembla.com/spaces/ciseco-eve/wiki/Work_in_progress

Not sure if that helps, except that I can say it is building and working
from these much more recent commits...

(On a separate note I'd be interested in a chat with anybody who has any
ideas on performance of EFL and how it can be improved, e.g. improved
XServer support, hard fp perhaps, maybe EFL on DirectFB or similar?)

Cheers,

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

Re: [yocto] [meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)

[Autif Khan]

On Wed, Jan 2, 2013 at 3:46 PM, Alex J Lennon
 wrote:
> On 02/01/2013 20:27, Autif Khan wrote:
>> On Thu, Dec 27, 2012 at 12:10 PM, Autif Khan  wrote:
>>> On Wed, Dec 26, 2012 at 12:05 PM, Alex J Lennon
>>>  wrote:
 Hi all, Autif,

 I've been working to support .NET development on Linux
 over the past few days.

 There is a Visual Studio plugin, MonoTools for Visual Studio
 which provides support for local and remote debugging of
 .NET applications with Mono.

 This requires a remote stub to be running on the target
 platform, monotools-server.

 I've created a recipe to build monotools-server, which in
 turn required me to pull in Openembedded Legacy recipes
 for mono-xsp and gtk-sharp.

 As it stands I'm now able to build an X enabled image for
 the Raspberry Pi and remote-debug some simple Windows
 Forms .NET applications within the Visual Studio IDE.

 Recipes are hosted here in 'recipes-mono'

 g...@git.assembla.com:ciseco-eve.meta-eve.git
>>
>> I could not "git clone" the repo.
>
> Apologies. I should have given you the public r/o link.
>
> Originally I was trying to avoid modifying meta-mono, adding .bbappends
> into my own meta-eve layer instead, but since my last post to you I
> found I couldn't build against the current HEAD of Yocto due to some odd
> file location issues which I couldn't overlay. (i.e. it didn't seem to
> be able to pick up the patches where you had them - although was fine
> with an older commit of the Yocto core).
>
> As a result I've moved the original meta-mono patches that weren't being
> picked up by bitbake and merged my additions into a fork of meta-mono
> which is here:
>
> git://git.assembla.com/ciseco-eve.meta-mono.git

Got it.

I scanned thru the code and saw what you did to re-organize the
directory structure.

When I get back, I will see if I can build libGDI+ and mono with
denzil (I am stuck with denzil for reasons beyond my control, or until
I find a show stopping bug in denzil for our project - unlikely)

Meanwhile, I have no questions about changes for gk-sharp, mono,
mono-xsp and monotools-server.

Presumably, you will take care of the "TODO: This needs fixing
properly and needs to be revisited" in mono_.bb - I
definitely do not want unstripped binaries on my distribution -
presumably, this was needed for some debugging and is not meant to be
checked into production.

I could not understand the purpose of
libgdiplus/files/libgdiplus-2.10/libgdiplus-2.10.1-libpng15.patch -
could you please help me understand what prompted these seemingly non
trivial changes.

Everything else looks good.

> I'm coming up the curve on Git, as I migrate from mainly Subversion use.
> Can I issue a "pull request" to you or some such?

Yes, a pull request should work.

>> Presumably, you want to release the recipes with the MIT and/or GPLv2 
>> licenses.
>>
>> If the license is different for monotools-server or mono-xsp or
>> gtk-sharp, you will likely have to submit a patch for README file too.
>> Even otherwise, section 4 in README needs to be updated. If you have
>> any tasks left - please add them to section 10.
>>
>
> Will double check this. I am waiting for feedback from the
> monotools-server people on their license as there's nothing explicit in
> their source.

Will wait for that. Might affect the README

>> The guidelines for the Yocto project are very similar to other FOSS
>> projects including the Linux kernel. They are outlined here:
>>
>> https://wiki.yoctoproject.org/wiki/Contribution_Guidelines
>>
>> I used the following as a guide when I have submitted my patches in
>> the past. This is for the Linux kernel, adapt as appropriate for
>> meta-mono.
>>
>> http://linux.koolsolutions.com/2011/02/26/howto-create-and-submit-your-first-linux-kernel-patch/
>>
>> Please submit separate patches for each of the recipes (presumably
>> there are no changes to the mono/libGDI+ recipes)
>>
>> Please add me to the "To:" recipient (I filter a lot of PATCH related
>> traffic) - this should allow the emails to be caught by the filter
>> instead of archiving.
>>
>> In case I do not respond within 72 hours, please email me with a
>> gentle reminder :-)
>>
>> I have not had the opportunity to integrate patches just yet, please
>> bear with me in case I screw up.
>>
>> Thanks again for contributing!
>>
>> PS #1: If you do not want to go thru the hassle - please email me the
>> tar.gz as an attachment and I will check it in directly - a bad side
>> effect of this would be that you will not get any "git" credit for
>> this
>>
>> PS #2: I am still on vacation, but had a few hours - the 72 hour clock
>> will start only after Monday :-)
>>
>> And finally, PS #3:
>>
>> http://marc.info/?l=linux-usb&m=135229956521385&w=2
>> http://marc.info/?l=linux-usb&m=135119051922403&w=2
>> http://marc.info/?l=linux-usb&m=134858043613838&w=2
>> http://marc.info/?l=linux-usb&m=134791970203982&w=2
>> ... many others ...
>

Re: [yocto] [meta-mono] Support for Visual Studio debugging on Yocto/OE targets (e.g. RPi)

[Alex J Lennon]

On 03/01/2013 15:24, Autif Khan wrote:
> On Wed, Jan 2, 2013 at 3:46 PM, Alex J Lennon
>  wrote:
>> On 02/01/2013 20:27, Autif Khan wrote:
>>> On Thu, Dec 27, 2012 at 12:10 PM, Autif Khan  wrote:
 On Wed, Dec 26, 2012 at 12:05 PM, Alex J Lennon
  wrote:
> Hi all, Autif,
>
> I've been working to support .NET development on Linux
> over the past few days.
>
> There is a Visual Studio plugin, MonoTools for Visual Studio
> which provides support for local and remote debugging of
> .NET applications with Mono.
>
> This requires a remote stub to be running on the target
> platform, monotools-server.
>
> I've created a recipe to build monotools-server, which in
> turn required me to pull in Openembedded Legacy recipes
> for mono-xsp and gtk-sharp.
>
> As it stands I'm now able to build an X enabled image for
> the Raspberry Pi and remote-debug some simple Windows
> Forms .NET applications within the Visual Studio IDE.
>
> Recipes are hosted here in 'recipes-mono'
>
> g...@git.assembla.com:ciseco-eve.meta-eve.git
>>>
>>> I could not "git clone" the repo.
>>
>> Apologies. I should have given you the public r/o link.
>>
>> Originally I was trying to avoid modifying meta-mono, adding .bbappends
>> into my own meta-eve layer instead, but since my last post to you I
>> found I couldn't build against the current HEAD of Yocto due to some odd
>> file location issues which I couldn't overlay. (i.e. it didn't seem to
>> be able to pick up the patches where you had them - although was fine
>> with an older commit of the Yocto core).
>>
>> As a result I've moved the original meta-mono patches that weren't being
>> picked up by bitbake and merged my additions into a fork of meta-mono
>> which is here:
>>
>> git://git.assembla.com/ciseco-eve.meta-mono.git
> 
> Got it.
> 
> I scanned thru the code and saw what you did to re-organize the
> directory structure.
> 
> When I get back, I will see if I can build libGDI+ and mono with
> denzil (I am stuck with denzil for reasons beyond my control, or until
> I find a show stopping bug in denzil for our project - unlikely)
> 
> Meanwhile, I have no questions about changes for gk-sharp, mono,
> mono-xsp and monotools-server.
> 

Good oh.

> Presumably, you will take care of the "TODO: This needs fixing
> properly and needs to be revisited" in mono_.bb - I
> definitely do not want unstripped binaries on my distribution -
> presumably, this was needed for some debugging and is not meant to be
> checked into production.

Ah yes. I'd forgotten about that. I shall habe to revisit why that was
erroring.

> I could not understand the purpose of
> libgdiplus/files/libgdiplus-2.10/libgdiplus-2.10.1-libpng15.patch -
> could you please help me understand what prompted these seemingly non
> trivial changes.
>

Yes there seems to be a problem building libGDI against libpng15. It
seems a known issue:

https://github.com/mono/libgdiplus/pull/4

> Everything else looks good.
> 

Good oh

>> I'm coming up the curve on Git, as I migrate from mainly Subversion use.
>> Can I issue a "pull request" to you or some such?
> 
> Yes, a pull request should work.
> 
>>> Presumably, you want to release the recipes with the MIT and/or GPLv2 
>>> licenses.
>>>
>>> If the license is different for monotools-server or mono-xsp or
>>> gtk-sharp, you will likely have to submit a patch for README file too.
>>> Even otherwise, section 4 in README needs to be updated. If you have
>>> any tasks left - please add them to section 10.
>>>
>>
>> Will double check this. I am waiting for feedback from the
>> monotools-server people on their license as there's nothing explicit in
>> their source.
> 
> Will wait for that. Might affect the README
> 

I'll give them another nudge once I've worked our what's going on with
the stripping, commit to my fork and then try to work out how to send
you a pull req.

>>> The guidelines for the Yocto project are very similar to other FOSS
>>> projects including the Linux kernel. They are outlined here:
>>>
>>> https://wiki.yoctoproject.org/wiki/Contribution_Guidelines
>>>
>>> I used the following as a guide when I have submitted my patches in
>>> the past. This is for the Linux kernel, adapt as appropriate for
>>> meta-mono.
>>>
>>> http://linux.koolsolutions.com/2011/02/26/howto-create-and-submit-your-first-linux-kernel-patch/
>>>
>>> Please submit separate patches for each of the recipes (presumably
>>> there are no changes to the mono/libGDI+ recipes)
>>>
>>> Please add me to the "To:" recipient (I filter a lot of PATCH related
>>> traffic) - this should allow the emails to be caught by the filter
>>> instead of archiving.
>>>
>>> In case I do not respond within 72 hours, please email me with a
>>> gentle reminder :-)
>>>
>>> I have not had the opportunity to integrate patches just yet, please
>>> bear with me in case I screw up.
>>>
>>> Thanks again for contributing!
>>>
>>> PS #1: If you do not

[yocto] do_patch fails for quilt-native-0.60-r0

[Barros Pena, Belen]

Hi there,

I am trying to build core-image-minimal with Hob using the latest master.
The build fails. I've pasted the log below.

Does anybody know why and what can I do to fix it?

Thanks!!

Belen


Build Configuration:
BB_VERSION= "1.17.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Unknown"
TARGET_SYS= "mips-poky-linux"
MACHINE   = "qemumips"
DISTRO= "poky"
DISTRO_VERSION= "1.3+snapshot-20130103"
TUNE_FEATURES = "o32 bigendian fpu-hard mips32"
TARGET_FPU= ""
meta
meta-hob
meta-yocto-bsp
meta-yocto= "master:09359e6ec00901abfe49157f1f9730117b4d284b"

WARNING: /home/yocto/poky/bitbake/lib/bb/ui/crumbs/hobwidget.py:769:
Warning: g_object_set_qdata: assertion `G_IS_OBJECT (object)' failed
  if self.props.icon_name or self.props.pixbuf or self.props.stock_id:

WARNING: /home/yocto/poky/bitbake/lib/bb/ui/crumbs/hobwidget.py:751:
Warning: g_object_set_qdata: assertion `G_IS_OBJECT (object)' failed
  elif self.props.pixbuf:

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 3 of 1629 (ID: 879,
/home/yocto/poky/meta/recipes-devtools/quilt/quilt-native_0.60.bb,
do_patch)
NOTE: Running task 28 of 1629 (ID: 1112,
virtual:native:/home/yocto/poky/meta/recipes-devtools/bison/bison_2.7.bb,
do_fetch)
NOTE: Running task 35 of 1629 (ID: 332,
/home/yocto/poky/meta/recipes-devtools/binutils/binutils-cross_2.23.1.bb,
do_fetch)
NOTE: Running task 38 of 1629 (ID: 200,
/home/yocto/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_
3.4.3.bb,
do_fetch)
NOTE: recipe linux-libc-headers-3.4.3-r0: task do_fetch: Succeeded
NOTE: Running task 39 of 1629 (ID: 196,
/home/yocto/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_
3.4.3.bb,
do_unpack)
ERROR: Command Error: exit status: 1  Output:
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--
|Upstream-Status: Pending
|
|--- quilt-0.47/Makefile.in 2008-12-31 19:09:13.0 +
|+++ quilt-0.47/Makefile.in.orig2008-08-21 13:21:32.0 +0100
--
File to patch:
Skip this patch? [y]
Skipping patch.
1 out of 1 hunk ignored
ERROR: Function failed: patch_do_patch
NOTE: recipe quilt-native-0.60-r0: task do_patch: Failed
ERROR: Task 879
(/home/yocto/poky/meta/recipes-devtools/quilt/quilt-native_0.60.bb,
do_patch) failed with exit code '1'
NOTE: recipe binutils-cross-2.23.1-r0: task do_fetch: Succeeded
NOTE: recipe bison-native-2.7-r0: task do_fetch: Succeeded
NOTE: recipe linux-libc-headers-3.4.3-r0: task do_unpack: Succeeded
NOTE: Tasks Summary: Attempted 39 tasks of which 34 didn't need to be
rerun and 1 failed.

-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

Re: [yocto] Fix prelink build with automake-1.13

[Mark Hatle]

On 1/3/13 1:52 AM, Marko Lindqvist wrote:

[PATCH] fix build with automake-1.13.

Long obsolete AM_CONFIG_HEADER is completely removed from automake-1.13,
which errors out upon seeing it.
configure.in -> configure.ac rename is not strictly necessary yet,
use of deprecated name still gives only warning.

Problem in dropping obsolete constructs is that support for autotools
versions so ancient that now-obsolete way is the only way to do things.
configure.in seems to have AC_PREREQ(2.13), but with these changes
(if not earlier) such an ancient autoconf will not do.



Do you know if the change to AC_CONFIG_HEADER (from AM_CONFIG_HEADER) is 
supported in autoconf 2.13?  Assuming it likely is, I'll get this merged. 
Otherwise we should expect to bump the AC_PREREQ.


BTW I'll check and see if this patch is specific to the cross-prelinker or 
applicable to the upstream prelink as well.  Seems like if it's applicable there 
they may want it as well..


--Mark


  - ML



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

Re: [yocto] Fix prelink build with automake-1.13

[Mark Hatle]

On 1/3/13 10:00 AM, Mark Hatle wrote:

On 1/3/13 1:52 AM, Marko Lindqvist wrote:

[PATCH] fix build with automake-1.13.

Long obsolete AM_CONFIG_HEADER is completely removed from automake-1.13,
which errors out upon seeing it.
configure.in -> configure.ac rename is not strictly necessary yet,
use of deprecated name still gives only warning.

Problem in dropping obsolete constructs is that support for autotools
versions so ancient that now-obsolete way is the only way to do things.
configure.in seems to have AC_PREREQ(2.13), but with these changes
(if not earlier) such an ancient autoconf will not do.



Do you know if the change to AC_CONFIG_HEADER (from AM_CONFIG_HEADER) is
supported in autoconf 2.13?  Assuming it likely is, I'll get this merged.
Otherwise we should expect to bump the AC_PREREQ.

BTW I'll check and see if this patch is specific to the cross-prelinker or
applicable to the upstream prelink as well.  Seems like if it's applicable there
they may want it as well..


Responding to my own query.  I just checked and the cross-prelinker is already 
setup for AC_PREREQ(2.50):


http://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/tree/trunk/configure.in?h=cross_prelink

(The unmodified upstream -- master branch -- is still using AC_PREREQ(2.13). 
But we don't use that in OE/Yocto Project work.)


The -- cross_prelink branch -- does still have the AM_CONFIG_HEADER.  I'll get 
that updated.  I will also rename the configure.in to configure.ac and adjust 
anything else that references that.


--Mark


--Mark


   - ML





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

Re: [yocto] Fails to launch the hob

[Barros Pena, Belen]

Any chance we could change the content of the error message to provide better 
indication of what the problem is? The idea would be adding version numbers and 
printing only what's causing trouble.

So, from:

$ hob
FATAL: Gtk+, PyGtk and PyGobject are required to use Hob,
You have Gtk+ 2.20.1 and PyGtk 2.17.0.

To something like:

$ hob
FATAL: Hob requires Gtk+ 2.20.0 or higher, PyGtk 2.21.0 or higher and PyGobject 
[insert minimum version here] or higher
You have PyGtk 2.17.0.

Would this be possible?

We should probably also add a paragraph listing essential packages to the Hob 
manual page on the website 
(https://www.yoctoproject.org/documentation/hob-manual). If someone tells me 
what's the minimum version of PyGobject required I could probably edit the page 
myself.

Thanks!

Belen



From: Biao mailto:huanmat...@163.com>>
Date: Tuesday, 25 December 2012 06:16
To: Mihai Lindner 
mailto:mihaix.lind...@linux.intel.com>>
Cc: "yocto@yoctoproject.org" 
mailto:yocto@yoctoproject.org>>
Subject: Re: [yocto] Fails to launch the hob


At 2012-12-24 20:37:26,"Mihai Lindner" 
mailto:mihaix.lind...@linux.intel.com>> wrote:
>On Mon, 2012-12-24 at 14:23 +0200, Mihai Lindner wrote:
>> On Mon, 2012-12-24 at 15:37 +0800, Biao wrote:
>> > Hi all,
>> >
>> >
>> > I can not launch hob on my ubun-10.04, it seems saying "no PyGobject" 
>> > whereas python-object has already been installed. Can anyone kindly give a 
>> > help?
>> >
>Oh, forgot to mention here, that you should probably be using Denzil,
>instead of Danny or 'master'.

Thanks for the kindly reminder.
>> >
>> > $ hob
>> > FATAL: Gtk+, PyGtk and PyGobject are required to use Hob,
>> > You have Gtk+ 2.20.1 and PyGtk 2.17.0.
>> >
>> >
>> > $ sudo apt-get install python-gobject
>> > Reading package lists... Done
>> > Building dependency tree
>> > Reading state information... Done
>> > python-gobject is already the newest version.
>> >
>> Python-gobject seems fine, Gtk seems fine (you have 2.20.1, Hob wants
>> higher than 2.20.0), which leaves python-gtk2 version 2.17.0 on your
>> system. Hob wants a version higher than 2.21.0.

Thanks for this information, it seems the prompt message on the environment 
checking is not so clear.  Where are the hob users supposed to get such kind of 
information from?

I did not found this information from the hob manual.

>>
>> --Mihai
>> >
>> > $ uname -a
>> > Linux zb-d 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC 2011 
>> > x86_64 GNU/Linux
>> >
>> >
>> > Thanks,
>> > Biao
>> > ___ yocto mailing list 
>> > yocto@yoctoproject.org 
>> > https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>___
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto

-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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

Re: [yocto] Fails to launch the hob

[Zhang, Jessica]

Hi Belen,

I'll modify the error message per suggestion.  By looking at the existing code, 
seems we only check for GTK+ and PyGtk version, so probably I'll drop PyGobject 
in the error message.  So you probably can update the hob info on the web-site 
accordingly.

Thanks,
Jessica

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Barros Pena, Belen
Sent: Thursday, January 03, 2013 8:48 AM
To: Biao; Mihai Lindner
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Fails to launch the hob

Any chance we could change the content of the error message to provide better 
indication of what the problem is? The idea would be adding version numbers and 
printing only what's causing trouble.

So, from:

$ hob
FATAL: Gtk+, PyGtk and PyGobject are required to use Hob, You have Gtk+ 2.20.1 
and PyGtk 2.17.0.

To something like:

$ hob
FATAL: Hob requires Gtk+ 2.20.0 or higher, PyGtk 2.21.0 or higher and PyGobject 
[insert minimum version here] or higher You have PyGtk 2.17.0.

Would this be possible?

We should probably also add a paragraph listing essential packages to the Hob 
manual page on the website 
(https://www.yoctoproject.org/documentation/hob-manual). If someone tells me 
what's the minimum version of PyGobject required I could probably edit the page 
myself.

Thanks!

Belen



From: Biao mailto:huanmat...@163.com>>
Date: Tuesday, 25 December 2012 06:16
To: Mihai Lindner 
mailto:mihaix.lind...@linux.intel.com>>
Cc: "yocto@yoctoproject.org" 
mailto:yocto@yoctoproject.org>>
Subject: Re: [yocto] Fails to launch the hob


At 2012-12-24 20:37:26,"Mihai Lindner" 
mailto:mihaix.lind...@linux.intel.com>> wrote:
>On Mon, 2012-12-24 at 14:23 +0200, Mihai Lindner wrote:
>> On Mon, 2012-12-24 at 15:37 +0800, Biao wrote:
>> > Hi all,
>> >
>> >
>> > I can not launch hob on my ubun-10.04, it seems saying "no PyGobject" 
>> > whereas python-object has already been installed. Can anyone kindly give a 
>> > help?
>> >
>Oh, forgot to mention here, that you should probably be using Denzil,
>instead of Danny or 'master'.

Thanks for the kindly reminder.
>> >
>> > $ hob
>> > FATAL: Gtk+, PyGtk and PyGobject are required to use Hob, You have
>> > Gtk+ 2.20.1 and PyGtk 2.17.0.
>> >
>> >
>> > $ sudo apt-get install python-gobject Reading package lists... Done
>> > Building dependency tree Reading state information... Done
>> > python-gobject is already the newest version.
>> >
>> Python-gobject seems fine, Gtk seems fine (you have 2.20.1, Hob wants
>> higher than 2.20.0), which leaves python-gtk2 version 2.17.0 on your
>> system. Hob wants a version higher than 2.21.0.

Thanks for this information, it seems the prompt message on the environment 
checking is not so clear.  Where are the hob users supposed to get such kind of 
information from?

I did not found this information from the hob manual.

>>
>> --Mihai
>> >
>> > $ uname -a
>> > Linux zb-d 2.6.32-33-generic #72-Ubuntu SMP Fri Jul 29 21:07:13 UTC
>> > 2011 x86_64 GNU/Linux
>> >
>> >
>> > Thanks,
>> > Biao
>> > ___ yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>___
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto

-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.

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

[yocto] configuration management on remote target

[Ilya Dmitrichenko]

Hi,

As my day job mostly involves configuring servers using puppet
configuration management system, I had been thinking of what sort of tool
would be best to use on an embedded devices where on some occasions one
would want to update a couple of config files and scripts. Perhaps this can
be limited just to the `/etc` direcotry...

So the best I could come up with so far is to implement it as cron job that
would pull a git repository, perhaps it would also run a script (git hook)
that would restart a daemon or do something of that kind.

I suppose that some people will suggest to just use packages, but I'm not
very keen on maintaining a package repository on some sever out in the
internet that would be one big single point of failure. Although, perhaps,
on some occasion, this may be the only way.
Another reason why I wouldn't like to use git to manage configuration, as
that way all configs are going to be at hand from one directory tree, which
is, IMO, much quicker to manage and validate rather then a recipes spread
across subdirectories.

Firstly, I'd appreciate any feedback on this!

And I do have a few rather more specific questions ;)

a) How often OE users do not implement any system updates over the wire in
their products, although the product is able to access the internet?

b) Has anyone here use the configuration tools like puppet, chef or
cfendgine and understands the benefits?

c) Has anyone succeeded building git without having to include perl on the
target? I'd probably get ways with just a subset of git commands.
I have also had a look at libgit2, but not sure if I'd be able to implement
something as robust as git itself with libgit2...


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

Re: [yocto] configuration management on remote target

[Mark Hatle]

On 1/3/13 5:43 PM, Ilya Dmitrichenko wrote:

Hi,

As my day job mostly involves configuring servers using puppet configuration
management system, I had been thinking of what sort of tool would be best to use
on an embedded devices where on some occasions one would want to update a couple
of config files and scripts. Perhaps this can be limited just to the `/etc`
direcotry...

So the best I could come up with so far is to implement it as cron job that
would pull a git repository, perhaps it would also run a script (git hook) that
would restart a daemon or do something of that kind.

I suppose that some people will suggest to just use packages, but I'm not very
keen on maintaining a package repository on some sever out in the internet that
would be one big single point of failure. Although, perhaps, on some occasion,
this may be the only way.
Another reason why I wouldn't like to use git to manage configuration, as that
way all configs are going to be at hand from one directory tree, which is, IMO,
much quicker to manage and validate rather then a recipes spread across
subdirectories.


There are different systems out there that need to be managed (as well as 
different philosophies of how to manage them.)  Solving all of the problems 
isn't going to work.  Solving a specific problem has a chance.  :)


It's fairly typical that a device can be maintained as files, packages, or 
filesystem images.  Each of those approaches requires a very different 
upgrade/maintenance mechanism.  In addition since embedded systems do not have 
an admin console, if they fail during the upgrade process you can brick a user, 
so a fail safe is almost always required!


In each of the above methods, you can do things like transfer an individual file 
(or files) and related reset commands after an upgrade has occurred.. send up a 
package (or packages) and automate that -- or even upgrade the filesystem, but 
in each of these cases bandwidth may be at a premium.  Most field upgrade 
systems want a "delta" (diff) based system, where only the changes have to be 
sent, not the whole file.



Firstly, I'd appreciate any feedback on this!

And I do have a few rather more specific questions ;)



a) How often OE users do not implement any system updates over the wire in their
products, although the product is able to access the internet?


Due to the complexity of upgrading, this is fairly typical on embedded systems 
in my experience...but it's being tolerated less and less over time.  (They 
usually have some kind of an upgrade mechanism, they just don't do it over the 
internet.)



b) Has anyone here use the configuration tools like puppet, chef or cfendgine
and understands the benefits?

c) Has anyone succeeded building git without having to include perl on the
target? I'd probably get ways with just a subset of git commands.
I have also had a look at libgit2, but not sure if I'd be able to implement
something as robust as git itself with libgit2...


Last time I looked (a few months back) it was not possible to build a functional 
git system w/o perl -- or at least I wasn't able to.  I hope this continues to 
get better, as perl is -very- heavy weight for an embedded system.



So if you want the ultimate works for everyone system.. it really needs to be a 
field upgrade tool of some kind.  Basically providing the infrastructure to 
push/pull the update, a way to use a delta of the update to what is already 
installed on the device to construct the "file" to save bandwidth, a way to 
apply the update and control the associated behavior.  Then people can use that 
to implement file, package or image based upgrades... fail safe behavior is also 
usually device specific and would be implemented based on the toolkit.




Cheers,
--
Ilya



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



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

[yocto] [meta-intel][PATCH] layer.conf: Use .= for adding to BBPATH and += to BBFILES

[Khem Raj]

Fixes parsing errors which is appearing after this commit to
meta-openembedded

http://cgit.openembedded.org/meta-openembedded/commit/?id=3c21a46020bd0816579648f684c41dbd6333583e

This triggers
exception NameError: name 'base_contains' is not defined
without this change

Signed-off-by: Khem Raj 
---
 conf/layer.conf|4 ++--
 meta-cedartrail/conf/layer.conf|4 ++--
 meta-chiefriver/conf/layer.conf|4 ++--
 meta-crownbay/conf/layer.conf  |4 ++--
 meta-crystalforest/conf/layer.conf |4 ++--
 meta-emenlow/conf/layer.conf   |4 ++--
 meta-fri2/conf/layer.conf  |4 ++--
 meta-jasperforest/conf/layer.conf  |4 ++--
 meta-n450/conf/layer.conf  |4 ++--
 meta-nuc/conf/layer.conf   |4 ++--
 meta-romley/conf/layer.conf|4 ++--
 meta-sugarbay/conf/layer.conf  |4 ++--
 meta-sys940x/conf/layer.conf   |4 ++--
 meta-tlk/conf/layer.conf   |4 ++--
 14 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index e9c2b10..31132ab 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"
 
 # We have recipes-* directories, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/common/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/common/recipes-*/*/*.bb \
 ${LAYERDIR}/common/recipes-*/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "intel"
diff --git a/meta-cedartrail/conf/layer.conf b/meta-cedartrail/conf/layer.conf
index c19c4c1..0166b35 100644
--- a/meta-cedartrail/conf/layer.conf
+++ b/meta-cedartrail/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"
 
 # We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "cedartrail"
diff --git a/meta-chiefriver/conf/layer.conf b/meta-chiefriver/conf/layer.conf
index 5dc3c02..6164f99 100644
--- a/meta-chiefriver/conf/layer.conf
+++ b/meta-chiefriver/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"
 
 # We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "chiefriver"
diff --git a/meta-crownbay/conf/layer.conf b/meta-crownbay/conf/layer.conf
index cb17298..e6cc2a0 100644
--- a/meta-crownbay/conf/layer.conf
+++ b/meta-crownbay/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"
 
 # We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "crownbay"
diff --git a/meta-crystalforest/conf/layer.conf 
b/meta-crystalforest/conf/layer.conf
index 6b802d6..daa2ba7 100644
--- a/meta-crystalforest/conf/layer.conf
+++ b/meta-crystalforest/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"
 
 # We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "crystalforest"
diff --git a/meta-emenlow/conf/layer.conf b/meta-emenlow/conf/layer.conf
index a49ec47..b5832e4 100644
--- a/meta-emenlow/conf/layer.conf
+++ b/meta-emenlow/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"
 
 # We have recipes-* directories, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "emenlow"
diff --git a/meta-fri2/conf/layer.conf b/meta-fri2/conf/layer.conf
index 4d140f9..0bb29a1 100644
--- a/meta-fri2/conf/layer.conf
+++ b/meta-fri2/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"
 
 # We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "fri2"
diff --git a/meta-jasperforest/conf/layer.conf 
b/meta-jasperforest/conf/layer.conf
index 09f1647..b539733 100644
--- a/meta-jasperforest/conf/layer.conf
+++ b/meta-jasperforest/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have 

[yocto] Where does the 'PN' is set.

[Biao]

Hi,


In meta/conf/documentation.conf
PN[doc] = "PN holds the name of the package (Package Name). It is gathered from 
the bitbake-file filename"


I would like to know where does the so-called 'gather' exactly happens?
For example, does it mean the bitbake core get the 'PN = u-boot' by cutting of 
the name of 'u-boot_2011.03.bb'?


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

[yocto] [meta-mono][PATCH] layer.conf: Use .= for adding to BBPATH and += to BBFILES

[Khem Raj]

Fixes parsing errors which is appearing after this commit to
meta-openembedded

http://cgit.openembedded.org/meta-openembedded/commit/?id=3c21a46020bd0816579648f

This triggers
exception NameError: name 'base_contains' is not defined
without this change

Signed-off-by: Khem Raj 
---
 conf/layer.conf |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 6bcf70e..d8cc797 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -1,8 +1,8 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH := "${BBPATH}:${LAYERDIR}"
+BBPATH .= ":${LAYERDIR}"
 
 # We have a recipes directory, add to BBFILES
-BBFILES := "${BBFILES} ${LAYERDIR}/recipes-mono/*/*.bb \
+BBFILES += "${LAYERDIR}/recipes-mono/*/*.bb \
 ${LAYERDIR}/recipes-mono/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "mono"
-- 
1.7.9.5

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