from:"Frans Meulenbroeks"

2011/7/20 Phil Blundell ph...@gnu.org

 Since updating this morning I'm getting

 | ERROR: Function 'File: '/home/pb/sources/libiconv-1.13.1.tar.gz' has
 md5 checksum 7ab33ebd26687c744a37264a330bbe9a when
 d42b97f6ef5dd0ba4469d520ed732fed was expected (from URL:
 'ftp://ftp.gnu.org/gnu/libiconv/libiconv-1.13.1.tar.gz')' failed
 NOTE: package libiconv-1.13.1-r0: task do_fetch: Failed

 The offending commit appears to be
 bd1e627bef29830f9346b4b984905fd8fcf2e716.  As far as I can tell from a
 quick inspection of the files, the checksum that was added for
 libiconv-1.13.1.tar.gz in that commit is actually the md5sum of the
 earlier version 1.11.1.

 This seems to indicate that the added 1.13.1 recipe has not been build by
neither the submitter nor the committer (let alone tested by someone).
is that the kind of quality we want to achieve in oe-core ?

Frans.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] libiconv checksum wrong

2011/7/20 Khem Raj raj.k...@gmail.com

On 07/20/2011 04:55 AM, Frans Meulenbroeks wrote:

2011/7/20 Phil Blundellph...@gnu.org

Since updating this morning I'm getting

| ERROR: Function 'File: '/home/pb/sources/libiconv-1.**13.1.tar.gz' has
md5 checksum 7ab33ebd26687c744a37264a330bbe**9a when
d42b97f6ef5dd0ba4469d520ed732f**ed was expected (from URL:
'ftp://ftp.gnu.org/gnu/**libiconv/libiconv-1.13.1.tar.**gz'ftp://ftp.gnu.org/gnu/libiconv/libiconv-1.13.1.tar.gz%27)'
failed
NOTE: package libiconv-1.13.1-r0: task do_fetch: Failed

The offending commit appears to be
bd1e627bef29830f9346b4b984905f**d8fcf2e716. As far as I can tell from a
quick inspection of the files, the checksum that was added for
libiconv-1.13.1.tar.gz in that commit is actually the md5sum of the
earlier version 1.11.1.

This seems to indicate that the added 1.13.1 recipe has not been build by

neither the submitter nor the committer (let alone tested by someone).
is that the kind of quality we want to achieve in oe-core ?

there is already patch sent to fix it.
http://patches.openembedded.**org/patch/7933/http://patches.openembedded.org/patch/7933/
libiconv is not default provider of virtual/libiconv on eglibc/glibc based
systems and sometimes that can trip you over. It happens and as long as we
find it and fix it quickly I don't see a problem. Do you ?

Some people seem to think differently about this. I still recall the pile of
shit Koen dumped upon me about a year ago when I accidentally removed a
version of openssh or so that was still used. Even though the problem was
fixed very quickly after it was brought to my attention. Ah well. As Orwell
already said all animals are equal but some animals are more equal than
others.

IMO we should not get so pedantic that people start getting scared of
making changes

It was by no means my intention to be pedantic.

Then again I *do* think it is good practice if someone creates a new recipe
that (s)he tests it before submitting it.

And my impression was that one of the goals of YP and oe-core was to
increase the quality level.
One of the ways to increase quality is to do a build after pulling changes
and before committing them.
(at least I feel that is one of the ways to increase quality, and yes there
are other ways too).

And where people work, mistakes happen. One can accept that, but one can
also see if there are ways to improve and avoid that a problem re-occurs.

My two cents. Do with it whatever you want. And remember: have fun!

Frans.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] libiconv checksum wrong

