[yocto] [Package Report System]Manual check recipes name list

2013-04-20 Thread Yocto Project Package Report System
This mail was sent out by Package Report System.
It will list all the recipes which can't check upstream version by script, and 
will show how long it is since their last mannual version check.
You can check the detail information at 
http://packages.yoctoproject.org/manuallychkinfo


PackageName  Version LastChkVersion  LastChkTime
  Maintainer  NoUpgradeReason   
tinylogin1.4 1.4 230 day
  Radu Moisan  
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] [Package Report System]Upgrade recipes name list

2013-04-20 Thread Yocto Project Package Report System
This mail was sent out by Package Report System.
This message list those recipes which need to be upgraded. If maintainers 
believe some of them needn't to upgrade this time, they can fill in 
RECIPE_NO_UPDATE_REASON_pn-"xxx" in upstream_tracking files to ignore this 
recipe remainder until newer upstream version was detected.
Example:
RECIPE_NO_UPDATE_REASON_pn-"xxx" = "Not upgrade to 2.0 because the new version 
is unstable"
You can check the detail information at 
http://packages.yoctoproject.org/upgradepkgname


PackageName   Version   UpVersion   
  MaintainerNoUpgradeReason 
  
lsb   4.1   1.4 
  Yi Zhao
ccache3.1.8 3.1.9   
  Wenzong Fan
gettext   0.18.20.18.2.1
  Wenzong Fan
lsbinitscripts9.45  9.46
  Saul Wold
libcheck  0.9.9 0.9.10  
  Saul Wold
mesa-demos8.0.1 8.1.0   
  Saul Wold
nspr  4.9.5 4.9.6   
  Saul Wold
cups  1.6.1 1.6.2   
  Saul Wold
pkgconfig 0.25  0.28
  Saul Woldremoves glib-conf, 
adds circu...
kconfig-frontends 3.8.0 3.8.0.0 
  Saul Wold
dpkg  1.16.91.16.10 
  Saul Wold
glib-networking   2.28.72.36.1  
  Saul Wold
createrepo0.4.110.9.9   
  Saul WoldVersions after 
0.9.* use YUM,...
vte   0.28.20.34.4  
  Saul Wold
libgcrypt 1.5.0 1.5.2   
  Saul Wold
libxkbcommon  0.2.0 0.3.0   
  Saul Wold
sysstat   10.1.410.1.5  
  Saul Wold
resolvconf1.70  1.71
  Saul Wold
libxml2   2.9.0 2.9.1   
  Saul Wold
oprofileui-server 0.0+gitAUTOINC+82ecf8c
0.0+gitAUTOINC+f168b8bSaul Wold   
 
texinfo   4.13a 5.1 
  Saul WoldChecking script 
parses direct...
sqlite3   3071502   3071602 
  Saul Wold
build-appliance-image 1.0   8.0.1   
  Saul Wold
dhcp  4.2.5 4.2.5-P1
  Saul Wold
less  457   458 
  Saul Wold
file  5.13  5.14
  Saul Wold
libffi3.0.113.0.13  
  Saul Wold
mtdev 1.1.2 1.1.3   
  Ross Burton
busybox   1.20.21.21.0  
  Radu Moisan
iputils   s20101006 s20121221   
  Radu Moisan
dropbear  2012.55   2013.58 
  Radu Moisan
unzip 6.0   60  
  Radu Moisan
elfutils  0.148 1.7.4   
  Radu Moisan
rxvt-unicode  9.17  9.18
  Radu Moisan
zip   3.0   30  
  Radu Moisan

Re: [yocto] [meta-raspberrypi][PATCH] Fix FILESEXTRAPATHS, dir is "netbase-5.0"

2013-04-20 Thread Andrei Gherzan
On Sat, Apr 20, 2013 at 4:05 PM, Paul Barker  wrote:

> On 19 April 2013 17:23, Saul Wold  wrote:
> > Just another note about the netbase, for 1.4 the interfaces file moved to
> > init-ifupdown, so that file should move to a new recipe with bbappends
> for
> > init-ifupdown-1.0.
> >
> > We just fixed meta-yocto for the beagleboard  in the final 1.4 release.
> >
>
> Ok, had a look at this now.
>
> As originally pointed out by Robert, the hosts and interfaces files
> are not picked up as the wrong directory is named in
> netbase_5.0.bbappend. However, the image I've just built works fine
> with the stock files in openembedded-core. Both eth0 and lo interfaces
> come up fine. Other interfaces listed in the stock files don't have an
> "auto" line so no attempt is made to bring them up at boot.
>
> If we look at the interfaces file in meta-raspberrypi
> (
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/recipes-core/netbase/netbase-5.0/raspberrypi/interfaces
> ),
> it doesn't even list eth0 so I can't see how it would work.
>
> The hosts file (
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/recipes-core/netbase/netbase-5.0/raspberrypi/hosts
> )
> just adds the names 'raspberrypi' and 'rpi' as aliases for localhost,
> which I don't see the purpose of myself.
>
> So I'd recommend dropping these from meta-raspberrypi completely. Just
> my opinion though, anyone else got any thoughts on this?
>
>
Hello guys. Probably dropping would be the best thing here. I don't think
that the issue is reproduced anymore with netbase on rpi. If you submit
patch I can give it a try.

-- 
*Andrei Gherzan*
m: +40.744.478.414 |  f: +40.31.816.28.12
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


[yocto] busy Box error

2013-04-20 Thread Alexander Keller
Hello, 

 

When I was trying to build yocto for the i.mx6, there was an error building
busybox. The error when building busbox was

 

| DEBUG: Executing python function sysroot_cleansstate