2011/7/20 Richard Purdie richard.pur...@linuxfoundation.org

 On Wed, 2011-07-20 at 16:26 +0200, Frans Meulenbroeks wrote
  there is already patch sent to fix it.
  http://patches.openembedded.org/patch/7933/
  libiconv is not default provider of virtual/libiconv on
  eglibc/glibc based systems and sometimes that can trip you
  over. It happens and as long as we find it and fix it quickly
  I don't see a problem. Do you ?
  Some people seem to think differently about this. I still recall the
  pile of shit Koen dumped upon me about a year ago when I accidentally
  removed a version of openssh or so that was still used. Even though
  the problem was fixed very quickly after it was brought to my
  attention. Ah well. As Orwell already said all animals are equal but
  some animals are more equal than others.
 
 
  IMO we should not get so pedantic that people start getting
  scared of making changes
 
  It was by no means my intention to be pedantic.
 
  Then again I *do* think it is good practice if someone creates a new
  recipe that (s)he tests it before submitting it.
 
  And my impression was that one of the goals of YP and oe-core was to
  increase the quality level.
  One of the ways to increase quality is to do a build after pulling
  changes and before committing them.
  (at least I feel that is one of the ways to increase quality, and yes
  there are other ways too).
 
  And where people work, mistakes happen. One can accept that, but one
  can also see if there are ways to improve and avoid that a problem
  re-occurs.

 I think its fair to ask how this happened and it appears to be due to
 PREFERRED_VERSION and/or PROVIDER confusion. Its unfortunate but I think
 the people involved will not do it again :).

 I don't think its entirely fair to immediately bring into question the
 overall quality goals as we are continuing to work towards those and
 this is an exception, not the norm.

 Cheers,

 Richard, Saul, all,

I understand that these things can happen. It is a pretty basic mistake, but
I made my share of those as well. Unfortunately some community members were
not too forgiving in those situations :-(
I feel as long as those mistakes lead to improvement of the process and we
learn from it, I have no problem with it (and I'm sure this has happened in
this case).
What slightly irridated me was the email of Khem which stated as long as we
find it and fix it quickly I don't see a problem. I'm not sure if that is
the most desirable way of working, and definitely not a statement I had
expected from a TSC member.

Wrt commits: in the past I have been picking up oe postings from other
people without commit access and commit these for them. When I did that I
always made sure to review and to build the changed or new recipe.
I think that is good practice. Now I know that a lot of patches are being
thrown to Richard, so this might not be too workable to do it that way. It
could help though to do some automated tests after taking patches and before
pushing to the oe-core repo. (ideally it would be an (incremental?) build of
world (if there is a bitbake world in YP, actually never attempted that, but
I can also imagine a fetchall or so).

And yeah, on reading back maybe I should have formulated things a little bit
more diplomatic.

Frans.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 03/10] intltool: inherit perlnative

General remark:

I suspect lots of recipes depend on perl if only in their configure scripts.
I guess doing per-patckage staging could improve the visibility of this.

Also wrt /usr/bin/env perl:
I haven't peeked into the source of env, but ideally non-native recipes
should maybe not rely on host packages, only on the ones we build.
E.g. no /usr/bin in PATH wehn building these (and yes, I know that is not
trivial and will trigger some bugs and it also does not help against hard
coded paths, and probalby some progs will cause a pain (e.g. /bin/sh)).
Maybe a chrooted system would be better, but I vaguely recall that this was
once discussed (and presumably rejected).

Another thing we could do is have  our own env program which (in this case)
does not return a path to perl if the native package is not there (and
thereby causing things to fail instead of silently using the host perl).

Have fun!
Frans.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/8] Bug Fixes for M2 Rc2

2011-07-08 Thread Frans Meulenbroeks

2011/7/8 Saul Wold s...@linux.intel.com

 Richard,

 This address the bash, xcb missing from libx11, locale issue and
 the lack of space due to zypper eating space.


I don't think all the dependencies on bash are needed.

E.g:  eglibc: Add RDEPENDS on bash
eglibc itself does not need bash to be present at runtime (or maybe only in
some eglibc configurations).
I am currently happily running an eglibc system with busybox sh without any
problem at all.
Footprintwise for embedded systems that is desirable and as such it is quite
a common setup.

Frans.




 Sau!


 The following changes since commit
 f1fc6d084b079dea21ff1a30b815496452042490:

  pulseaudio: add 0.9.23 (2011-07-07 13:44:36 +0100)

 are available in the git repository at:
  git://git.openembedded.org/openembedded-core-contrib sgw/fix

 http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/fix

 Saul Wold (8):
  rootfs_rpm: Add 50Meg to image size for zypper
  image.bbclass: add LINGUAS_INSTALL to depends list
  gnome-doc-utils: Add RDEPENDS on bash
  quilt: Add RDEPENDS on bash
  console-tools: Add RDEPENDS on bash
  usbutils: Add RDEPENDS on bash
  eglibc: Add RDEPENDS on bash
  libx11: enable xcb support

  meta/classes/image.bbclass |2 +-
  meta/classes/image_types.bbclass   |2 +-
  meta/classes/rootfs_rpm.bbclass|5 +
  meta/recipes-bsp/usbutils/usbutils_0.91.bb |5 +++--
  .../console-tools/console-tools_0.3.2.bb   |3 ++-
  meta/recipes-core/eglibc/eglibc-package.inc|2 +-
  meta/recipes-core/eglibc/eglibc.inc|2 +-
  meta/recipes-core/eglibc/eglibc_2.12.bb|2 +-
  meta/recipes-core/eglibc/eglibc_2.13.bb|2 +-
  meta/recipes-devtools/quilt/quilt.inc  |2 ++
  meta/recipes-devtools/quilt/quilt_0.48.bb  |2 +-
  meta/recipes-gnome/gnome/gnome-doc-utils.inc   |2 ++
  meta/recipes-gnome/gnome/gnome-doc-utils_0.20.6.bb |2 +-
  meta/recipes-graphics/xorg-lib/libx11_1.3.4.bb |   11 ---
  14 files changed, 30 insertions(+), 14 deletions(-)

 --
 1.7.3.4


 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 7/8] eglibc: Add RDEPENDS on bash

2011-07-08 Thread Frans Meulenbroeks

2011/7/8 Saul Wold s...@linux.intel.com

 [YOCTO #1214]

 Signed-off-by: Saul Wold s...@linux.intel.com
 ---
  meta/recipes-core/eglibc/eglibc-package.inc |2 +-
  meta/recipes-core/eglibc/eglibc.inc |2 +-
  meta/recipes-core/eglibc/eglibc_2.12.bb |2 +-
  meta/recipes-core/eglibc/eglibc_2.13.bb |2 +-
  4 files changed, 4 insertions(+), 4 deletions(-)

 diff --git a/meta/recipes-core/eglibc/eglibc-package.inc
 b/meta/recipes-core/eglibc/eglibc-package.inc
 index 1c6626c..f0fac76 100644
 --- a/meta/recipes-core/eglibc/eglibc-package.inc
 +++ b/meta/recipes-core/eglibc/eglibc-package.inc
 @@ -69,7 +69,7 @@ FILES_eglibc-utils = ${bindir}/* ${sbindir}/*
  FILES_${PN}-dbg += ${libexecdir}/*/.debug ${libdir}/audit/.debug
  FILES_catchsegv${PKGSUFFIX} = ${bindir}/catchsegv
  RDEPENDS_catchsegv${PKGSUFFIX} = libsegfault
 -EDEPENDS_eglibc-utils = libsotruss
 +RDEPENDS_eglibc-utils += libsotruss bash
  FILES_eglibc-pcprofile = ${base_libdir}/libpcprofile.so
  FILES_eglibc-thread-db${PKGSUFFIX} = ${base_libdir}/libthread_db*
  RPROVIDES_eglibc-dev += libc-dev
 diff --git a/meta/recipes-core/eglibc/eglibc.inc
 b/meta/recipes-core/eglibc/eglibc.inc
 index 74afb9d..058d58e 100644
 --- a/meta/recipes-core/eglibc/eglibc.inc
 +++ b/meta/recipes-core/eglibc/eglibc.inc
 @@ -22,7 +22,7 @@ siteconfig_do_siteconfig_gencache_prepend =  \
  # nptl needs unwind support in gcc, which can't be built without glibc.
  DEPENDS = virtual/${TARGET_PREFIX}gcc-intermediate linux-libc-headers
  #this leads to circular deps, so lets not add it yet
 -#RDEPENDS_ldd +=  bash
 +RDEPENDS_ldd +=  bash


Ah ok, now see that this is only for ldd.
In that case the commit message is misleading. (and probably also not
conformant with the commit message policy).

Frans


  # nptl needs libgcc but dlopens it, so our shlibs code doesn't detect this
  #RDEPENDS_${PN} += ${@['','libgcc']['nptl' in '${GLIBC_ADDONS}']}
  PROVIDES = virtual/libc virtual/${TARGET_PREFIX}libc-for-gcc
 diff --git 
 a/meta/recipes-core/eglibc/eglibc_2.12.bbb/meta/recipes-core/eglibc/
 eglibc_2.12.bb
 index 85d58fa..fd7b485 100644
 --- a/meta/recipes-core/eglibc/eglibc_2.12.bb
 +++ b/meta/recipes-core/eglibc/eglibc_2.12.bb
 @@ -1,7 +1,7 @@
  require eglibc.inc

  DEPENDS += gperf-native
 -PR = r18
 +PR = r19

  SRCREV = 14158

 diff --git 
 a/meta/recipes-core/eglibc/eglibc_2.13.bbb/meta/recipes-core/eglibc/
 eglibc_2.13.bb
 index 7986131..be65787 100644
 --- a/meta/recipes-core/eglibc/eglibc_2.13.bb
 +++ b/meta/recipes-core/eglibc/eglibc_2.13.bb
 @@ -4,7 +4,7 @@ SRCREV = 14157

  DEPENDS += gperf-native
  FILESPATHPKG =. eglibc-svn:
 -PR = r5
 +PR = r6
  PR_append = +svnr${SRCPV}

  EGLIBC_BRANCH=eglibc-2_13
 --
 1.7.3.4


 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 7/8] eglibc: Add RDEPENDS on bash