| DEBUG: Python function sysroot_cleansstate finished

| DEBUG: Executing shell function do_configure

| trap: 80: SIGHUP: bad trap

 

Does anyone have any ideas to fix this error?

 

-Alexander 

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


Re: [yocto] clarification about BSP layer names and bblayers.conf file?

2013-04-20 Thread Tom Zanussi
On Sat, 2013-04-20 at 05:35 -0400, Robert P. J. Day wrote:
> On Fri, 19 Apr 2013, Tom Zanussi wrote:
> 
> > On Fri, 2013-04-19 at 08:37 -0400, Robert P. J. Day wrote:
> >
> > >   second, the BBLAYERS example there seems overly complicated and
> > > potentially confusing to beginners. the fact that meta-yocto is listed
> > > as NON_REMOVABLE might make readers wonder how they're supposed to
> > > know that. why not go with something a lot more people will see, like,
> > > say:
> > >
> > >  BBLAYERS = ?" \  <-- and that looks like a typo
> > >/usr/local/src/yocto/meta \
> > >/usr/local/src/yocto/meta-ti \
> > >"
> > >
> > >  BBLAYERS_NON_REMOVABLE ?= " \
> > >/usr/local/src/yocto/meta \
> > >"
> > >
> >
> > I agree - the whole NON_REMOVABLE thing doesn't add anything and should
> > be removed - the example is just trying to show how to add a BSP layer -
> > the rest just adds potential confusion.  And, yeah, it's a typo..
> 
>   i'll let someone else decide what to do there.
> 
> > >   finally, the passing reference to layers that contain sub-BSP-layers
> > > is good, but show an example, such as the fact that the meta-crownbay
> > > layer.conf file has a dependency on meta-intel:
> > >
> > > ...
> > > LAYERDEPENDS_crownbay = "intel"
> > >
> > >   never pass up the opportunity to reinforce an idea with a few lines
> > > of actual code. :-)
> > >
> >
> > Agreed, but on the other hand we don't really want to be too
> > intel-specific (I know, we have crownbay everywhere else, but anyway..)
> 
>   i was just looking for an example of the kind of hierarchical layer
> structure you find in meta-intel. is there another layer that has that
> kind of structure?
> 

A quick scan of all the layers I have opengrokked here doesn't show any
either, so possibly meta-intel is currently the only example.  If so,
let's use it..

Tom

> rday
> 


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


Re: [yocto] [meta-raspberrypi][PATCH] Fix FILESEXTRAPATHS, dir is "netbase-5.0"

2013-04-20 Thread Paul Barker
On 19 April 2013 17:23, Saul Wold  wrote:
> Just another note about the netbase, for 1.4 the interfaces file moved to
> init-ifupdown, so that file should move to a new recipe with bbappends for
> init-ifupdown-1.0.
>
> We just fixed meta-yocto for the beagleboard  in the final 1.4 release.
>

Ok, had a look at this now.

As originally pointed out by Robert, the hosts and interfaces files
are not picked up as the wrong directory is named in
netbase_5.0.bbappend. However, the image I've just built works fine
with the stock files in openembedded-core. Both eth0 and lo interfaces
come up fine. Other interfaces listed in the stock files don't have an
"auto" line so no attempt is made to bring them up at boot.

If we look at the interfaces file in meta-raspberrypi
(http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/recipes-core/netbase/netbase-5.0/raspberrypi/interfaces),
it doesn't even list eth0 so I can't see how it would work.

The hosts file 
(http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/recipes-core/netbase/netbase-5.0/raspberrypi/hosts)
just adds the names 'raspberrypi' and 'rpi' as aliases for localhost,
which I don't see the purpose of myself.

So I'd recommend dropping these from meta-raspberrypi completely. Just
my opinion though, anyone else got any thoughts on this?

--
Paul Barker

Email: p...@paulbarker.me.uk
http://www.paulbarker.me.uk
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] clarification about BSP layer names and bblayers.conf file?

2013-04-20 Thread Robert P. J. Day
On Fri, 19 Apr 2013, Tom Zanussi wrote:

> On Fri, 2013-04-19 at 08:37 -0400, Robert P. J. Day wrote:
>
> >   second, the BBLAYERS example there seems overly complicated and
> > potentially confusing to beginners. the fact that meta-yocto is listed
> > as NON_REMOVABLE might make readers wonder how they're supposed to
> > know that. why not go with something a lot more people will see, like,
> > say:
> >
> >  BBLAYERS = ?" \  <-- and that looks like a typo
> >/usr/local/src/yocto/meta \
> >/usr/local/src/yocto/meta-ti \
> >"
> >
> >  BBLAYERS_NON_REMOVABLE ?= " \
> >/usr/local/src/yocto/meta \
> >"
> >
>
> I agree - the whole NON_REMOVABLE thing doesn't add anything and should
> be removed - the example is just trying to show how to add a BSP layer -
> the rest just adds potential confusion.  And, yeah, it's a typo..

  i'll let someone else decide what to do there.

> >   finally, the passing reference to layers that contain sub-BSP-layers
> > is good, but show an example, such as the fact that the meta-crownbay
> > layer.conf file has a dependency on meta-intel:
> >
> > ...
> > LAYERDEPENDS_crownbay = "intel"
> >
> >   never pass up the opportunity to reinforce an idea with a few lines
> > of actual code. :-)
> >
>
> Agreed, but on the other hand we don't really want to be too
> intel-specific (I know, we have crownbay everywhere else, but anyway..)

  i was just looking for an example of the kind of hierarchical layer
structure you find in meta-intel. is there another layer that has that
kind of structure?

rday

-- 


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

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

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