2011-07-08 Thread Frans Meulenbroeks

2011/7/8 Koen Kooi k...@dominion.thruhere.net



 Op 8 jul. 2011 om 07:53 heeft Frans Meulenbroeks 
 fransmeulenbro...@gmail.com het volgende geschreven:


 -#RDEPENDS_ldd += bash
 +RDEPENDS_ldd += bash


 Ah ok, now see that this is only for ldd.
 In that case the commit message is misleading. (and probably also not
 conformant with the commit message policy).


 there's an ldd-unbash patch in . dev


 Seems to me that that is a better alternative then

Frans
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] libxml-parser-perl: convert to BBCLASSEXTEND, merge in OE fixes:wq

2011-07-02 Thread Frans Meulenbroeks

commit headers do not need to reveal that you are using vi :-)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] Proposal: recipe feature switches

2011/7/1 Richard Purdie richard.pur...@linuxfoundation.org

 On Thu, 2011-06-30 at 18:10 +0100, Chris Elston wrote:
  We're looking to base an embedded development on oe-core in the near
  future, and one of the things we must have is the ability to configure
  features in/out of recipes per distro.
 
  At the moment some recipes have a configuration / set of dependencies
  baked in to the recipe.  For example, gstreamer has theora, ogg and
  vorbis hard-coded in to it's EXTRA_OECONF and DEPENDS.  Currently, you'd
  have to override the DEPENDS and EXTRA_OECONF for the recipe in the
  distro layer - which means moving knowledge about what EXTRA_OECONF
  flags bring in which dependencies outside of the recipe.  It seems that
  this metadata is better contained in the recipe.
 
  I'm proposing something along the lines of the following:

 This is actually along the lines of what I've been thinking too!

  diff --git a/meta/classes/utils.bbclass b/meta/classes/utils.bbclass
  index 9930a24..4f1c54f 100644
  --- a/meta/classes/utils.bbclass
  +++ b/meta/classes/utils.bbclass
  @@ -84,6 +84,15 @@ def oe_system(d, cmd, **kwargs):
   kwargs[shell] = True
   return oe_popen(d, cmd, **kwargs).wait()
 
  +def oe_package_feature_switch(feature, switch_on, switch_off,
  dependencies, d):
  +oeconf = d.getVar(EXTRA_OECONF, True)
  +if feature in d.getVar(PACKAGE_FEATURES, True).split():
  +d.setVar(EXTRA_OECONF, oeconf +   + switch_on)
  +depends = d.getVar(DEPENDS, True)
  +d.setVar(DEPENDS, depends +   + dependencies)
  +else:
  +d.setVar(EXTRA_OECONF, oeconf +   + switch_off)
  +
   oe_soinstall() {
# Purpose: Install shared library file and
#  create the necessary links
  diff --git
  a/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
  b/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
  index f81011f..6fc6405 100644
  --- a/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
  +++ b/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
  @@ -6,10 +6,12 @@ LIC_FILES_CHKSUM =
  file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
 
  file://COPYING.LIB;md5=55ca817ccb7d5b5b66355690e9abc605 \
 
 
 file://gst/ffmpegcolorspace/utils.c;beginline=1;endline=20;md5=9c83a200b8e597b26ca29df20fc6ecd0
 
  -DEPENDS += virtual/libx11 alsa-lib freetype gnome-vfs liboil libogg
  libvorbis libxv libtheora avahi util-linux tremor
  +DEPENDS += virtual/libx11 alsa-lib freetype gnome-vfs liboil libxv
  avahi util-linux tremor
   RDEPENDS_${PN} += gnome-vfs-plugin-file gnome-vfs-plugin-http
  gnome-vfs-plugin-ftp \
gnome-vfs-plugin-sftp
 
  +PACKAGE_FEATURES ?= ogg vorbis theora
  +
   SRC_URI +=  file://gst-plugins-base-tremor.patch
 
   SRC_URI[md5sum] = 2920af2b3162f3d9fbaa7fabc8ed4d38
  @@ -21,6 +23,12 @@ inherit gettext
 
   EXTRA_OECONF += --disable-freetypetest --disable-pango
 
  +python () {
  + oe_package_feature_switch(ogg, --enable-ogg, --disable-ogg,
  libogg, d)
  + oe_package_feature_switch(vorbis, --enable-vorbis,
  --disable-vorbis, libvorbis, d)
  + oe_package_feature_switch(theora, --enable-theora,
  --disable-theora, libtheora, d)
  +}
  +
   do_configure_prepend() {
# This m4 file contains nastiness which conflicts with libtool
 2.2.2
rm -f ${S}/m4/lib-link.m4
 
  Then in your layer, you could configure which plugins gstreamer should
  be built with like this:
 
  PACKAGE_FEATURES_pn-gst-plugins-base = ogg theora
 
  Or just filter out the package features that you don't want.
 
  With a little extra work, it would also be possible to check the list of
  package features a distro layer requests against those the recipe
  actually implements.  Then we could get an early warning when we pull
  oe-core and a recipe has stopped implementing a feature.

 How about something like the syntax for the recipe:

 PACKAGECONFIG[ogg] = --enable-ogg, --disable-ogg, libogg
 PACKAGECONFIG[vorbis] = --enable-vorbis, --disable-vorbis, libvorbis
 PACKAGECONFIG[theora] = --enable-theora, --disable-theora, libtheora

 and then in base.bbclass we can simply:

 for flag in (d.getVarFlags(PACKAGECONFIG) or {}):
manipulate DEPENDS/EXTRA_OECONF

 I'm also strongly tempted to tie this into the DISTRO_FEATURES variable
 instead of individual PACKAGE_FEATURES variables to make it clear how
 this is intended to be used.

 If we do this, we are going to need to exercise some measure of control
 as someone is going to want an enable/disable option for every config
 option for every package. How do we decide which make sense and which
 don't?

 Note that the more options you have, the more combinations there are to
 test and the less testing the system likely gets. I would therefore like
 to see some kind of natural pressure to only add very useful
 DISTRO_FEATURES. Maybe a criteria like it affecting 5 or more recipes?


Good idea.
Personally I'd like to also bring footprint

Re: [OE-core] Proposal: recipe feature switches

2011/7/1 Koen Kooi k...@dominion.thruhere.net


 Op 1 jul 2011, om 10:55 heeft Frans Meulenbroeks het volgende geschreven:

 
  Good idea.
  Personally I'd like to also bring footprint into the equation. If a
 feature drags in lots of additional packages, it is interesting to make it
 configurable.
  My favourite example: bluez dragging in all kind of rendering stuff
 (through DEPENDS) even though the hardware functionality might not be there
 (e.g. you have BT but not audio).

 Which is a great example, since that doesn't impact footprint at all, it's
 an alsa *plugin* that will get produced.


 bluez.inc:DEPENDS = gstreamer gst-plugins-base dbus glib-2.0

I don't think gstreamer is really needed or desired if you e.g. just want to
do some tethering over bluetooth, or in my case, connect to a BT HID, and
they do contribute to both the build time and the footprint.

Frans.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] Proposal: recipe feature switches

Oh by the way, and the message you might be see saying:

This message may not have been sent by: fransmeulenbro...@gmail.com Learn
more Report phishing

This is really google not having their stuff properly configured.
I'm sending email from their web client (https://mail.google.com/)
And yes, it is me :-)

Frans
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] Proposal: recipe feature switches

2011/7/1 Koen Kooi k...@dominion.thruhere.net


 Op 1 jul 2011, om 11:26 heeft Frans Meulenbroeks het volgende geschreven:

 
 
  2011/7/1 Koen Kooi k...@dominion.thruhere.net
 
  Op 1 jul 2011, om 10:55 heeft Frans Meulenbroeks het volgende geschreven:
 
  
   Good idea.
   Personally I'd like to also bring footprint into the equation. If a
 feature drags in lots of additional packages, it is interesting to make it
 configurable.
   My favourite example: bluez dragging in all kind of rendering stuff
 (through DEPENDS) even though the hardware functionality might not be there
 (e.g. you have BT but not audio).
 
  Which is a great example, since that doesn't impact footprint at all,
 it's an alsa *plugin* that will get produced.
 
 
  bluez.inc:DEPENDS = gstreamer gst-plugins-base dbus glib-2.0
 
  I don't think gstreamer is really needed or desired if you e.g. just want
 to do some tethering over bluetooth, or in my case, connect to a BT HID, and
 they do contribute to both the build time and the footprint.

 Again, a plugin, so no footprint issues.

 Well, as far as I know if it is in DEPENDS it will implicitly end up in
RDEPENDS and will become part of the image that contains bluez, unless
special precautions are taken, so it seems to me the image will grow as
plugins do consume space.

Anyway, my current project does not use or need bluez and I use a hand
crafted image picking only the things that I need so haven't really been
bitten by this recently.

Frans
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] PRIORITY

2011/7/1 Phil Blundell p...@pbcl.net

 On Fri, 2011-07-01 at 11:15 +0100, Richard Purdie wrote:
  On Fri, 2011-07-01 at 10:41 +0100, Phil Blundell wrote:
   We had some discussion of this a few weeks ago but I'm not sure it ever
   reached a firm conclusion.
  
   Is everyone agreed that the PRIORITY variable does not serve any useful
   purpose in oe-core and can/should be removed from the recipes?
 
  I think that was the conclusion, yes. I'll take a patch (or a
  commandline I guess).

 I did:

 $ find . -regex .*\.\(bb\|inc\)$ | xargs sed -i '/^PRIORITY = .*$/d'

 which seemed to produce the desired results.  I can send a patch if you
 like but it would be somewhat large and fairly uninteresting.

 I'd suggest a regex that matches for any whitespace in order also to catch
things like:
./libgpevtype/libgpevtype_0.50.bb:PRIORITY= optional

Have fun! Frans
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] Multilib Development Update

2011-06-21 Thread Frans Meulenbroeks

As I already asked before: what is the benefit having this in embedded
systems?

If I am doing an embedded system I know the target hardware, and there is no
need to have e.g. both 32 and 64 bit libs.

Frans.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] Question about apply eglibc configurability to create minimal image

2011-06-09 Thread Frans Meulenbroeks

2011/6/9 Mark Hatle mark.ha...@windriver.com

 On 6/9/11 5:57 AM, Kang Kai wrote:
  Hi Mark,
 
  I am focus on eglibc itself compilation with disabling all the
  configurable options, right now eglibc can be compiled with disable all
  the configurable options.
 
  But when I build core-image-minimal in a clear new directory, some
  packages build failed and they need eglibc supports, such as

 core-image-minimal is simply to large of an image to see some of the
 advantages
 of the eglibc configuration.  Realistically the advantages come on single
 application or small (busybox + single application) systems.


Then again if you are in that usecase you're probably better off (spacewise)
using static linking

Frans
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/5] network based PR service

2011/5/19 Lianhao Lu lianhao...@intel.com

 From: Lianhao Lu lianhao...@intel.com

 This series of 5 patches implemented the network based PR service and
 enabled
 the poky to use it during the task do_package and do_package_write_xxx. By
 using the network based PR service and the basichash for
 BB_SIGNATURE_HANDLER,
 the poky user may not need to bump the PR manually everytime he/she changes
 the recipe. The package will get automatically rebuilt and new revision
 number
 reflecting the change will be included in the package feed.

 The first patch [PATCH 1/5] Added the PR service. implemented the network
 based PR service on the server side. It is a XMLRPC server with the sqlite3
 as the backend database. The users query an automated value from this
 service
 by giving  a tuple of (version, checksum). The returned value will
 be used as a part of the package revision value during the package feed
 creation process. The following algorihtm is used so this PR service could
 give
 multiple build servers new values for the new index tuple and same values
 for
 the same index tuple:

 IF the index tuple(version, checksum) is found,  THEN
return the value.
 ELSE
find the max value in the database with the same version.
increment it and save it into the database along with the index tuple.
return the incremented value.
(Note: If no matching version is found, save and return the value of 0).
 ENDIF

 To start the network based PR service daemon, run the following command
 after
 sourcing the environment file oe-init-build-env:

  bitbake-prserv --start

 See bitbake-prserv --help to see a detailed description of the options.

 The remaining 4 patches enable the poky to use the PR service. In order to
 use
 it, the user needs to set 2 varialbes of PRSERV_HOST and PRSERV_PORT (which
 specify the PR service ip address and port, default is localhost and
 8585
 respectively) in the file conf/local.conf under the building directory.
 Unsetting these 2 variables would disable the poky to use the PR service
 for
 backward compatibility.

 The following important new variables are introduced in bitbake.conf:

 PRFORMAT: The final value goes into the package revision. Default is
 something
 like PR.PRAUTO, where PRAUTO is the value returned by the PR service.

 PRAUTOINX: The version part of the index tuple for the PR service. Default
 is PF.
 The checksum of that tuple is the task checksum of do_package.

 Pull URL: git://git.pokylinux.org/poky-contrib.git
  Branch: llu/PR-service
  Browse:
 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=llu/PR-service

 Thanks,
Lianhao Lu lianhao...@intel.com
 ---


 Lianhao Lu (5):
  Added the PR service.
  conf/bitbake.conf: Added variables for PR service.
  classes/package(prserv).bbclass: Added PR service support.
  classes/package_xxx.class: Added PR service support.
  meta-yocto/local.conf.sample: Added PRSERV_HOST and PRSERV_PORT.

  bitbake/bin/bitbake-prserv|   53 ++
  bitbake/lib/prserv/__init__.py|   11 ++
  bitbake/lib/prserv/db.py  |  100 +++
  bitbake/lib/prserv/serv.py|  198
 +
  meta-yocto/conf/local.conf.sample |5 +
  meta/classes/package.bbclass  |   36 +--
  meta/classes/package_deb.bbclass  |6 +-
  meta/classes/package_ipk.bbclass  |6 +-
  meta/classes/package_rpm.bbclass  |4 +-
  meta/classes/package_tar.bbclass  |4 +-
  meta/classes/prserv.bbclass   |   29 ++
  meta/conf/bitbake.conf|   14 +++-
  12 files changed, 443 insertions(+), 23 deletions(-)
  create mode 100755 bitbake/bin/bitbake-prserv
  create mode 100644 bitbake/lib/prserv/__init__.py
  create mode 100644 bitbake/lib/prserv/db.py
  create mode 100644 bitbake/lib/prserv/serv.py
  create mode 100644 meta/classes/prserv.bbclass


 What should I do to either disable this for some recipes, or use a
different (private) server?
We do not wish to rely on an external server for proprietary recipes (or for
recipes for which we made a local change in an overlay).
How is this case handled?

Frans
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/5] network based PR service

2011/5/19 Richard Purdie richard.pur...@linuxfoundation.org

 On Thu, 2011-05-19 at 13:01 +0200, Frans Meulenbroeks wrote:
  What should I do to either disable this for some recipes, or use a
  different (private) server?
  We do not wish to rely on an external server for proprietary recipes (or
 for
  recipes for which we made a local change in an overlay).
  How is this case handled?

 This could be handled by doing things like setting:

 PRSERV_HOST_pn-myprivaterecipe = somelocalhost

 or

 PRSERV_HOST_pn-myprivaterecipe = 

 to disable it.

 One thing we lack is a good way to apply changes like this, only if code
 is within a given layer. Even in that case, it should be possible with
 anonymous python to look at the location of the current .bb file and
 then conditionally set these variables as appropriate to the right
 server.

 Certainly this needs to be thought about and documented but I think
 there are ways to do it.

 Pardon my ignorance, but I do not really understand the complete flow and
way of working.

Anyway if I do something like:
 PRSERV_HOST_pn-myprivaterecipe = 
would I still be able to use PR in my recipe (like I do today)?

Also we do have the issue that it is desired to be able to rebuild without
network connectivity (e.g. while temporary offline while travelling). Would
that still be possible?

For layers, one solution could be to allow variable overriding on the
overlay level. I can imagine there are more uses for that (and I understand
this requires changes to the bitbake machinery).

Frans.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/5] network based PR service

2011/5/19 Richard Purdie richard.pur...@linuxfoundation.org

 On Thu, 2011-05-19 at 14:02 +0200, Frans Meulenbroeks wrote:
  2011/5/19 Richard Purdie richard.pur...@linuxfoundation.org
 
   On Thu, 2011-05-19 at 13:01 +0200, Frans Meulenbroeks wrote:
What should I do to either disable this for some recipes, or use a
different (private) server?
We do not wish to rely on an external server for proprietary recipes
 (or
   for
recipes for which we made a local change in an overlay).
How is this case handled?
  
   This could be handled by doing things like setting:
  
   PRSERV_HOST_pn-myprivaterecipe = somelocalhost
  
   or
  
   PRSERV_HOST_pn-myprivaterecipe = 
  
   to disable it.
  
   One thing we lack is a good way to apply changes like this, only if
 code
   is within a given layer. Even in that case, it should be possible with
   anonymous python to look at the location of the current .bb file and
   then conditionally set these variables as appropriate to the right
   server.
  
   Certainly this needs to be thought about and documented but I think
   there are ways to do it.
  
   Pardon my ignorance, but I do not really understand the complete flow
 and
  way of working.
 
  Anyway if I do something like:
   PRSERV_HOST_pn-myprivaterecipe = 
  would I still be able to use PR in my recipe (like I do today)?

 Yes, since the PR server appends to this.

  Also we do have the issue that it is desired to be able to rebuild
 without
  network connectivity (e.g. while temporary offline while travelling).
 Would
  that still be possible?

 You could use a local PR server. Obviously connecting to one central
 server without any network connectivity isn't going to happen so we have
 to be realistic about expectations.

 To make a perfect rebuild the local PR server would need a dump of the
 database on the central server. There isn't code for that at the moment
 and I don't think its the highest priority task out there or the most
 important use case but its certainly possible for someone to add.


I'd say it would already be nice if some caching is being done locally (just
like is done with e.g. downloads).


  For layers, one solution could be to allow variable overriding on the
  overlay level. I can imagine there are more uses for that (and I
 understand
  this requires changes to the bitbake machinery).

 There is certainly a use case for something like this. The exact
 implementation and workings needs a lot more thought and discussion
 though. I believe its at least already possible in anonymous python (and
 if not, any extensions needed shouldn't be invasive by comparison).

 Hm. you consider this PR change to be non-invasive?

BTW I am not saying it is not good, and I understand the problem that you
want to solve, but I feel this could require some more thought wrt the
issues I raised before in this thread (and some more documentation and usage
info).

Frans.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] opkg-utils: Allow uppercase lettlers in package names