from:"Frans Meulenbroeks"

2012/3/11 Alex J Lennon ajlen...@dynamicdevices.co.uk:
 From: Alex J Lennon ajlen...@gmail.com

 Signed-off-by: Alex J Lennon ajlen...@gmail.com
 ---
  recipes/libpng/libpng_1.2.47.bb |    6 --
  recipes/libpng/libpng_1.2.48.bb |    6 ++
  2 files changed, 6 insertions(+), 6 deletions(-)
  delete mode 100644 recipes/libpng/libpng_1.2.47.bb
  create mode 100644 recipes/libpng/libpng_1.2.48.bb

 diff --git a/recipes/libpng/libpng_1.2.47.bb b/recipes/libpng/libpng_1.2.47.bb
 deleted file mode 100644
 index 8d594f1..000
 --- a/recipes/libpng/libpng_1.2.47.bb
 +++ /dev/null
 @@ -1,6 +0,0 @@
 -require libpng.inc
 -
 -PR = ${INC_PR}.0
 -
 -SRC_URI[libpng.md5sum] = 4389dab9fcd2f9d57ac14701b9115f59
 -SRC_URI[libpng.sha256sum] = 
 f0bfa4a33b419a61cf97935cd6a15f5cbda84d116c72fa4b3489b0605a00a7a2
 diff --git a/recipes/libpng/libpng_1.2.48.bb b/recipes/libpng/libpng_1.2.48.bb
 new file mode 100644
 index 000..50a3c03
 --- /dev/null
 +++ b/recipes/libpng/libpng_1.2.48.bb
 @@ -0,0 +1,6 @@
 +require libpng.inc
 +
 +PR = ${INC_PR}.0
 +
 +SRC_URI[libpng.md5sum] = 7612af5660cd4b5e8c433ce53bea01a7
 +SRC_URI[libpng.sha256sum] = 
 f6db51aff81b6920203678b29e8c68a5e3703cf5b39ae5e9e56370d17f31b1c4
 --
 1.7.5.4


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

Pushed, thanks.

I have this one pending for the maintenance branch too, but had
connectiivty problems yesterday

will submit that later

Frans

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

[oe] [2011.03-maintenance] [PATCH 2/2] libpng: moved from 1.2.44 to 1.2.48

upstream does not retain old versions so moved to the latest
version to make things buildable again

Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
---
 recipes/libpng/libpng_1.2.44.bb |8 
 recipes/libpng/libpng_1.2.48.bb |9 +
 2 files changed, 9 insertions(+), 8 deletions(-)
 delete mode 100644 recipes/libpng/libpng_1.2.44.bb
 create mode 100644 recipes/libpng/libpng_1.2.48.bb

diff --git a/recipes/libpng/libpng_1.2.44.bb b/recipes/libpng/libpng_1.2.44.bb
deleted file mode 100644
index 4ba7b20..000
--- a/recipes/libpng/libpng_1.2.44.bb
+++ /dev/null
@@ -1,8 +0,0 @@
-require libpng.inc
-
-PR = ${INC_PR}.0
-
-SRC_URI += file://makefile_fix.patch
-
-SRC_URI[libpng.md5sum] = e3ac7879d62ad166a6f0c7441390d12b
-SRC_URI[libpng.sha256sum] = 
b9ab20f1c2c3bf6c4448fd9bd8a4a8905b918114d5fada56c97bb758a17b7215
diff --git a/recipes/libpng/libpng_1.2.48.bb b/recipes/libpng/libpng_1.2.48.bb
new file mode 100644
index 000..7bd3ec3
--- /dev/null
+++ b/recipes/libpng/libpng_1.2.48.bb
@@ -0,0 +1,9 @@
+require libpng.inc
+
+PR = ${INC_PR}.0
+
+SRC_URI += file://makefile_fix.patch
+
+SRC_URI[libpng.md5sum] = 7612af5660cd4b5e8c433ce53bea01a7
+SRC_URI[libpng.sha256sum] = 
f6db51aff81b6920203678b29e8c68a5e3703cf5b39ae5e9e56370d17f31b1c4
+
-- 
1.7.0.4


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

[oe] [2011.03-maintenance] [PATCH 1/2] tzcode/tzdata: moved to 2012b; changed src location

elsie does not respond, so moved to ftp.iana.org (also used by oe-core)

Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
---
 recipes/tzcode/tzcode-native.inc  |6 +++---
 recipes/tzcode/tzcode-native_2011e.bb |   16 
 recipes/tzcode/tzcode-native_2012b.bb |   17 +
 recipes/tzdata/tzdata.inc |4 ++--
 recipes/tzdata/tzdata_2011b.bb|   11 ---
 recipes/tzdata/tzdata_2012b.bb|   11 +++
 6 files changed, 33 insertions(+), 32 deletions(-)
 delete mode 100644 recipes/tzcode/tzcode-native_2011e.bb
 create mode 100644 recipes/tzcode/tzcode-native_2012b.bb
 delete mode 100644 recipes/tzdata/tzdata_2011b.bb
 create mode 100644 recipes/tzdata/tzdata_2012b.bb

diff --git a/recipes/tzcode/tzcode-native.inc b/recipes/tzcode/tzcode-native.inc
index 78ddec5..94d1bd9 100644
--- a/recipes/tzcode/tzcode-native.inc
+++ b/recipes/tzcode/tzcode-native.inc
@@ -1,9 +1,9 @@
 DESCRIPTION = tzcode, timezone zoneinfo utils -- zic, zdump, tzselect
-INC_PR = r4
+INC_PR = r5
 
 SRC_URI =  \
-ftp://elsie.nci.nih.gov/pub/tzcode${PV}.tar.gz;name=tzcode-${PV} \
-
ftp://elsie.nci.nih.gov/pub/tzdata${TZDATA_PV}.tar.gz;name=tzdata-${TZDATA_PV} \
+   ftp://ftp.iana.org/tz/releases/tzcode${PV}.tar.gz;name=tzcode-${PV} \
+   
ftp://ftp.iana.org/tz/releases/tzdata${PV}.tar.gz;name=tzdata-${TZDATA_PV} \

 
 S = ${WORKDIR}
diff --git a/recipes/tzcode/tzcode-native_2011e.bb 
b/recipes/tzcode/tzcode-native_2011e.bb
deleted file mode 100644
index 2bf4f4c..000
--- a/recipes/tzcode/tzcode-native_2011e.bb
+++ /dev/null
@@ -1,16 +0,0 @@
-require tzcode-native.inc
-
-# Note that elsie.nci.nih.gov removes old versions when new is coming out
-# So if this doesn't build for you because of missing source file, just
-# bump it to the latest available version, removing old one
-# Also, tzdata (and it is needed to build tzcode) version can differ from
-# tzcode version, thus this variable
-
-TZDATA_PV = 2011e
-
-PR = ${INC_PR}.0
-
-SRC_URI[tzcode-2011e.md5sum] = fbfc05dbf9ebcfe7c4bba18549870173
-SRC_URI[tzcode-2011e.sha256sum] = 
8fb00f8763aa51d83d6f3190d144124bb7176ca829fc08823d6205297bf0426b
-SRC_URI[tzdata-2011e.md5sum] = 044a07072300a0ee72b046e5a9a4ec90
-SRC_URI[tzdata-2011e.sha256sum] = 
44fef01de4589a4979eb6b5fdbbfd21a3b135852af1ecbfb9e0368ae47392c79
diff --git a/recipes/tzcode/tzcode-native_2012b.bb 
b/recipes/tzcode/tzcode-native_2012b.bb
new file mode 100644
index 000..4d3477c
--- /dev/null
+++ b/recipes/tzcode/tzcode-native_2012b.bb
@@ -0,0 +1,17 @@
+require tzcode-native.inc
+
+# Note that elsie.nci.nih.gov removes old versions when new is coming out
+# So if this doesn't build for you because of missing source file, just
+# bump it to the latest available version, removing old one
+# Also, tzdata (and it is needed to build tzcode) version can differ from
+# tzcode version, thus this variable
+
+TZDATA_PV = 2012b
+
+PR = ${INC_PR}.0
+
+SRC_URI[tzcode-2012b.md5sum] = 6137322ffd36e1fd5128885be1c57008
+SRC_URI[tzcode-2012b.sha256sum] = 
4345a2de239a7b6e5ab286052cc269eb07d63798ae14ba715eb4c6bdfa0f3350
+SRC_URI[tzdata-2012b.md5sum] = 0615fd29def380a917e528433c820368
+SRC_URI[tzdata-2012b.sha256sum] = 
2f9f8e2d1ae087be5917f60c3946e8dc3fe1068d7738c3395f2125135309e745
+
diff --git a/recipes/tzdata/tzdata.inc b/recipes/tzdata/tzdata.inc
index dd5c2c9..af00d4c 100644
--- a/recipes/tzdata/tzdata.inc
+++ b/recipes/tzdata/tzdata.inc
@@ -3,7 +3,7 @@ SECTION = base
 PRIORITY = optional
 DEPENDS = tzcode-native
 
-INC_PR = r8
+INC_PR = r1
 
 DEFAULT_TIMEZONE ?= Europe/London
 
@@ -12,7 +12,7 @@ RCONFLICTS_${PN} = timezones timezone-africa 
timezone-america timezone-antarcti
  timezone-australia timezone-europe timezone-indian \
  timezone-iso3166.tab timezone-pacific timezone-zone.tab
 
-SRC_URI = ftp://elsie.nci.nih.gov/pub/tzdata${PV}.tar.gz;name=tar;
+SRC_URI = ftp://ftp.iana.org/tz/releases/tzdata${PV}.tar.gz;name=tar;
 
 S = ${WORKDIR}
 
diff --git a/recipes/tzdata/tzdata_2011b.bb b/recipes/tzdata/tzdata_2011b.bb
deleted file mode 100644
index 87ba619..000
--- a/recipes/tzdata/tzdata_2011b.bb
+++ /dev/null
@@ -1,11 +0,0 @@
-require tzdata.inc
-
-# Note that elsie.nci.nih.gov removes old archives when new is being
-# released. So if this doesn't build for you because of missing source file
-# just bump it to the latest available version, removing old one
-
-PR = ${INC_PR}.0
-
-SRC_URI[tar.md5sum] = 9eaf3ca354c42a32bd28e623539bf0e0
-SRC_URI[tar.sha256sum] = 
ff45f5ddc2ec925249626d00d7bc2587e0956a1d8245517a023bf27e4cc9
-
diff --git a/recipes/tzdata/tzdata_2012b.bb b/recipes/tzdata/tzdata_2012b.bb
new file mode 100644
index 000..8605331
--- /dev/null
+++ b/recipes/tzdata/tzdata_2012b.bb
@@ -0,0 +1,11 @@
+require tzdata.inc
+
+# Note that elsie.nci.nih.gov removes old archives when new is being
+# released. So if this doesn't build for you because of missing source file
+# just bump

Re: [oe] [PATCH] Replaced libpng 1.2.47 recipe with 1.2.48 as source tarball no longer available from SRC_URI

2012/3/11 Alex J Lennon ajlen...@dynamicdevices.co.uk:

 Pushed, thanks.


 No problem Frans. Out of interest I thought the build environment was
 supposed to
 fall back to an OE/Angstrom caching server to ensure this type of thing
 didn't happen
 when the primary sources disappeared?

This depends on conf files and specification of the mirrors.
I haven't really build angstrom for oe-classic; our latest product is
build around minimal
IMHO better configurability and dragging in less stuff I do not need.
The system I'm building for is quite resource constrainged.

Maybe the old sources are not in the mirror.
And often people do not discover this because the file is in the
downloads dir. I only noticed the libpng defect when I was building on
a different machine and didn't have our local mirror configured.

As it stands most people use oe-core, but some of us are still bound
to oe-classic for maintenance purposes.

Enjoy! Frans

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

Re: [oe] bitbake versions

2012-02-09 Thread Frans Meulenbroeks

2012/2/9 Andrei Gherzan and...@gherzan.ro:
 On 02/09/2012 01:26 AM, Rich Pixley wrote:

 I'm having trouble even parsing using bitbake  1.12.

 Am I right in thinking that the openembedded tree isn't ready to be built
 with bitbake  1.12?

 If so, then the getting started document should probably include this
 info.

 I just finished a core-image-minimal + some other packages using bitbake
 form git, branch master. So i don't think that there a problem with bitbake
 in your case. What error you encountered? What is your system shell? Hope
 bash.

 @g



If one is using oe-classic then bitbakes  1.12 indeed introduce issues.
One that I recall is that it gives a warning if there is a # in a
variable (e.g. when commenting out a patch in a recipe).
But there were other ones too actually blocking it.

If you are using oe-classic better stay with 1.12.
For oe-core probably the latest version of bitbake is the best choice.

Frans

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

[oe] get OE git hash tag in executable

2012-01-28 Thread Frans Meulenbroeks

Hi,

In order to allow backtracking of the sources for a binary build with OE, I
would like to (automatically) add the hash of the top level commit (and
maybe also the branch) of the oe git tree my recipe lives in).
E.g. in main.c I would like to have a var say:
const char * const buildfrom = oe branch 2011.03-maintence hash
1234567890; or something like that.

What would be the best way to get that info into my program?
(my best guess at the moment is to use a macro and compile with
-DOE_IDENT=. or so and say  char *buildfrom = OE_IDENT; but not
really sure what the best way is to fill OE_IDENT and pass it to the
recipe.)

(and of course I'm open to alternate solutions; as long as I can trace back
the git hash)

Thanks in advance for any suggestions!
Frans
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] get OE git hash tag in executable

2012-01-28 Thread Frans Meulenbroeks

2012/1/28 Paul Eggleton paul.eggle...@linux.intel.com

 On Saturday 28 January 2012 13:42:32 Frans Meulenbroeks wrote:
  In order to allow backtracking of the sources for a binary build with
 OE, I
  would like to (automatically) add the hash of the top level commit (and
  maybe also the branch) of the oe git tree my recipe lives in).
  E.g. in main.c I would like to have a var say:
  const char * const buildfrom = oe branch 2011.03-maintence hash
  1234567890; or something like that.
 
  What would be the best way to get that info into my program?
  (my best guess at the moment is to use a macro and compile with
  -DOE_IDENT=. or so and say  char *buildfrom = OE_IDENT; but not
  really sure what the best way is to fill OE_IDENT and pass it to the
  recipe.)

 Interesting question! Putting the information in a define specified on the
 compiler command line would be one way; another way would be to have the
 recipe write to/append to/subsitute into a header file that you can
 #include in
 the source. You would also probably want to include ${DATE} in the
 recipe's PV
 or use some other mechanism to ensure it gets rebuilt every time you build
 an
 image.

 I guess you are still using OE-Classic, but in OE-Core we now have a
 function
 in base.bbclass called get_layers_branch_rev that will return the git
 branch/revision information for all enabled layers. It was split out from
 the
 code in the same bbclass that displays this information when BitBake
 starts,
 so I guess you could just make a copy of it into your recipe for
 OE-Classic.

 Cheers,
 Paul


HI Paul,

Thanks for the feedback.
Indeed I'm still on oe classic; the product in which I am putting this is
close to release so I
cannot switch any more.

Writing into a header file is also something that I considered and that is
also probably quite feasible.
(and maybe even simpler, if it is done in a do_configure step or so,
passing shell varables through bitbake to CFLAGS is not
really trivial; as far as I know I cannot use things like `git log | head
-1` and assign it to a var in the recipe
(it might be possbile with some python, but that is outside my league).

With respect to rebuilding the app. Yeah, didn' t think of that.
It is not too much of a concern, because all our products are build from
scratch on an autobuilder and the
test images and later the release are pulled from that autobuilder, so I
always know that the app info is correct.

Then again, rethinking it, it seems I am making things way too complicated.
Guess the simplest solution is just to do some postprocessing when the
rootfs is created and make a file /etc/buildinfo or so and read that from
the app.
(We only distribute images, not complete apps).

(Actually I do already something like that in the top level makefile that I
have to collect all data for the autobuilder).

Thanks alot for your advice.

Frans

PS: saw the reply from Khem while typing this.
Probably even simpler. add a small makefile rule to the project to create
the version .h file.
I seem to recall u-boot does something similar.
Might need to pass the path from the recipe though, otherwise I'll have to
come up with something like ../../../../../../openembedded.git or so
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[oe] DEFAULT_PREFERENCE = -1

2012-01-26 Thread Frans Meulenbroeks

Dear all,

Triggered by the discussion on oe devel on splitting meta-oe I decided to
do some quick greps on who uses DEFAULT_PREFERENCE in oe-core and meta-oe.

Below are the results.
My questions:
- are recipes with D_P = -1 good enough to enter oe core and/or meta oe.
- is it desirable to have a D_P -1 in an inc file (as happens in
mesa-dri.inc)

Best regards, Frans.

PS: I found the -2 ones especially odd. This seems only useful if there is
someone else already with a -1, which might make the recipe even more
questionable.

frans@frans-desktop:~/workspace$ grep -r DEFAULT_PREFERENCE
openembedded-core
openembedded-core/meta/recipes-core/uclibc/uclibc_git.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-sato/matchbox-theme-sato/matchbox-theme-sato_git.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-gnome/gnome/gobject-introspection_git.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-kernel/oprofile/oprofile_git.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-connectivity/gypsy/gypsy_git.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-qt/qt4/qt4-embedded_4.8.0.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-qt/qt4/qt4-x11-free_4.8.0.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-qt/qt4/qt4-tools-nativesdk_4.8.0.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-qt/qt4/qt4-native_4.8.0.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-graphics/libmatchbox/libmatchbox_git.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-graphics/mutter/mutter_git.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-graphics/xcb/libxcb_git.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-graphics/xcb/xcb-proto_git.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-graphics/clutter/cogl_git.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-graphics/clutter/clutter_git.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-graphics/mesa/mesa-dri_git.bb:DEFAULT_PREFERENCE
= -2
openembedded-core/meta/recipes-graphics/mesa/mesa-dri.inc:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-graphics/mesa/qemugl_git.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-graphics/mesa/mesa-xlib_git.bb:DEFAULT_PREFERENCE
= -2
openembedded-core/meta/recipes-devtools/opkg/opkg-nogpg_svn.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-devtools/opkg/opkg-nogpg_0.1.8.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-devtools/qemu/qemu_git.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-devtools/subversion/subversion_1.7.2.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-devtools/binutils/binutils_csl-arm-2008q1.bb:DEFAULT_PREFERENCE
= -1
openembedded-core/meta/recipes-devtools/pseudo/pseudo_git.bb:DEFAULT_PREFERENCE
= -1
frans@frans-desktop:~/workspace$ grep -r DEFAULT_PREFERENCE
meta-openembedded/
meta-openembedded/meta-efl/recipes-support/libsoup/libsoup-2.4_2.37.2.bb:DEFAULT_PREFERENCE
= -1
meta-openembedded/meta-efl/recipes-efl/efl/eet_svn.bb:DEFAULT_PREFERENCE =
-1
meta-openembedded/meta-efl/recipes-efl/efl/eina_svn.bb:DEFAULT_PREFERENCE =
-1
meta-openembedded/meta-efl/recipes-efl/efl/edbus_svn.bb:DEFAULT_PREFERENCE
= -1
meta-openembedded/meta-efl/recipes-efl/efl/efreet_svn.bb:DEFAULT_PREFERENCE
= -1
meta-openembedded/meta-efl/recipes-efl/efl/edje_svn.bb:DEFAULT_PREFERENCE =
-1
meta-openembedded/meta-efl/recipes-efl/efl/embryo_svn.bb:DEFAULT_PREFERENCE
= -1
meta-openembedded/meta-efl/recipes-efl/efl/eeze_svn.bb:DEFAULT_PREFERENCE =
-1
meta-openembedded/meta-efl/recipes-efl/efl/evas_svn.bb:DEFAULT_PREFERENCE =
-1
meta-openembedded/meta-efl/recipes-efl/efl/eio_svn.bb:DEFAULT_PREFERENCE =
-1
meta-openembedded/meta-efl/recipes-efl/efl/ecore_svn.bb:DEFAULT_PREFERENCE
= -1
meta-openembedded/meta-oe/recipes-core/udev/udev_175.bb:DEFAULT_PREFERENCE
= -1
meta-openembedded/meta-oe/recipes-graphics/tslib/tslib_git.bb:DEFAULT_PREFERENCE
= -1
meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_0.6.8.bb:DEFAULT_PREFERENCE
= -1
meta-openembedded/contrib/oe-stylize.py:'DEFAULT_PREFERENCE',
meta-openembedded/meta-gnome/recipes-gnome/gnome-panel/gnome-panel3_3.0.2.bb:DEFAULT_PREFERENCE
= -1
meta-openembedded/meta-gnome/recipes-gnome/gobject-introspection/gobject-introspection_git.bb:DEFAULT_PREFERENCE
= -1
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe

2012-01-26 Thread Frans Meulenbroeks

2012/1/26 Martin Jansa martin.ja...@gmail.com

 On Wed, Jan 25, 2012 at 06:33:13PM +0100, Frans Meulenbroeks wrote:
  I like the idea of putting toolchains in a layer.
 
  Wrt DP = -1:
  I feel if a recipe needs DP = -1 it is not good enough to be added to
  meta-oe. Probably it is more something for an unstable layer.
  (and DP = -1 encourages the growth of deadwood; I still recall in OE that
  there were some recipes that had the last 3 or 4 versions all with DP =
 -1;
  let's try to avoid this in oe-core/meta-oe)

 I'm not proposing to stash multiple versions of same recipe with D_P in
 same layer.

 What I'm missing is use-case when for example with libsoup-2.4 I'm
 adding unstable version, because actually webkit-efl has random runtime
 crashes with stable version, but works better with unstable one.

 So I want to be able to add recipe with D_P = -1 which would say, that
 this recipe is not used unless someone really wants and adds P_V to his
 layer to get it (I guess people using browsers based on webkit-efl).

 But right now it will pick this unstable version from meta-oe by default
 and you have to add P_V for that stable version in oe-core (and keep it
 up2date as long as stable version in oe-core is updated).

 And I guess the same use-case D_P should be used for all not so well
 tested or deprecated recipes in meta-oe or any other layer.

 Even if there is meta-deprecated layer.. I guess nobody would prefer all
 deprecated recipes, but just some of them (ideally by pinning them with
 P_V).


 HI Martin,

I understand your reasoning.
My main concerns are:
- you might end up with lots of versions and no one knows that is actually
used (so it is difficult to clean it). We saw this in oe classic
- generally the reasons why a recipe has DP -1 are unclear. How would Joe
Average know that if he is using webkit-efl he is better off using this new
libsoup recipe?
- and if a recipe is not well enough tested it should probably not end up
in meta-oe anyway (but better e.g. in meta-oe-next or meta-oe-new or
whatever you want to call the super bleeding edge version)

Best regards, Frans.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe

2012-01-25 Thread Frans Meulenbroeks

2012/1/25 Paul Eggleton paul.eggle...@linux.intel.com

 Hi all,

 The meta-oe layer [1] is becoming the home for additional recipes that we
 miss
 from OE-Classic that don't have another obvious layer to go into, and this
 is
 a good thing. However I think that meta-oe is already in a state where
 quite a
 few people feel the new structure is not working for them.

 As I see it, meta-oe is trying provide the following:

  1) Additional recipes that are not in OE-Core

  2) Additional functionality for OE-Core recipes that we can't enable in
 OE-
 Core itself (e.g. enabling postgres support in Qt) - mostly just a
 side-effect
 of #1

  3) A place to preserve old versions of recipes that have been removed from
 OE-Core in favour of newer versions

  4) Newer less-well tested versions of recipes

 I think what most people want when they enable meta-oe in their layer
 configuration is #1, and it's probably OK to get #2 along with it. They do
 not
 however expect versions of toolchains, eglibc or other fairly fundamental
 bits
 and pieces that might cause their build to fail when everything worked fine
 just building with OE-Core (#4). Equally I expect there will be some people
 who want just #3 and nothing else.

 I understand there is significant value in providing all of these things, I
 just think we shouldn't be trying to do them all in one largely indivisible
 layer. In our new layer structure we should be able to find a way to split
 the
 metadata so that people who want any combination can still have what we
 have
 in meta-oe today, and yet those who just want one of them don't get
 unexpected
 build failures or older/newer versions being built.

 Thoughts?

 Cheers,
 Paul

 [1] http://cgit.openembedded.org/meta-openembedded/tree/meta-oe

 --

 Paul, all,

I feel this is a good proposal.
We might also attempt to define some criteria on what should go in and what
not.

Some more finegrained comments:

#3 should probably not be needed (it might be as a temporary transient).
I would hope/expect that meta-oe builds with oe-core and what is in there.
If a distro needs an older version of something (for whatever reason) it
better should be in the distro overlay.
Ditto if a board needs an older version.
(btw and if it is for historical reasons: the old versions can always be
retrieved from git).
(Note that I see no problem if there is a drastic change that needs some
work in meta-oe where an old version is kept as a transient to keep things
working while working to move to the new version)

Wrt #4: that is indeed something that people do not always expect. I feel a
better place for these newer/less-stable recipes would be a oe-core-next
branch or tree (assuming we are talking about oe-core recipes)

Best regards, Frans
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] Splitting meta-oe

2012-01-25 Thread Frans Meulenbroeks

I like the idea of putting toolchains in a layer.

Wrt DP = -1:
I feel if a recipe needs DP = -1 it is not good enough to be added to
meta-oe. Probably it is more something for an unstable layer.
(and DP = -1 encourages the growth of deadwood; I still recall in OE that
there were some recipes that had the last 3 or 4 versions all with DP = -1;
let's try to avoid this in oe-core/meta-oe)

Best regards, Frans.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] FOSDEM 2012 - stand organization thread

2012-01-19 Thread Frans Meulenbroeks

2012/1/19 Robert Schuster thebohem...@gmx.net


 [...]



 Any news regarding OE people who want come to FOSDEM?


I am planning to come but no idea yet if it will be for 1 or 2 days.

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

Re: [oe] fakeroot 1.15.1 issues

2012-01-17 Thread Frans Meulenbroeks

2012/1/17 Tom Rini tom.r...@gmail.com

On Wed, Jan 4, 2012 at 3:08 AM, Angus Lees al...@google.com wrote:
On Mon, Dec 26, 2011 at 15:12, Denys Dmytriyenko de...@denix.org
wrote:

On Sun, Dec 25, 2011 at 09:11:36PM +0100, Frans Meulenbroeks wrote:
2011/12/23 Denys Dmytriyenko de...@denix.org
Actually bumped into this today as well; I saw maintenance moved back
to
1.14.6 or so.
Latest version is about 1.18.2.2.

Guess we should either move master back to 1.14.6, or maybe even move
to
a
newer version. or fix the url to point to the snapshot copy.

So, instead of always chasing the very latest version, why not simply
set
the
Debian mirror variable on a per-distro basis?

Or stick to a fakeroot release that was in a Debian (stable) release, and
hence will be around for a while.

I'm not sure what problem people are having currently. An empy DL_DIR
build with DISTRO=angstrom-2008.1 and MACHINE=beagleboard does this:
NOTE: package fakeroot-native-1_1.14.5-r0.0: task do_fetch: Started
--2012-01-17 13:42:12--

http://snapshot.debian.org/archive/debian/20110301/pool/main/f/fakeroot/fakeroot_1.14.5.orig.tar.bz2

Which works and finds the expected file with expected hashes. This is
because the fakeroot recipe doesn't use DEBIAN_MIRROR now but directly
uses a date-encoded URL on snapshot.debian.org.

Tom,

The problem was present in master (as it fetched 1.15.1), not in the
maintenance branch.
I've fixed it in master by adding the 1.14.5 recipe and deprecating the
1.15.1 recipe.

This commit: 38c962e6f0adbc4154cda3107404e8ce92cfbccb

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

Re: [oe] [2011.03-maintenance] commit 89cb863234616620d172984ff173f1d84ce4caa9

2012-01-16 Thread Frans Meulenbroeks

2012/1/16 Tom Rini tr...@kernel.crashing.org

On Thu, Jan 12, 2012 at 12:33 AM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:
Dear all,

I just accidently committed
89cb863234616620d172984ff173f1d84ce4caa9
http://cgit.openembedded.org/openembedded/commit/?h=2011.03-maintenanceid=89cb863234616620d172984ff173f1d84ce4caa9
on
the maintenance branch.

My intention was to commit this to master and send a maintenance pull
request, but as i did not notice that my branch was on
2011.03-maintenance,
I accidently pushed to that branch
(actually somewhat surprizing me, as i did not expect to be able to push
against that branch).

I'll leave it to the maintainers to decide on how to handle this.
I would like to see this recipe in the maintenance branch too thoguh.

The patch moves the recipe from the 2007_365 version to the 2010_365
version.
commit message:

*kicks gmail for not marking this important*

Well, how does this fit against the rest of the requirements for the
branch? In other words, have you gotten all of these changes in
somewhere else so they won't be lost?

Hi Tom,

Not sure what you exactly mean.
The change is also in oe classic master. oe-core does not carry this recipe
(and if I recall correctly meta-oe neither does)
As it stands the patch simplifies the recipe as the uclibc specific patch
is not needed any more (and hence is dropped).

And maybe I caused confusion: the changes I listed in the commit message
are the official changes between 2007_365 and 2010_365, not changes I made
to the code.
In fact the recipe is pretty straightforward.

Best regards, Frans
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [2011.03-maintenance] commit 89cb863234616620d172984ff173f1d84ce4caa9

2012-01-16 Thread Frans Meulenbroeks

2012/1/16 Tom Rini tom.r...@gmail.com

On Mon, Jan 16, 2012 at 12:59 PM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:
2012/1/16 Tom Rini tr...@kernel.crashing.org

On Thu, Jan 12, 2012 at 12:33 AM, Frans Meulenbroeks
fransmeulenbro...@gmail.com wrote:
Dear all,

I just accidently committed
89cb863234616620d172984ff173f1d84ce4caa9

http://cgit.openembedded.org/openembedded/commit/?h=2011.03-maintenanceid=89cb863234616620d172984ff173f1d84ce4caa9
on
the maintenance branch.

I'll leave it to the maintainers to decide on how to handle this.
I would like to see this recipe in the maintenance branch too thoguh.

The patch moves the recipe from the 2007_365 version to the 2010_365
version.
commit message:

*kicks gmail for not marking this important*

Well, how does this fit against the rest of the requirements for the
branch? In other words, have you gotten all of these changes in
somewhere else so they won't be lost?

Hi Tom,

Not sure what you exactly mean.
The change is also in oe classic master. oe-core does not carry this
recipe
(and if I recall correctly meta-oe neither does)
As it stands the patch simplifies the recipe as the uclibc specific patch
is not needed any more (and hence is dropped).

And maybe I caused confusion: the changes I listed in the commit message
are the official changes between 2007_365 and 2010_365, not changes I
made
to the code.
In fact the recipe is pretty straightforward.

So long as the recipe changes exist somewhere else then yes, I'm OK
with this accident. We don't currently have special hooks setup to
make the maintenance branch only writable by me and I'm not sure if
it's worth adding to our admins workload.

I'll make sure it won't happen again (at least not by me).
As I was unaware this could happen I did not really pay attention to the
branch when pushing (actually I was under the impression I was on master)

Best regards, Frans
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] #oe topic

2012-01-14 Thread Frans Meulenbroeks

Ping. Almost a week ago.
No one with rights to change the topic ???

Best regards, Frans

2012/1/8 Frans Meulenbroeks fransmeulenbro...@gmail.com

 No idea who is can change the topic for #oe, but currently it reads:

 (04:27:30 PM) *The topic for #oe is: OpenEmbedded Developer Lounge | Web:
 http://openembedded.org | Bugtracker: http://bugs.openembedded.org and
 http://tinderbox.openembedded.org for compile issues | Repository:
 git.openembedded.org/openembedded and repo.or.cz/r/openembedded.git as ro
 mirror | This is not a distro or machine support channel*

 As it stands the bugtracker is taken offline permanently and tinderbox is
 (temporary?) out of service.
 It seems pointless to mention these in the topic

 Best regards, Frans

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

Re: [oe] meta-oe post holiday patchwork cleanup

2012-01-13 Thread Frans Meulenbroeks

2012/1/13 martin.ja...@gmail.com

 On Thu, Jan 12, 2012 at 06:47:29PM -0600, Peter Bigot wrote:
  On Thu, Jan 12, 2012 at 6:06 PM, McClintock Matthew-B29882
  b29...@freescale.com wrote:
   On Thu, Jan 12, 2012 at 5:26 PM, Peter Bigot big...@acm.org wrote:
   On Thu, Jan 12, 2012 at 8:23 AM, Koen Kooi 
 k...@dominion.thruhere.net wrote:
   -BEGIN PGP SIGNED MESSAGE-
   Hash: SHA1
  
   tl;dr version: get your subject-prefix right
  
   Hi,
  
   I've cleaned up patchwork by marking every meta-oe patch as
 archived, minus
   the one Martin just sent.
  
   This means all the pending patches for meta-oe are listed here:
  
   http://patches.openembedded.org/project/oe/list/?q=meta-oe
  
   If your patches are missing, resend them using the method outlined
 in the
   README of the respective meta-openembedded layer.
  
   I'll include the meta-oe one below, since too many patches still
 don't comply:
  
   -
 ---
  
   This layer depends on:
  
   URI: git://git.openembedded.org/openembedded-core
   branch: master
   revision: HEAD
  
   Send pull requests to openembedded-devel@lists.openembedded.org with
   '[meta-oe]' in the subject'
  
   When sending single patches, please use something like 'git
 send-email -1
   - --to openembedded-devel@lists.openembedded.org --subject-prefix
 meta-oe'
  
   You are encouraged to fork the mirror on github
   https://github.com/openembedded/meta-oe/ to share your patches,
 this is
   preferred for patch sets consisting of more than one patch. Other
 services
   like gitorious, repo.or.cz or self hosted setups are of course
 accepted as
   well, 'git fetch remote' works the same on all of them. We
 recommend
   github because it is free, easy to use, has been proven to be
 reliable and
   has a really good web GUI.
  
   Main layer maintainer: Koen Kooi k...@dominion.thruhere.net
  
   -
 ---
  
   The most important thing of that is the subject prefix. I only read
 emails
   with a [meta-foo] subject prefix on oe-devel nowadays and I look at
   http://patches.openembedded.org/project/oe/list/?q=meta- more often
 than
   oe-devel.
  
   So: Get your subject-prefix right
  
   And kudos to Andreas, Martin and Otavio for getting their pull
 requests
   right pretty much all the time.
  
   While I appreciate that a blanket throw it out; if they care they'll
   resend it approach is an effective way to deal with the backlog
   resulting from an absence, I don't appreciate that in addition to the
   time I spent crafting patches to improve oe-core and submitting them
   (with the right prefix AFAIK), I am now expected to do so again.
   Further, the archived discussion of one of my patches included a
   request for clarification on how to address a licensing issue which
   was never answered, and which now presumably never will be.
  
   This sort of practice discourages people (well, me at least) from
   contributing to this project.
  
   Perhaps you can just mark them correctly in patchworks again instead
   of resubmitting? Somewhat easier, you can even keep a list of patch
   id's and do this automatically via the pwclient.
 
  Maybe; the only one I can see in the archive is the one that has an
  unanswered question.  If I request a patchwork account, would I be
  able to do this?  (I don't have/use/know anything about pwclient.)

 If it still works the same, then create patchwork account yourself with
 same e-mail address you're using when sending patches and you should be
 able to update your patches.

  The others don't appear to be there; maybe they got merged in since I
  last looked, in which case I apologize for grumbling prematurely.  (My
  oe-core effort is unfunded so I only get a chance to poke at it for a
  couple days every couple weeks, and only see the emails during the off
  times.)


I could find 3 patches:
http://patches.openembedded.org/project/oe/list/?submitter=1693state=*archive=both



 Be aware that oe-core patches are not really tracked on patchwork,
 patchwork is used mostly for meta-* patches.


 oe-core patches are tracked on a different project:
http://patches.openembedded.org/project/oe-core/list/


Best regards, Frans
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[oe] [2011.03-maintenance] commit 89cb863234616620d172984ff173f1d84ce4caa9

2012-01-11 Thread Frans Meulenbroeks

Dear all,

I just accidently committed
89cb863234616620d172984ff173f1d84ce4caa9http://cgit.openembedded.org/openembedded/commit/?h=2011.03-maintenanceid=89cb863234616620d172984ff173f1d84ce4caa9on
the maintenance branch.

My intention was to commit this to master and send a maintenance pull
request, but as i did not notice that my branch was on 2011.03-maintenance,
I accidently pushed to that branch
(actually somewhat surprizing me, as i did not expect to be able to push
against that branch).

I'll leave it to the maintainers to decide on how to handle this.
I would like to see this recipe in the maintenance branch too thoguh.

The patch moves the recipe from the 2007_365 version to the 2010_365
version.
commit message:

ntpclient: updated to 2010_365 version

Changes since ntpclient_2007_365:
-- fixed type of sa_xmit_len, thanks vapier
-- dropped underscores in spelling of adjtimex(2), might make uClibc
happier
-- include netdb.h and always define _BSD_SOURCE to get prototype for
herror
-- minor formatting to align with Nilsson's fork
-- add -fno-strict-aliasing as needed by traditional network coding
style

The 2nd -- also implies our local patch is not needed any more

Apologies for any inconvenience.
Frans
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[oe] #oe topic

2012-01-08 Thread Frans Meulenbroeks

No idea who is can change the topic for #oe, but currently it reads:

(04:27:30 PM) *The topic for #oe is: OpenEmbedded Developer Lounge | Web:
http://openembedded.org | Bugtracker: http://bugs.openembedded.org and
http://tinderbox.openembedded.org for compile issues | Repository:
git.openembedded.org/openembedded and repo.or.cz/r/openembedded.git as ro
mirror | This is not a distro or machine support channel*

As it stands the bugtracker is taken offline permanently and tinderbox is
(temporary?) out of service.
It seems pointless to mention these in the topic

Best regards, Frans
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [PATCHv2][2011.03-maintenance] binutils_2.20.1 fixed md5 and sha256 sum

2011-12-31 Thread Frans Meulenbroeks

2011/12/31 Adriano Pallavicino adrianopallavic...@gmail.com

 Signed-off-by: Adriano Pallavicino adriano.pallavic...@gmail.com

 Fixed md5sum and sha256sum
 ---
  recipes/binutils/binutils_2.20.1.bb |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/recipes/binutils/binutils_2.20.1.bb b/recipes/binutils/
 binutils_2.20.1.bb
 index 5154e2d..f40b676 100644
 --- a/recipes/binutils/binutils_2.20.1.bb
 +++ b/recipes/binutils/binutils_2.20.1.bb
 @@ -24,8 +24,8 @@ SRC_URI_append_nios2 = \
file://binutils-nios2.patch \


 -SRC_URI[tarball.sha256sum] =
 228b84722d87e88e7fdd36869e590e649ab523a0800a7d53df906498afe6f6f8
 -SRC_URI[tarball.md5sum] = 9cdfb9d6ec0578c166d3beae5e15c4e5
 +SRC_URI[tarball.sha256sum] =
 71d37c96451333c5c0b84b170169fdcb138bbb27397dc06281905d9717c8ed64
 +SRC_URI[tarball.md5sum] = 2b9dc8f2b7dbd5ec5992c6e29de0b764

  # powerpc patches
  SRC_URI += \
 --
 1.7.4.1


As told on IRC, I'd suggest to compare against the version in master.
THere the issue was fixed using this patch:
http://cgit.openembedded.org/openembedded/commit/recipes/binutils/binutils_2.20.1.bb?id=262f9eb0f046cd77d041a9dcb055700c5ab6601b

Note that this also patches SRC_URI.
Guess the patch above should also go into master.

Did you by any chance download your binutils tarball manually?

Best regards, Frans
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [PATCHv2][2011.03-maintenance] binutils_2.20.1 fixed md5 and sha256 sum

2011-12-31 Thread Frans Meulenbroeks

Tom,

I feel it is a good plan to resolve this problem by adding
http://cgit.openembedded.org/openembedded/commit/?id=262f9eb0f046cd77d041a9dcb055700c5ab6601bto
the maintenance branch
This makes things buildable again.
As you are the commiter of the above patch, I feel you are in a better
position than me to judge this is ok.
However with the patch at least the angstrom people get the problem
resolved (minimal uses 2.21 and requries a different patch)

Best regards, Frans.

2011/12/31 Adriano Pallavicino adrianopallavic...@gmail.com

 I can correctly download it from here
 ftp://ftp.gnu.org/gnu/binutils/binutils-2.20.1.tar.bz2 (as indicated
 inside
 bb file). The problem is only in sha256 and md5 sum. I'm using
 2011.03-maintenance. I can desume that this branch is only for maintaining
 2011.03 release. If someone decided to use binutils 2.20.1 why should I
 introduce the new 2.20.1a from master? All the things are tested with
 2.20.1 and imho the branch 2011.03-maintenance must continue to utilize
 them.
 Of course, if maintainers consider this patch useless, I'll remove it from
 here.

 2011/12/31 Frans Meulenbroeks fransmeulenbro...@gmail.com

  2011/12/31 Adriano Pallavicino adrianopallavic...@gmail.com
 
   Signed-off-by: Adriano Pallavicino adriano.pallavic...@gmail.com
  
   Fixed md5sum and sha256sum
   ---
recipes/binutils/binutils_2.20.1.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
  
   diff --git a/recipes/binutils/binutils_2.20.1.bb b/recipes/binutils/
   binutils_2.20.1.bb
   index 5154e2d..f40b676 100644
   --- a/recipes/binutils/binutils_2.20.1.bb
   +++ b/recipes/binutils/binutils_2.20.1.bb
   @@ -24,8 +24,8 @@ SRC_URI_append_nios2 = \
  file://binutils-nios2.patch \
  
  
   -SRC_URI[tarball.sha256sum] =
   228b84722d87e88e7fdd36869e590e649ab523a0800a7d53df906498afe6f6f8
   -SRC_URI[tarball.md5sum] = 9cdfb9d6ec0578c166d3beae5e15c4e5
   +SRC_URI[tarball.sha256sum] =
   71d37c96451333c5c0b84b170169fdcb138bbb27397dc06281905d9717c8ed64
   +SRC_URI[tarball.md5sum] = 2b9dc8f2b7dbd5ec5992c6e29de0b764
  
# powerpc patches
SRC_URI += \
   --
   1.7.4.1
  
 
  As told on IRC, I'd suggest to compare against the version in master.
  THere the issue was fixed using this patch:
 
 
 http://cgit.openembedded.org/openembedded/commit/recipes/binutils/binutils_2.20.1.bb?id=262f9eb0f046cd77d041a9dcb055700c5ab6601b
 
  Note that this also patches SRC_URI.
  Guess the patch above should also go into master.
 
  Did you by any chance download your binutils tarball manually?
 
  Best regards, Frans
  ___
  Openembedded-devel mailing list
  Openembedded-devel@lists.openembedded.org
  http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
 



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

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

[oe] non-fetching recipes

2011-12-28 Thread Frans Meulenbroeks

Hi,

I noticed that several recipes are non-fetchers. These are mostly the ones
with sources hosted on kernel.org.
Is there an issue with kernel.org again?

I noticed this for oe classic where libpam and util-linux-ng did not fetch
(as well as opkg-utils but that one is from openmoko).
oe maintenance branch seems to have the same problems as well as using
binutils 2.21 which is not available any more. master does not have this as
it has been moved to 2.21a.

I'm crossposting this to oe-core, because I noticed it uses the same
location for libpam (and probably util-linux).

Someone might want to run some fetchalls.

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

Re: [oe] [2011.03-maintenance] net-snmp: please cherry pick 4a98e62ac35d4367d3c072819317deeda52abf5e from master

2011/12/27 Tom Rini tom.r...@gmail.com

 On Mon, Dec 26, 2011 at 1:29 PM, Frans Meulenbroeks
 fransmeulenbro...@gmail.com wrote:
  Please merge this one
 
 http://cgit.openembedded.org/openembedded/commit/?id=4a98e62ac35d4367d3c072819317deeda52abf5e
 
  to the maintenance tree. it updates net-snmp to 5.7.1; the existing
 version
  does not build for uclibc; this fixes it.

 Per the wiki page, this is not a proper request for the maintenance
 branch, please re-submit a pull request with the cherry-pick tested
 and confirmed to fix the issue, thanks.

 This has been tested for meta-oe (by Eric) and for the maintenance branch
(by me, actually it is part of our most recent product) and compile-tested
by me on master.
I'm not planning to set up a git or branch for a single patch. I'll mail a
patch in a few minutes.
Didn't know we became this bureaucratic. Will take that into account when
considering submitting my next patch.

Best regards,
Frans
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[oe] [2011.03-maintenance] [PATCH] net-snmp: added version 5.7.1

Backported from meta-oe where it was contributed by Eric Bénard
While at it also fixed some whitespace warnings.
Gave it a DEFAULT_PREFERENCE of 1 so it gets preference above the
older svn recipe (svn is deprecatted by net-snmp anyway)

Rationale for adding is because the existing recipe does not
build for uclibc, and the new version does.

Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
---
 recipes/net-snmp/files/snmpd.conf |   32 
 recipes/net-snmp/files/snmptrapd.conf |1 -
 recipes/net-snmp/net-snmp_5.7.1.bb|   28 
 3 files changed, 44 insertions(+), 17 deletions(-)
 create mode 100644 recipes/net-snmp/net-snmp_5.7.1.bb

diff --git a/recipes/net-snmp/files/snmpd.conf 
b/recipes/net-snmp/files/snmpd.conf
index 728171c..4e6b2eb 100644
--- a/recipes/net-snmp/files/snmpd.conf
+++ b/recipes/net-snmp/files/snmpd.conf
@@ -39,7 +39,7 @@
 # allow me to access it?
 #
 # By default, the agent responds to the public community for read
-# only access, if run out of the box without any configuration file in 
+# only access, if run out of the box without any configuration file in
 # place.  The following examples show you other ways of configuring
 # the agent so that you can change the community names, and give
 # yourself write access as well.
@@ -150,7 +150,7 @@ syscontact Root root@localhost (configure 
/etc/snmp/snmpd.local.conf)
 #proc sendmail 10 1
 
 #  A snmpwalk of the prTable would look something like this:
-# 
+#
 # % snmpwalk -v 1 -c public localhost .1.3.6.1.4.1.2021.2
 # enterprises.ucdavis.procTable.prEntry.prIndex.1 = 1
 # enterprises.ucdavis.procTable.prEntry.prIndex.2 = 2
@@ -180,8 +180,8 @@ syscontact Root root@localhost (configure 
/etc/snmp/snmpd.local.conf)
 #  Note that the errorFlag for mountd is set to 1 because one is not
 #  running (in this case an rpc.mountd is, but thats not good enough),
 #  and the ErrMessage tells you what's wrong.  The configuration
-#  imposed in the snmpd.conf file is also shown.  
-# 
+#  imposed in the snmpd.conf file is also shown.
+#
 #  Special Case:  When the min and max numbers are both 0, it assumes
 #  you want a max of infinity and a min of 1.
 #
@@ -220,7 +220,7 @@ syscontact Root root@localhost (configure 
/etc/snmp/snmpd.local.conf)
 #
 #exec shelltest /bin/sh /tmp/shtest
 
-# Then, 
+# Then,
 # % snmpwalk -v 1 -c public localhost .1.3.6.1.4.1.2021.8
 # enterprises.ucdavis.extTable.extEntry.extIndex.1 = 1
 # enterprises.ucdavis.extTable.extEntry.extIndex.2 = 2
@@ -246,7 +246,7 @@ syscontact Root root@localhost (configure 
/etc/snmp/snmpd.local.conf)
 #
 
 # The agent can check the amount of available disk space, and make
-# sure it is above a set limit.  
+# sure it is above a set limit.
 
 # disk PATH [MIN=DEFDISKMINIMUMSPACE]
 #
@@ -260,7 +260,7 @@ syscontact Root root@localhost (configure 
/etc/snmp/snmpd.local.conf)
 
 # % snmpwalk -v 1 -c public localhost .1.3.6.1.4.1.2021.9
 # enterprises.ucdavis.diskTable.dskEntry.diskIndex.1 = 0
-# enterprises.ucdavis.diskTable.dskEntry.diskPath.1 = / Hex: 2F 
+# enterprises.ucdavis.diskTable.dskEntry.diskPath.1 = / Hex: 2F
 # enterprises.ucdavis.diskTable.dskEntry.diskDevice.1 = /dev/dsk/c201d6s0
 # enterprises.ucdavis.diskTable.dskEntry.diskMinimum.1 = 1
 # enterprises.ucdavis.diskTable.dskEntry.diskTotal.1 = 837130
@@ -294,9 +294,9 @@ syscontact Root root@localhost (configure 
/etc/snmp/snmpd.local.conf)
 # enterprises.ucdavis.loadTable.laEntry.loadaveNames.1 = Load-1
 # enterprises.ucdavis.loadTable.laEntry.loadaveNames.2 = Load-5
 # enterprises.ucdavis.loadTable.laEntry.loadaveNames.3 = Load-15
-# enterprises.ucdavis.loadTable.laEntry.loadaveLoad.1 = 0.49 Hex: 30 2E 34 
39 
-# enterprises.ucdavis.loadTable.laEntry.loadaveLoad.2 = 0.31 Hex: 30 2E 33 
31 
-# enterprises.ucdavis.loadTable.laEntry.loadaveLoad.3 = 0.26 Hex: 30 2E 32 
36 
+# enterprises.ucdavis.loadTable.laEntry.loadaveLoad.1 = 0.49 Hex: 30 2E 34 39
+# enterprises.ucdavis.loadTable.laEntry.loadaveLoad.2 = 0.31 Hex: 30 2E 33 31
+# enterprises.ucdavis.loadTable.laEntry.loadaveLoad.3 = 0.26 Hex: 30 2E 32 36
 # enterprises.ucdavis.loadTable.laEntry.loadaveConfig.1 = 12.00
 # enterprises.ucdavis.loadTable.laEntry.loadaveConfig.2 = 14.00
 # enterprises.ucdavis.loadTable.laEntry.loadaveConfig.3 = 14.00
@@ -312,7 +312,7 @@ syscontact Root root@localhost (configure 
/etc/snmp/snmpd.local.conf)
 
 ###
 # Extensible sections.
-# 
+#
 
 # This alleviates the multiple line output problem found in the
 # previous executable mib by placing each mib in its own mib table:
@@ -346,8 +346,8 @@ syscontact Root root@localhost (configure 
/etc/snmp/snmpd.local.conf)
 # the .50.* outputs above to change to reasonable text descriptions.
 
 # Other ideas:
-# 
-# exec .1.3.6.1.4.1.2021.51 ps /bin/ps 
+#
+# exec .1.3.6.1.4.1.2021.51 ps /bin/ps
 # exec .1.3.6.1.4.1.2021.52 top /usr/local/bin/top
 # exec

Re: [oe] [2011.03-maintenance] net-snmp: please cherry pick 4a98e62ac35d4367d3c072819317deeda52abf5e from master

2011/12/27 Tom Rini tom.r...@gmail.com

 On Tue, Dec 27, 2011 at 11:28 AM, Frans Meulenbroeks
 fransmeulenbro...@gmail.com wrote:
  2011/12/27 Tom Rini tom.r...@gmail.com
 
  On Mon, Dec 26, 2011 at 1:29 PM, Frans Meulenbroeks
  fransmeulenbro...@gmail.com wrote:
   Please merge this one
  
 
 http://cgit.openembedded.org/openembedded/commit/?id=4a98e62ac35d4367d3c072819317deeda52abf5e
  
   to the maintenance tree. it updates net-snmp to 5.7.1; the existing
  version
   does not build for uclibc; this fixes it.
 
  Per the wiki page, this is not a proper request for the maintenance
  branch, please re-submit a pull request with the cherry-pick tested
  and confirmed to fix the issue, thanks.
 
  This has been tested for meta-oe (by Eric) and for the maintenance
 branch
  (by me, actually it is part of our most recent product) and
 compile-tested
  by me on master.
  I'm not planning to set up a git or branch for a single patch. I'll mail
 a
  patch in a few minutes.
  Didn't know we became this bureaucratic. Will take that into account when
  considering submitting my next patch.

 Yes, I'm only taking cherry-picks that others have done and
 send-email'd or pull requests and not individual cherry-pick requests
 so that I can be sure that the person requesting the change is sure
 this deals with their issue fully.  Sorry if I wasn't clear that
 individual patches are also fine (the wiki page does say patches or
 pull requests already, just re-confirmed).  Thanks.

 --
 Tom

 patch send,. it applies without any problem on the maintenance branch.
Could not compile-test it on the maintenance branch. When I tried to it
wanted to build binutils 2.21 but that one did not fetch.
See log below.
BTW opg-utils also is a non-fetcher.

Frans

NOTE: Running task 219 of 676 (ID: 332, /home/frans/oe/recipes/binutils/
binutils-cross_2.21.bb, do_fetch)
--2011-12-27 19:52:31--
ftp://ftp.gnu.org/gnu/binutils/binutils-2.21.tar.bz2
= `/home/frans/sources/binutils-2.21.tar.bz2'
NOTE: package binutils-cross-2.21-r13.3: task do_fetch: Started
 Resolving ftp.gnu.org... 140.186.70.20
 Connecting to ftp.gnu.org|140.186.70.20|:21... connected.
 Logging in as anonymous ... Logged in!
 == SYST ... done.== PWD ... done.
 == TYPE I ... done.  == CWD (1) /gnu/binutils ... done.
 == SIZE binutils-2.21.tar.bz2 ... done.
 == PASV ... done.== RETR binutils-2.21.tar.bz2 ...
 No such file `binutils-2.21.tar.bz2'.

 --2011-12-27 19:52:33--
ftp://mirrors.kernel.org/gnu/binutils/binutils-2.21.tar.bz2
= `/home/frans/sources/binutils-2.21.tar.bz2'
 Resolving mirrors.kernel.org... 149.20.4.71
 Connecting to mirrors.kernel.org|149.20.4.71|:21... connected.
 Logging in as anonymous ... Logged in!
 == SYST ... done.== PWD ... done.
 == TYPE I ... done.  == CWD (1) /gnu/binutils ... done.
 == SIZE binutils-2.21.tar.bz2 ... done.
 == PASV ... done.== RETR binutils-2.21.tar.bz2 ...
 No such file `binutils-2.21.tar.bz2'.

 --2011-12-27 19:52:36--
ftp://ftp.cs.ubc.ca/mirror2/gnu/binutils/binutils-2.21.tar.bz2
= `/home/frans/sources/binutils-2.21.tar.bz2'
 Resolving ftp.cs.ubc.ca... 142.103.6.49
 Connecting to ftp.cs.ubc.ca|142.103.6.49|:21... connected.
 Logging in as anonymous ... Logged in!
 == SYST ... done.== PWD ... done.
 == TYPE I ... done.  == CWD (1) /mirror2/gnu/binutils ...
 No such directory `mirror2/gnu/binutils'.

 --2011-12-27 19:52:39--
ftp://sunsite.ust.hk/pub/gnu/binutils/binutils-2.21.tar.bz2
= `/home/frans/sources/binutils-2.21.tar.bz2'
 Resolving sunsite.ust.hk... failed: Name or service not known.
 wget: unable to resolve host address `sunsite.ust.hk'
 --2011-12-27 19:52:40--
ftp://ftp.ayamura.org/pub/gnu/binutils/binutils-2.21.tar.bz2
= `/home/frans/sources/binutils-2.21.tar.bz2'
 Resolving ftp.ayamura.org... 205.178.189.131
^C
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[oe] [2011.03-maintenance] u-boot 2011.03 recipe

Just a snippet of info for the maintenance tree users.
I've modified 2011.03 in master to also build the latest version of the
tools (notably fw_printenv, fw_setenv).
These are useful if you want to modify the u-boot environment from user
space.

As the maintenance branch does not have this version, I'm not sure whether
it is desired or not to submit it. (not sure whether maintenance would want
a newer u-boot)
Anyone needing it (or wanting to move it to the maintenance branch): feel
free to copy.

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

[oe] [2011.03-maintenance] net-snmp: please cherry pick 4a98e62ac35d4367d3c072819317deeda52abf5e from master

2011-12-26 Thread Frans Meulenbroeks

Please merge this one
http://cgit.openembedded.org/openembedded/commit/?id=4a98e62ac35d4367d3c072819317deeda52abf5e

to the maintenance tree. it updates net-snmp to 5.7.1; the existing version
does not build for uclibc; this fixes it.

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

Re: [oe] fakeroot 1.15.1 issues

2011-12-25 Thread Frans Meulenbroeks

2011/12/23 Denys Dmytriyenko de...@denix.org

 On Thu, Dec 22, 2011 at 01:08:16AM -0800, Jesse Lackey wrote:
  I'm have exactly the same problem.  git pull says up to date.
 
  I'm continuing on by running bitbake -k.  But things appear to be
  indeed broken, by the presumably recent removal of
  fakeroot_1.15.1.orig.tar.bz2 from the debian ftp site.
 
  Any assistance greatly appreciated.  I'm a total newbie with bitbake and
 OE.
 
  I tried `git pull` but apparently everything is Already up-to-date.
 Am I
  missing something else?

 Add this line to your local.conf:

 DEBIAN_MIRROR = 
 http://snapshot.debian.org/archive/debian/2029T215729Z/pool;


Actually bumped into this today as well; I saw maintenance moved back to
1.14.6 or so.
Latest version is about 1.18.2.2.

Guess we should either move master back to 1.14.6, or maybe even move to a
newer version. or fix the url to point to the snapshot copy.

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

[oe] opkg-util does not fetch any more

2011-12-25 Thread Frans Meulenbroeks

opkg-util does not fetch any more. The svn at openmoko does not seem to
exist any more.
This is a problem with oe classic (master and 2011.03-maintenance) as well
as oe-core (bug filed for that one).

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

[oe] [2011.03-maintenance] Fwd: [meta-oe 3/3] add net-snmp-5.7.1

2011-12-02 Thread Frans Meulenbroeks

Can we also pull this into the maintenance branch ?
I can also submit a patch for classic if needed (actually this was still on
my to do list but Eric surpassed me)

Frans

-- Forwarded message --
From: Eric Bénard e...@eukrea.com
Date: 2011/12/2
Subject: [oe] [meta-oe 3/3] add net-snmp-5.7.1
To: openembedded-devel@lists.openembedded.org
Cc: Eric Bénard e...@eukrea.com


the recipe was imported from OE-classic and upgraded to latest stable.

Signed-off-by: Eric Bénard e...@eukrea.com
---
 meta-oe/recipes-extended/net-snmp/files/init   |   63 +++
 meta-oe/recipes-extended/net-snmp/files/snmpd.conf |  422

 .../recipes-extended/net-snmp/files/snmptrapd.conf |   18 +
 meta-oe/recipes-extended/net-snmp/net-snmp.inc |   66 +++
 .../recipes-extended/net-snmp/net-snmp_5.7.1.bb|   26 ++
 5 files changed, 595 insertions(+), 0 deletions(-)
 create mode 100755 meta-oe/recipes-extended/net-snmp/files/init
 create mode 100644 meta-oe/recipes-extended/net-snmp/files/snmpd.conf
 create mode 100644 meta-oe/recipes-extended/net-snmp/files/snmptrapd.conf
 create mode 100644 meta-oe/recipes-extended/net-snmp/net-snmp.inc
 create mode 100644 meta-oe/recipes-extended/net-snmp/net-snmp_5.7.1.bb

diff --git a/meta-oe/recipes-extended/net-snmp/files/init
b/meta-oe/recipes-extended/net-snmp/files/init
new file mode 100755
index 000..434b2fa
--- /dev/null
+++ b/meta-oe/recipes-extended/net-snmp/files/init
@@ -0,0 +1,63 @@
+#! /bin/sh
+# /etc/init.d/snmpd: start snmp daemon.
+
+test -x /usr/sbin/snmpd || exit 0
+test -x /usr/sbin/snmptrapd || exit 0
+
+# Defaults
+export MIBDIRS=/usr/share/snmp/mibs
+SNMPDRUN=yes
+SNMPDOPTS='-Lsd -Lf /dev/null -p /var/run/snmpd.pid'
+TRAPDRUN=no
+TRAPDOPTS='-Lsd -p /var/run/snmptrapd.pid'
+
+# Cd to / before starting any daemons.
+cd /
+
+case $1 in
+  start)
+echo -n Starting network management services:
+if [ $SNMPDRUN = yes -a -f /etc/snmp/snmpd.conf ]; then
+   start-stop-daemon -S -x /usr/sbin/snmpd \
+   -- $SNMPDOPTS
+   echo -n  snmpd
+fi
+if [ $TRAPDRUN = yes -a -f /etc/snmp/snmptrapd.conf ]; then
+   start-stop-daemon -S -x /usr/sbin/snmptrapd \
+   -- $TRAPDOPTS
+   echo -n  snmptrapd
+fi
+echo .
+;;
+  stop)
+echo -n Stopping network management services:
+start-stop-daemon -K -x /usr/sbin/snmpd
+echo -n  snmpd
+start-stop-daemon -K -x /usr/sbin/snmptrapd
+echo -n  snmptrapd
+echo .
+;;
+  restart|reload|force-reload)
+echo -n Restarting network management services:
+start-stop-daemon -K -x /usr/sbin/snmpd
+start-stop-daemon -K -x /usr/sbin/snmptrapd
+# Allow the daemons time to exit completely.
+sleep 2
+if [ $SNMPDRUN = yes -a -f /etc/snmp/snmpd.conf ]; then
+   start-stop-daemon -S -x /usr/sbin/snmpd -- $SNMPDOPTS
+   echo -n  snmpd
+fi
+if [ $TRAPDRUN = yes -a -f /etc/snmp/snmptrapd.conf ]; then
+   # Allow snmpd time to start up.
+   sleep 1
+   start-stop-daemon -S -x /usr/sbin/snmptrapd -- $TRAPDOPTS
+   echo -n  snmptrapd
+fi
+echo .
+;;
+  *)
+echo Usage: /etc/init.d/snmpd
{start|stop|restart|reload|force-reload}
+exit 1
+esac
+
+exit 0
diff --git a/meta-oe/recipes-extended/net-snmp/files/snmpd.conf
b/meta-oe/recipes-extended/net-snmp/files/snmpd.conf
new file mode 100644
index 000..728171c
--- /dev/null
+++ b/meta-oe/recipes-extended/net-snmp/files/snmpd.conf
@@ -0,0 +1,422 @@
+###
+#
+# EXAMPLE.conf:
+#   An example configuration file for configuring the ucd-snmp snmpd agent.
+#
+###
+#
+# This file is intended to only be an example.  If, however, you want
+# to use it, it should be placed in /etc/snmp/snmpd.conf.
+# When the snmpd agent starts up, this is where it will look for it.
+#
+# You might be interested in generating your own snmpd.conf file using
+# the snmpconf program (perl script) instead.  It's a nice menu
+# based interface to writing well commented configuration files.  Try it!
+#
+# Note: This file is automatically generated from EXAMPLE.conf.def.
+# Do NOT read the EXAMPLE.conf.def file! Instead, after you have run
+# configure  make, and then make sure you read the EXAMPLE.conf file
+# instead, as it will tailor itself to your configuration.
+
+# All lines beginning with a '#' are comments and are intended for you
+# to read.  All other lines are configuration commands for the agent.
+
+#
+# PLEASE: read the snmpd.conf(5) manual page as well!
+#
+
+
+###
+# Access Control
+###
+
+# YOU SHOULD CHANGE THE COMMUNITY TOKEN BELOW TO A NEW KEYWORD ONLY
+# KNOWN AT YOUR SITE.  YOU *MUST* CHANGE THE NETWORK TOKEN BELOW TO
+# SOMETHING REFLECTING YOUR

Re: [oe] Documentation problems

2011-11-29 Thread Frans Meulenbroeks

2011/11/28 Bernhard Guillon bernhard.guil...@opensimpad.org



 On Mon, 28 Nov 2011, Richard Purdie wrote:

  Rather than fork off the Yocto docs for OE's needs, it would be nice to
 see if there was a way we could share the documentation.


 I like that idea + the pull based model idea from Koen. In my opinion a
 pull based model for the documentation lower the barriers to write
 documentation because nobody want to write something false.


Of course I also do not want to write faulty documentation; then again I
also hate wasting my time, so I think I wouldn't even start if there was a
chance that my contribution might be rejected because the pull master does
not like my style or feels there are grammar errors or so.

(note that I am not a native english speaker so this is not too unlikely;
also if there are language errors in a contributed piece of documentation
on a wiki other people more proficient in english could correct those
easier and better than I ever can),

For me this raises the bar to contribute (not that I have contributed much
to our documentation...)

The issue with documentation
- everybody wants documentation
- hardly anyone wants to write documentation
- make it hard to write documentation and you'll end up with no
documentation.

BTW somewhere in the thread also the license issue was raised.
I'd suggest a form of creative commons with attribution clause.

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

Re: [oe] Documentation problems

2011-11-29 Thread Frans Meulenbroeks

2011/11/29 Khem Raj raj.k...@gmail.com

 Hi Frans,


Hi Khem, all


 On Tue, Nov 29, 2011 at 12:24 AM, Frans Meulenbroeks
 fransmeulenbro...@gmail.com wrote:
 
  Of course I also do not want to write faulty documentation; then again I
  also hate wasting my time, so I think I wouldn't even start if there was
 a
  chance that my contribution might be rejected because the pull master
 does
  not like my style or feels there are grammar errors or so.

 I consider someone reviewing my patches a good thing. I think it makes
 me learn things
 if there is feedback on the patches, I include the feedback and
 resubmit the patch and thereby improve it


Oh, I consider reviewing patches a good thing too. For documentation it
also depends on the process and the kind of comments.
If the person pulling the changes rejects them because (s)he finds the
grammar not ok and the review comment is improve grammar, that is fairly
demotivating (if I knew how to do so, I would have done that upfront).
A few of such rejects will make that most people loose the interest in
submitting documentation quite quickly.
And if you have to give detailed review comments or instructions reviewing
becomes quite time consuming (actually more time consuming than actually
making the change yourself)

That is somewhat the advantage of a wiki. You can contribute to the best of
your abilities and others can extend with their knowledge, expertise and
language skills.
Then again, I understand that there is a risk that faulty information is
created (as was also expressed by Koen). However I cannot really recall big
such problems with our wiki.

There is of course another problem (which does surface every once in a
while). Sometimes people write pieces based upon outdated information. And
even if not, the information itself will become outdated.
E.g. if we deprecate PR (which is a good idea btw) this needs to be changed
in the wiki too. That is a part of the process that is not really well
developed.
outdated information is equally wrong as other faulty information.

As stated before, for most people writing documentation is not particularly
fun, so it should be made easy with few annoyances. Make it hard and you
will hardly get contributions. Turn people down a few times and they are
gone.



 
  (note that I am not a native english speaker so this is not too unlikely;

 neither am I.

  also if there are language errors in a contributed piece of documentation
  on a wiki other people more proficient in english could correct those
  easier and better than I ever can),

 right now there is no review process for wiki. So if I write a
 document it does not get notified
 to people and chances of someone really stumbling into this new piece
 are new users who are studying
 that document and I think reviewing it beforehand is a good thing
 since I might have written it wrong
 besides grammar errors. I think wrong documentation is worse than no
 documentation.


I agree with the wrong documentation is worse than no documentation.
I'm not sure whether there are no wiki plugins to allow notification.
(and it is always possible to examine the recent changes page, but that is
not really convenient).

BTW it is always possible to lock certain pages and only allow a limited
set of users to edit those pages. I can imagine this is done wth the pages
that are considered core.

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

Re: [oe] Documentation problems

2011-11-29 Thread Frans Meulenbroeks

2011/11/30 Tom Rini tom.r...@gmail.com

 On Tue, Nov 29, 2011 at 2:46 PM, Frans Meulenbroeks
 fransmeulenbro...@gmail.com wrote:
  2011/11/29 Khem Raj raj.k...@gmail.com
 
  Hi Frans,
 
 
  Hi Khem, all
 
 
  On Tue, Nov 29, 2011 at 12:24 AM, Frans Meulenbroeks
  fransmeulenbro...@gmail.com wrote:
  
   Of course I also do not want to write faulty documentation; then
 again I
   also hate wasting my time, so I think I wouldn't even start if there
 was
  a
   chance that my contribution might be rejected because the pull master
  does
   not like my style or feels there are grammar errors or so.
 
  I consider someone reviewing my patches a good thing. I think it makes
  me learn things
  if there is feedback on the patches, I include the feedback and
  resubmit the patch and thereby improve it
 
 
  Oh, I consider reviewing patches a good thing too. For documentation it
  also depends on the process and the kind of comments.
  If the person pulling the changes rejects them because (s)he finds the
  grammar not ok and the review comment is improve grammar, that is
 fairly
  demotivating (if I knew how to do so, I would have done that upfront).

 This would be just as bad as reviewing a patch and saying only fix
 the things that are wrong.  Both are equally unacceptable, and
 frankly at this point in the projects life, equally unlikely.


Hm. I'm not too sure about this. With a patch it is much easier to
distinguish between right and wrong.
With explanatory text the scale is much wider, and for text I suggest to
look at the content (which obviously should be technically ok) and perhaps
a little bit less at style and grammar (but of course it should remain
understandable).



  A few of such rejects will make that most people loose the interest in
  submitting documentation quite quickly.
  And if you have to give detailed review comments or instructions
 reviewing
  becomes quite time consuming (actually more time consuming than actually
  making the change yourself)

 Which probably means the commenter knows enough that they should have
 made the documentation change to start with.  This is the price to pay


I'm not sure about this. It could well be that a reviewer comments on style
and structure, even though (s)he cannot judge the technical details (and
therefore probably could not write the piece himself).
And I feel we have some people that seem to like it to pick on other people
not following the guidelines they are not willing to document.


 for not doing the edits directly.  Personally, I've been willing to
 pay that cost and explaining it to someone else helps make sure I
 really understand it and that the code is also really correct.


Sure. I understand and appreciate that.
Then again for code sometimes the feedback that is given with rejected
patches is neither helpful nor stimulating.
If that happens with documentation too, soon someone will end up whining
that no one wants to contribute to the documentation.

My two cents.
Frans.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [meta-oe] digitemp: fix QA issues:

2011-11-28 Thread Frans Meulenbroeks

2011/11/28 Khem Raj raj.k...@gmail.com

 On Mon, Nov 28, 2011 at 12:26 AM, Koen Kooi k...@dominion.thruhere.net
 wrote:
 
  Op 28 nov. 2011, om 03:17 heeft Khem Raj het volgende geschreven:
 
  On Sun, Nov 27, 2011 at 4:04 AM, Koen Kooi k...@dominion.thruhere.net
 wrote:
  -EXTRA_OEMAKE = ds9097 ds9097u
  +EXTRA_OEMAKE = ds9097 ds9097u \
  +SYSTYPE='Linux' \
  +   
  +# Fix GNU_HASH QA errors
  +TARGET_CC_ARCH += ${CFLAGS} ${LDFLAGS}
 
 
 
  why CFLAGS ? I thought only LDFLAGS would have been sufficient
 
  For GNU_HASH yes, but the buildsystem was ignoring both CFLAGS and
 LDFLAGS.
 

 bug in the build system I would say

 Actually personally I'd say passing CFLAGS and LDFLAGS to TARGET_CC_ARCH
is a workaround and the real solution is patching the build system to not
to ignore those flags.

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

Re: [oe] Plans for OE classic future

2011/11/26 Bernhard Guillon bernhard.guil...@opensimpad.org



 On Wed, 23 Nov 2011, Philip Balister wrote:

  At some point it needs to die/go read only.

 But, until oe-core + openembedded can replace it, we need to be able to
 do minor updates to support already deployed systems.


 We need to rewrite the getting started wiki page [1] to point to oe-core.
 It still mentions oe-classic which confuses new users. Also the main page
 should make it clear that oe-classic is going to die and new projects
 should use oe-core. In my opinion this will help new users more than to
 make oe-core read only. Some warning message when bitbakeing something with
 oe classic would also be nice.

 1 http://www.openembedded.org/wiki/Getting_started


Very good plan!
I wholehearty agree!

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

Re: [oe] Plans for OE classic future

2011/11/26 Tom Rini tom.r...@gmail.com

 On Sat, Nov 26, 2011 at 8:45 AM, Frans Meulenbroeks

 
  Well, there is at least the issue of machines and architectures.
  Now it is probably not too big a deal to bring over a new machine and
 turn
  it into a BSP layers, but adding another architecture is yet another
 thing.
 
  We do have products that are based upon NIOS II. This architecture is
  present in OE classic and not in OE core.
  One of the issues is that the NIOS II toolchain is still based upon
 (iirc)
  gcc 4.1.1
  I do not see an upgrade of gcc/niosii happen in the near future (In the
  past I did spent some time to see if I could move to a newer version, but
  there were some issues, and afaik no one is working on this atm), and I
  doubt oe-core is interested in having a 4.1.1 toolchain around.

 An external toolchain should be fine.  You should also be able to put
 that gcc  company into meta-niosii.  If you can't, then IMHO, there's
 a problem someone needs to look at.  But I suspect there isn't a
 problem doing that.


In oe-classic it is not an external toolchain. It is also a CPU
architecture.
It mgiht be possible to make an external toolchain for it, but that does
not allow
saying things in recipes like: FILES_niosii += in other recipes (iirc there
are a few of these)

Moving the recipes to meta-niosii could also be done, and is probably
better as the toolchain is a set of OE recipes. I'm not sure if it is
possible to solve the ARCH problem that way, but one might get away with it
by e.g. bbappend-ing in all relevant recipes. This seems a fair amount of
work, so I guess this is not going to happen overnight.

BTW if this is felt to be a good plan then we might consider moving all
arch specific bits into an arch specific layer. (not too sure if that is a
good plan though).


  Therefore probably our next niosii project will still be oe-classic
 based.
  On the other hand we also have ppc projects and the next one might quite
  well use oe-core (it is too late to switch for the current one as we need
  to release next month).
 
  (and more general: oe classic still has quite some recipes that are not
 in
  oe-core or meta-oe (apart from the fact that the latter is not really too
  open to contributions; see the email thread on id3lib from a while ago).

 Where someone asked Koen to document the differences between oe-core
 requirements and meta-oe requirements?  Yes, that's reasonable but
 lets not fool ourselves either, it's not vastly different, it's PR =
 r0 or not (and PR is supposed to go away).


I feel that if meta-oe is considered an openembedded layer, its guidelines
should be made clear.
Also in that case it does seem desirable to use the same guidelines as OE
core uses where possible and only deviate if really needed (and in the PR
case there is probably no such compelling reason).
This last section may be off-topic for the discussion at hand, but it might
explain some of the reluctance to contribute to meta-oe and move to meta-oe.

Might be a topic for the TSC to discuss too.

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

Re: [oe] Plans for OE classic future

2011/11/27 Tom Rini tom.r...@gmail.com



 So the question is, what is the long term plan for classic OE based
 stuff?  The TSC has been saying, perhaps not with enough voice or
 emphasis:
 - 2011.03 is the last release of oe.dev (unless someone(s) step up
 and wish to do another!)
 - 2011.03-maintenance will be maintained as long as people are saying
 they have a need for it.
 - The master branch needs to go away somehow as the last step of
 migration.  This is what I was trying to say below...

  In my mind, we couldn't do a technical branching of the repository, we
  made a new one. But people are still working off of a branch made
  against an 8 month old snapshot.  We really want to encourage this to
  stop.  If we were all in one repository still, it would be people
  saying don't make legacy/main read-only!  I still want to add things
  to it!.
 
  I did not understand that paragraph. Sorry.

 The analogy I'm trying to make between classic OE master branch and
 behavior is that it wasn't lets start from scratch with this new
 repository and hope someday most people stop using the old tree it
 was if we could cleanly do a 'git branch -m master legacy' and start
 master as the new meta-oe repository, we would.

 Now I'm going to make a Linux Kernel analogy.  The 2.4 series didn't
 (nearly) go away for a long while after 2.6 came out, but after a
 while the rules for what could go in got rather restrictive.

 The direction the TSC has recommended for how to deal with classic OE
 is to have the folks that can't yet move off of it be using the
 maintenance branch.  It's not going to be pulled out from under
 anyone.  It's just got rules about what kind of changes are allowed
 in.  Today that's must exist in relevant oe-core based layer or be
 N/A in that world.  I can't imagine that changing until the user base
 is small enough and themselves in a maintenance mode to be happy with
 that too.

 If anything it seems like there's an objection to switching classic OE
 from free for all to the pull request (or patches posted) model
 oe-core/meta-oe/etc are using.

 Personally I think we are not yet at at point where we should move OE
classic to a pull/patches model. Give it some time.

I understand the concerns with people using master for new projects, but I
also understand the concerns of people that for one reason or another are
still bound to oe-classic.

I feel that it also would be helpful to have some sort of staging area
where people can update things before they are pulled. Doing that
distributed not really creates visibility to those changes, so I'd say it
is better to keep that centralized. Might even be more convenient too.

That still leaves the issue of new projects.
What if we decide to rename master to e.g. maintenance-staging, or legacy,
or classic or whatever you want to; keeping it as it is now (so not R/O),
and have a new master that is R/O and only contains a document with some
explanation and referring to oe-core for new projects. This doc could
mention the legacy branch together with a statement that it is not desired
for new projects, but mainly there for maintenance/testing purposes.

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

Re: [oe] Documentation problems

What is the problem with being it a wiki (probably with authorized users to
avoid spam).

I'd say let everyone who wants to contribute.
If someone makes a mistake it can easily be corrected and/or reverted, and
if someone messes things up on purpose and/or creates more bad than good
such a (non)contributor can be banned.

Disadvantage of a pull model is:
- more difficult to make changes (e.g. if I see a typo in a wiki and I have
write permission, I'll fix it; however if it invokes checking out a file,
make the edit, commit it, mail a pull request, most likely I'll decide it
is not worth the effort
- more administrative workload (that is probably better spent on actually
doing things).
- It sends out a message of distrust. Not really a good way to create
involvement.

One might feel that it improves quality; then again also in a wiki one can
review and improve (or revert) changes.

As far as I see it we are all adults (at least I think so) all interested
in improving OE so no unnecessary barriers should be raised.

Frans.

PS: it is quite possible to backup a wiki (and I hope this is done at
regular intervals with our wiki). Also all edits are recorded so they can
always be tracked back and (if needed) undone.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] Plans for OE classic future

2011/11/27 Tom Rini tom.r...@gmail.com

 On Sun, Nov 27, 2011 at 3:12 AM, Frans Meulenbroeks
 fransmeulenbro...@gmail.com wrote:
  Personally I think we are not yet at at point where we should move OE
  classic to a pull/patches model. Give it some time.

 So, why are we not at that point yet for OE classic?  I'd like to
 think I've been timely in my pulls.


I'm not saying you are not timely. Au contraire, you are.


  I understand the concerns with people using master for new projects, but
 I
  also understand the concerns of people that for one reason or another are
  still bound to oe-classic.
 
  I feel that it also would be helpful to have some sort of staging area
  where people can update things before they are pulled. Doing that
  distributed not really creates visibility to those changes, so I'd say it
  is better to keep that centralized. Might even be more convenient too.

 We already have this for oe-core/meta-oe so it shouldn't be hard to
 make up a contrib repo for classic OE, for folks that don't want to
 just fork the mirror on github.


Whether it is a branch or a separate repo does not make too much of a
difference (at least not to me).
It was my impression that a branch would work a little bit simpler, but I
may well be mistaken here.


  That still leaves the issue of new projects.
  What if we decide to rename master to e.g. maintenance-staging, or
 legacy,
  or classic or whatever you want to; keeping it as it is now (so not R/O),
  and have a new master that is R/O and only contains a document with some
  explanation and referring to oe-core for new projects. This doc could
  mention the legacy branch together with a statement that it is not
 desired
  for new projects, but mainly there for maintenance/testing purposes.

 The only part here I object to is saying we need an anyone-can-write
 branch.


If it is a contrib repo or overlay fine with me.
I do think it is probably convenient that it should be an
anyone-who-is-authorized-can-write repo/overlay/branch/whatever, in order
not to unneededly raise the barrier to submit patches.

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

Re: [oe] Documentation problems

Generally speaking writing documentation is difficult and a task not liked
by most sw developers (me included).
People should be encouraged and it should be as easy as possible.
The more difficult it is, the less likely it is people will do it.

Then again I am not too sure what we need, given the yocto documentation.

BTW and if a certain part of the wiki is for a specific purpose (e.g.
related to a distro): in most wiki's it is possible to restrict access to
certain pages to a specific group.
Then again that all needs to be managed

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

Re: [oe] Plans for OE classic future

2011/11/27 Tom Rini tom.r...@gmail.com

 On Sun, Nov 27, 2011 at 10:25 AM, Frans Meulenbroeks
 fransmeulenbro...@gmail.com wrote:
  2011/11/27 Tom Rini tom.r...@gmail.com
 
  On Sun, Nov 27, 2011 at 3:12 AM, Frans Meulenbroeks
  fransmeulenbro...@gmail.com wrote:
   Personally I think we are not yet at at point where we should move OE
   classic to a pull/patches model. Give it some time.
 
  So, why are we not at that point yet for OE classic?  I'd like to
  think I've been timely in my pulls.
 
  I'm not saying you are not timely. Au contraire, you are.

 OK.  So provided we have an easy way to make pull requests of trees
 hosted on oe.org (like oe-core/meta-oe today), are there any other
 objections to moving towards pull request model for classic OE?


My whole point is that things should be easy for those who want to
contribute.
And it should be clear what goes in and how it should be done (and not like
in some other place where it seems to be left to the discretion of the pull
god, note that I am quite happy with the way you do your job).


   I understand the concerns with people using master for new projects,
 but
  I
   also understand the concerns of people that for one reason or another
 are
   still bound to oe-classic.
  
   I feel that it also would be helpful to have some sort of staging area
   where people can update things before they are pulled. Doing that
   distributed not really creates visibility to those changes, so I'd
 say it
   is better to keep that centralized. Might even be more convenient too.
 
  We already have this for oe-core/meta-oe so it shouldn't be hard to
  make up a contrib repo for classic OE, for folks that don't want to
  just fork the mirror on github.
 
 
  Whether it is a branch or a separate repo does not make too much of a
  difference (at least not to me).
  It was my impression that a branch would work a little bit simpler, but I
  may well be mistaken here.

 My understanding of the git server side of things is a contrib repo is
 easier to setup and manage permission-wise.

I can't comment on that as I have no knowledge on the server side. I'm
looking at it from a user/contributor perspective.


   That still leaves the issue of new projects.
   What if we decide to rename master to e.g. maintenance-staging, or
  legacy,
   or classic or whatever you want to; keeping it as it is now (so not
 R/O),
   and have a new master that is R/O and only contains a document with
 some
   explanation and referring to oe-core for new projects. This doc could
   mention the legacy branch together with a statement that it is not
  desired
   for new projects, but mainly there for maintenance/testing purposes.
 
  The only part here I object to is saying we need an anyone-can-write
  branch.
 
 
  If it is a contrib repo or overlay fine with me.
  I do think it is probably convenient that it should be an
  anyone-who-is-authorized-can-write repo/overlay/branch/whatever, in order
  not to unneededly raise the barrier to submit patches.

 So, like we do today for openembedded-core-contrib /
 meta-openembedded-contrib?

 Sorry but since all my projects are still based upon oe-classic, I never
bothered to peek at those.

Anyway these are my opinions. There were some others that had concerns. Not
sure how they feel about it.
And it is good that we come to a plan and define a workflow and a migration
path.

The original statement by someone saying OE classic will be R/O soon, was
a little bit too quick and too incomplete for the community I think. At
least it was for me.

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

Re: [oe] Plans for OE classic future

2011-11-26 Thread Frans Meulenbroeks

2011/11/25 Tom Rini tom.r...@gmail.com



 Putting on TSC hat
 The problem with this mindset is that we don't want to have
 oe-core+meta-oe+etc and oe.dev diverge any more than they had at the
 start.  This is why at some point master needs to become read-only.
 Everyone and their master based project can still fetch and build and
 work.  But if you're going right now and saying I need to start a new
 project and it should be oe.dev+master based, please speak up now
 about why you're unable to use oe-core+etc.  We can't solve what we
 don't know is a problem and frankly I think the TSC is of the mind
 that oe-core+etc is as good as or better than oe.dev.  If we're wrong,
 someone needs to tell us what's missing.


Well, there is at least the issue of machines and architectures.
Now it is probably not too big a deal to bring over a new machine and turn
it into a BSP layers, but adding another architecture is yet another thing.

We do have products that are based upon NIOS II. This architecture is
present in OE classic and not in OE core.
One of the issues is that the NIOS II toolchain is still based upon (iirc)
gcc 4.1.1
I do not see an upgrade of gcc/niosii happen in the near future (In the
past I did spent some time to see if I could move to a newer version, but
there were some issues, and afaik no one is working on this atm), and I
doubt oe-core is interested in having a 4.1.1 toolchain around.

Therefore probably our next niosii project will still be oe-classic based.
On the other hand we also have ppc projects and the next one might quite
well use oe-core (it is too late to switch for the current one as we need
to release next month).

(and more general: oe classic still has quite some recipes that are not in
oe-core or meta-oe (apart from the fact that the latter is not really too
open to contributions; see the email thread on id3lib from a while ago).

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

Re: [oe] Plans for OE classic future

2011-11-26 Thread Frans Meulenbroeks

2011/11/26 Tom Rini tom.r...@gmail.com

 On Sat, Nov 26, 2011 at 3:57 AM, Ulf Samuelsson
 ulf_samuels...@telia.com wrote:
  On 2011-11-25 23:04, Tom Rini wrote:
 
  On Fri, Nov 25, 2011 at 12:31 AM, Frans Meulenbroeks
  fransmeulenbro...@gmail.com  wrote:
 
  After all, isn't one of the purposes of OE to promote information
  sharing,
  cooperation and the use of openembedded technology (and not make things
  harder).
 
  One of the points of making master read-only would be to ensure that
  changes aren't lost.
 
  Perhaps the transition needs to be:
  - master is as it is today
  - master becomes oe-core backport || master-only bugfixes only
  - master becomes read only.
 
  And we go from the first step to the second step sometime sooner
  rather than later.  The top of my head date would be before the
  paid-developers go on end of year breaks to try and make sure all the
  hobbyist folks start their hacking with oe-core+etc rather than master
  and risk getting caught later.  I'm open to arguments on why that's
  exactly backwards...
 
 
  Won't it be a problem for existing projects, if you cannot add fixes to
 cope
  with new host OS versions.
 
  At the moment, openembedded-classic does not build properly with Ubuntu
  11.10 .

 Won't what be a problem?  Either oe-core+meta-oe+etc fails on 11.10
 (so, fix it there first then backport changes) or it's fine and you
 can either find the relevant changes there and move them or it's a
 oe.dev-only bug and just needs to be fixed, under my proposal (until
 we reach the point where everyone is OK calling it r/o).

 And part of this is to say that yes, existing projects external to
 oe.dev need to move to oe-core(+meta-oe+whatever else) (where layers
 should be making their life easier or again, there's problems we're
 unaware of and need to be made aware of) or explain why they can't
 ever move (and are forking the project?).


See the message on NIOS that I just posted.
Also I am not opposed to making oe classic master the place where patches
may land before they end up in the maintenance thread, but I am strongly
opposed to making OE classic read only on short notice (which as suggested
by Koen earlier).

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

Re: [oe] Plans for OE classic future

2011-11-26 Thread Frans Meulenbroeks

2011/11/25 Tom Rini tom.r...@gmail.com

 On Thu, Nov 24, 2011 at 1:33 PM, Paul Menzel
 paulepan...@users.sourceforge.net wrote:
  Am Donnerstag, den 24.11.2011, 09:06 -0800 schrieb Khem Raj:
  On (24/11/11 10:31), Frans Meulenbroeks wrote:
   2011/11/24 Koen Kooi k...@dominion.thruhere.net
  
OE .dev will go read-only soon, If you need an OE-classic setup,
2011.03-maintenance is there for you.
  
   As stated before there are still people using .dev and committing to
 it
   [1], and there are people interested in keeping it that way for a
 while.
   So as it stands I suggest to keep it open for a while for those that
 still
   are interested to use it.
 
  I would suggest that people interested in oe classic should use 2011.03
  branch since its maintained and tested regularly. Its in their best
  interest too since there are people behind the branch and it gets
  regular bug fixes thats not true for master.
 
  That statement is not true as far as I can see from the commit log.
  Almost all patches to 2011.03-maintenance went through master.

 Yes, but that's also due, in general to the nature of the branch.
 Angstrom/TI related stuff was going master-2011.03-maintenance before
 I clarified that coming from oe-core is also fine.  As of yet, no one
 else has stepped up and said I need DISTRO=foo MACHINE=bar working
 here, and I intend to keep an eye on things.  Having angstrom-2008.1
 in there seems to be good enough for most cases.


Forgot to mention this in my previous email, but I do have an interest in
minimal and minimal-uclibc for mpc8313. Then again virtually all of my work
is console only, so I'm not really into a position to test lots of things.
I'm keeping an eye on things though and have one or two patches pending
(e.g. our current netsnmp version and uclibc do not seem to be friends).
Personally I prefer to commit these patches to master and issue a pull
request for them and I prefer it if others do the same, so we have a
centralized location, instead of a gazillion git trees at several places.

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

Re: [oe] Plans for OE classic future

2011-11-24 Thread Frans Meulenbroeks

2011/11/24 Koen Kooi k...@dominion.thruhere.net



 OE .dev will go read-only soon, If you need an OE-classic setup,
 2011.03-maintenance is there for you.


As stated before there are still people using .dev and committing to it
[1], and there are people interested in keeping it that way for a while.
So as it stands I suggest to keep it open for a while for those that still
are interested to use it.

People not interested in oe classic can safely ignore it, but I feel there
is no need to complicate the life of the people that for whatever reason
still need access and are interesting to commit to it.

Frans.

[1] http://cgit.openembedded.org/openembedded/log/
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] Plans for OE classic future

2011-11-24 Thread Frans Meulenbroeks

2011/11/24 Otavio Salvador ota...@ossystems.com.br

 On Thu, Nov 24, 2011 at 08:23, Hauser, Wolfgang (external) 
 wolfgang.hauser.exter...@cassidian.com wrote:

  I would vote for an open classic master for bugfixing too, our project
  based on 2011.03-maintenance goes into the final phase and to switch to
  oe-core, the budged is not available jet.
 

 I also believe oe-classic master ought to be read-only as soon as possible;
 I understand that people are using it but the soonner we make it read-only,
 sooner people will move to oe-core otherwise people will keep starting new
 project on it and it will never die.

 People like Wolfgang, Mats and me are working on products that are at the
moment not in a position to move to oe-core.
Why would you want to deprive people in that situation from having a spot
(under the openembedded umbrella) under which they can share things.
Isn't sharing and cooperating what openembedded is all about ???

I understand you want people to move to oe-core, but really this should be
at the discretion of the users, and we should not give those who can not do
so right now a hard time.

Over time people will move to oe-core, as it will definitely be better
supported, have newer recipes etc. Actually for my next product I will
probably move over, but for now, with a release being imminent, moving is
not an option for me, and I consider having a place to share and exchange
bug fixes as useful.

My two cents.
Frans.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] Plans for OE classic future

2011-11-24 Thread Frans Meulenbroeks

Some global comments.

First of all I think it is good that we have this discussion, and that this
is discussed with the community, not solely within the TSC.

Wrt keeping master alive:

I feel it is better to have a central spot to put patches to be cherry
picked, than everyone making e.g. his own github project (at least having a
central spot is less work and less cumbersome).
Cherry picking from oe-core/meta-oe is of course also possible, but also
has a higher chance to encounter problems. E.g. the patch may not apply or
the recipe may not be parseable by the bitbake used in maintenance (because
oe-core uses a newer bitbake or different class files).

Also switching from master to the maintenance branch may not be possible
for all projects. This may depend on phase of the project, internal
policies, time etc.
(actually I did a test to move one of my projects to the maintenance
branch, several of the recipes did not fetch any more (mostly due to the
kernel.org situation))

For me, and from reading the discussion master still serves a need for some
of us, so why close it down. Actually I have not really heard any
compelling (compelling to me that is) reason to close it down.
Yes, for new projects most likely oe-core is the best choice, but I feel
people are capable enough to make that choice themselves; and, over time,
both the classic master branch and maintenance branch will die. For now it
is still useful for some of us, so my preference would be to keep it
available and writable (if only as a sort of 'alpha/draft' version of
maintenance).

After all, isn't one of the purposes of OE to promote information sharing,
cooperation and the use of openembedded technology (and not make things
harder).

Best regards, Frans

'PS: Thinking of it, we might consider a README file; and/or some text in
the git description to suggest not to use classic for new developments.
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] Plans for OE classic future

2011-11-23 Thread Frans Meulenbroeks

2011/11/23 Khem Raj raj.k...@gmail.com

 On Thu, Oct 27, 2011 at 3:53 AM, Mats Kärrman mats.karr...@tritech.se
 wrote:
  Hi,
 
  Are there any plans for new releases and/or maintenance branches of OE
 classic?
 

 2011.03-maintenance is the last release of OE classic. As long as the
 branch is maintained

 _

 Related: I noticed TSC plans to discuss on whether or not to make oe
classic read only.

I'd like to suggest leaving it open for those of us that are still using
it.
For instance I have still products that are based on OE classic. If there
is a problem that is of a generic nature, I'm more than happy to submit
patches so others in the same situation can benefit from it.
(actually I have one pending with a new version of netsnmp; the current
recipe does not build with uclibc, whereas the latest version of netsnmp
does; found/fixed this today, but haven't had time to make a commit)

And if there is no interest any more it'll eventually die. But as of now I
do see people working on/with it (see the commit log).

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

Re: [oe] [meta-efl][meta-oe 05/12] id3lib: Import from openembedded classic

2011-10-31 Thread Frans Meulenbroeks

2011/10/31 Koen Kooi k...@dominion.thruhere.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Op 31-10-11 22:18, Philip Balister schreef:
  On 10/31/2011 01:48 PM, Koen Kooi wrote:
  Op 31-10-11 17:24, Paul Menzel schreef:
  Am Montag, den 31.10.2011, 11:50 +0100 schrieb Koen Kooi:
  Op 29-10-11 14:33, Paul Menzel schreef:
  Dear Martin, dear Denis,
 
 
  Am Samstag, den 29.10.2011, 12:29 +0200 schrieb Martin Jansa:
  From: Denis 'GNUtoo' Carikli gnu...@no-log.org
 
  Added LIC_FILES_CHKSUM, and fixed LICENSE
 
  Signed-off-by: Denis 'GNUtoo' Carikli gnu...@no-log.org
  Signed-off-by: Martin Jansa martin.ja...@gmail.com
 
  NACK.
 
  please add the version you import and the commit ID you import
  from. This is all written in the guide lines [1]!
 
  And as I've said before, meta-oe is not oe-dev, so you can't use
  take the old 'rules' and apply them to meta-oe 1:1!
 
  The guide lines I referred to [1] have been written for OE-core. ;-)
 
  Yes, and oe-core still isn't meta-oe
 
  Why would we need different guidelines?

 Different goals I guess. And I don't trust a ruleset that's in a wiki, too
 much room for people coming in and messing it up.

 As far as I recall the idea was that meta oe should follow the same
guidelines as oe core.
When was this changed?
Who decided this?
And if there need to be different guidelines, I feel it is useful to
document them somewhere (and probably also why it deviates from oe-core).

Anyway, I think I start to understand why so few people are willing to
contribute to meta-oe.

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

Re: [oe] [oe-commits] Khem Raj : binutils-cross: Sync with oe-core

2011-10-18 Thread Frans Meulenbroeks

2011/10/17 Khem Raj raj.k...@gmail.com

 On 10/16/2011 11:35 PM, Frans Meulenbroeks wrote:



 I feel if a distro or bsp needs a version of a package that is older than
 the oe-core one, it should be stored in the distro or bsp layer.
 Or is meta-oe also wanting to keep binutils 18.50? In oe classic this is
 used by the nios2 hw (and afaik there is no newer binutils supporting
 nios2)? I'd say if some layer needs older versions it is up to them.


 This is a bit different when a version is retired from oe-core there might
 be more than one bsp using it therefore it would be more beneficial to keep
 it in a common layer


The risk is that over time this common layer ends up being a repo with
several versions of a recipe, and for some of these we end up having no idea
whether or not they are used.
We've seen in oe classic to what that leads. Here, with layers being
distributed it becomes even more vague what is used and what not.
I'd say if oe core moves forward then a layer that is not ready to move to
that new version should either keep a local copy or pin at a hash of oe-core
before the recipe was removed.
BTW if I recall correctly it was discussed to have an overlap period after
introducing a new version before the old one is deprecated. Not 100% sure if
that was indeed decided that way.


  What we are lacking here is a policy on purpose/goal of meta-oe and what
 goes in (and what not).


 This has been discussed quite a bit when we decided to move to layered
 structure. meta-oe infact is an umbrella of layers and each layer can have
 it own development policies.


Guess your are mixing up meta-openembedded (
http://git.openembedded.org/meta-openembedded/tree/) and meta-oe  (
http://git.openembedded.org/meta-openembedded/tree/meta-oe)
(and as far as I know the policys on the common stuff (assuming we see
meta-oe or meta-openembedded as common stuff) is not really documented
afaik).

Btw I feel it does not really help to have some gnome stuff in
meta-oe/recipes-gnome and other in meta-gnome.

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

Re: [oe] [oe-commits] Khem Raj : binutils-cross: Sync with oe-core

2011-10-17 Thread Frans Meulenbroeks

2011/10/17 Khem Raj raj.k...@gmail.com

 On Sun, Oct 16, 2011 at 2:37 PM, Andrea Adami andrea.ad...@gmail.com
 wrote:
  On Sat, Oct 15, 2011 at 8:51 PM, g...@git.openembedded.org wrote:
 
  Module: meta-openembedded.git
  Branch: master
  Commit: 92b02b7209e426a70cc5626e7bdbc82052e01ac5
  URL:
 
 http://git.openembedded.org/?p=meta-openembedded.gita=commit;h=92b02b7209e426a70cc5626e7bdbc82052e01ac5
 
  Author: Khem Raj raj.k...@gmail.com
  Date:   Sun Oct 16 01:28:32 2011 +
 
  binutils-cross: Sync with oe-core
 
  Now we have own copy of binutils-cross in meta-oe
 
 
  I can't unfortunately find the discussion which supposedly provided a
 valid
  reason for binutils-2.20 in meta-oe while binutils-2.21 is in oe-core.
  I'm against that kind of policy for meta-oe, particularly when it's about
  toolchain.

 oe-core is deprecating versions that are still used by consumers of
 meta-oe (mainly angstrom 2010 release)
 since its toolchain and it will also benefit derivatives of angstrom.
 Angstrom could also move these elements
 into meta-angstrom if we think that its only angstrom specific and no
 other consumers of oe-core needs them
 layer maintainers make judgement call which they think should benefit
 wider community

 similar but not for binutils here is a relevant thread


I feel if a distro or bsp needs a version of a package that is older than
the oe-core one, it should be stored in the distro or bsp layer.
Or is meta-oe also wanting to keep binutils 18.50? In oe classic this is
used by the nios2 hw (and afaik there is no newer binutils supporting
nios2)? I'd say if some layer needs older versions it is up to them.

What we are lacking here is a policy on purpose/goal of meta-oe and what
goes in (and what not).

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

Re: [oe] OE TSC meeting 11 August 2011 (re-send)

2011-10-05 Thread Frans Meulenbroeks

2011/10/4 Jeff Osier-Mixon je...@jefro.net

 Hi Frans

 Sent to the list, and there is also a link at
 http://www.openembedded.org/wiki/TSC


Saw the resend and the link. Thanks! Frans
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] OE TSC meeting 11 August 2011 (re-send)

2011-10-03 Thread Frans Meulenbroeks

Any chance on also getting a resend of the sep 1 minutes?

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

Re: [oe] `PR = r0`: Add or not to add?

2011-09-01 Thread Frans Meulenbroeks

2011/9/1 Philip Balister phi...@balister.org

 On 08/31/2011 06:43 AM, Otavio Salvador wrote:

 On Wed, Aug 31, 2011 at 10:30, Koen 
 Kooikoen@dominion.thruhere.**netk...@dominion.thruhere.net
  wrote:

 Besides, this is also on the policy


 The OE classic policy maybe, not on the meta-oe policy[1].


 ETOOMANYPOLICIES

  so or you change the policy or you follow it. Otherwise makes no sense to
 have a policy if the person who merge the patches do not follow it.


 - From 
 http://wiki.openembedded.org/**index.php/Category:Policyhttp://wiki.openembedded.org/index.php/Category:PolicyI
  read:

 http://wiki.openembedded.org/**index.php/Commit_Patch_**
 Message_Guidelineshttp://wiki.openembedded.org/index.php/Commit_Patch_Message_Guidelines
 http://wiki.openembedded.org/**index.php/Commit_Policyhttp://wiki.openembedded.org/index.php/Commit_Policy
 http://wiki.openembedded.org/**index.php/Commit_log_examplehttp://wiki.openembedded.org/index.php/Commit_log_example
 http://wiki.openembedded.org/**index.php/Styleguidehttp://wiki.openembedded.org/index.php/Styleguide
 http://wiki.openembedded.org/**index.php/Versioning_Policyhttp://wiki.openembedded.org/index.php/Versioning_Policy

 And none of those say PR = r0 is wanted behaviour. OTOH it doesn't say
 it's
 unwanted either.


 So until it is explicit we might keep PR = r0 as it seems most people
 prefer this way.


 As long as we are all chiming in, I would like to see all of us decide once
 and for all what to do.

 I also prefer the explicitly setting PR = r0. Can we work out the
 troublesome cases and see if we can get them fixed? Also, what is the
 oe-core view on this?

 Let's work out what the technical answer is and go from there


Good plan.

BTW not sure if it is feasible but ideally a 2nd assingment to a var should
give an error (or at least a warning). This avoids that e.g. a recipe and a
.inc file set the var (or that a var is set twice within the same recipe, in
the past I have seen this). If a variable is intended to be reassigned, weak
binding should be used. ( ?= or so).

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

Re: [oe] `PR = r0`: Add or not to add?

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

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Op 31-08-11 12:06, Paul Menzel schreef:
  Am Mittwoch, den 31.08.2011, 09:15 +0200 schrieb Koen Kooi:
  Op 31-08-11 01:06, Andreas Müller schreef:

 [...]



 
  please remove PR in new recipes
 
  Actually I would favor to leave them in.

 Well I don't, and atm I decide if it goes in or not.


Ah. God is back. (btw who decided you are the decision maker for these
things?).

Somehow  I had the impression that the number of active contributors in OE
was diminishing; Guess I now understand why.
Statements like this are probably not the best way to run a community
project and/or keep people motivated.


  The manual also advises to do this.

 The manual says a lot of things and was written for .dev, not OE-core or
 meta-oe.


Then make sure that people know how do do things (e.g. by updating the
manual for OE_core and/or meta-oe)


  To change that policy, I would favor a survey/poll so that not every
 developers says something different as s/he sees best fit.

 Be sure to include every other variable with a default in that poll in
 order to be consistent.

 There is quite a difference between this variable and most others.
If one changes a recipe a PR change is in virtually all cases mandatory.
Having a line
PR = r0
in the recipe increases the chance that updating PR is not forgotten.
(and most, if not all, other variables with a default value will not change
when a recipe is updated).

My two cents.
Do with it whatever you want to.

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

Re: [oe] `PR = r0`: Add or not to add?

2011/8/31 Paul Eggleton paul.eggle...@linux.intel.com

 On Wednesday 31 August 2011 13:16:50 Koen Kooi wrote:
  Op 31-08-11 13:55, Anders Darander schreef:
   To sad. It's a lot easier to remember to bump the PR, when PR actually
 is
   in the recipe. Thus, including PR=0 will often remove one issue with
   patches.
 
  That's what review is for, no?

 Surely you'd rather people have a better chance of getting it right the
 first
 time rather than you having to remind them for every patch? The almost
 insignificant burden of a PR = r0 in each recipe seems worthwhile to me
 if it
 even helps a single person remember.


Nah, no good, as it reduces the opportunities for Koen to send nasty
remarks.

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

Re: [oe] `PR = r0`: Add or not to add?

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

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Op 31-08-11 14:43, Anders Darander schreef:


[...]


 Just curious (and it might convince me and others) what issues have PR =
 r0 caused in .dev?

The most recent one in .dev was xorg .inc files. Some recipes had PR, some
 didn't, and some had INC_PR. In this specific case there should have been
 only one PR (or INC_PR) in the .inc.

 And of course the good old add PR=r0 to the .inc, making older recipes go
 backwards thing.

 In OE-core/meta-oe the most recent annoyance were the gcc recipes, which
 now
 finally have a centrally managed PR.

 No situation is perfect, but my *personal* experience is that not adding
 PR=r0 is *less* annoying than adding it.

 The big difference between classic OE and the OE-core way is that things
 are
 a lot cleaner to start with, so PR=r0 might be safer to use, but I'd like
 to
 err on the side of caution.

 If you all feel really strongly about PR=r0 I'd advice you to send patches
 to add it to recipes that need it in OE-core and after those get accepted
 send patches for the recipes in meta-oe.


inc files are to some extend evil. If an .inc file changes all recipes
depending on it should be rebuild and retested. In an ideal world this
happens, in a real world not.
Also if there is only one version of a recipe .inc does not really bring
much. It mostly complicates things as one now has two places to look at.
(apart from the fact that they allow introducing errors like the PR=r0 in
inc file).
Of course there are places where inc files have their merits. Excellent
example is gcc. However on quite some places they are not too useful (if I
recall the oe-core policy is to   (ideally) have only one or at most two
versions of a recipe)

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

Re: [oe] How to prevent fetching?

2011/8/31 Dave Beal db...@cardinalpeak.com

 My company is using OE to develop the embedded Linux infrastructure of a
 medical device.  The US government agency that approves such devices
 (FDA) requires that its source code be strictly controlled.  We would
 like to configure our OE installation to prevent the fetching of new
 source code except when we explicitly allow it.

 Is there a way to accomplish this that doesn't require modifying all the
 individual .bb files?  Is there a global configuration option that would
 prevent fetching?  I've looked through the OE and Bitbake User Manuals,
 but haven't found an answer.

 Thank you!

 Simplest way is to set up a premirror with all source packages you need;
then change the routing table of your build system allowing only routing to
your premirror (and maybe some other hosts you want to access during
development).
Personally I do this with a VM.
At a certain point you probably also want to pin your OE tree on a certain
git hash to avoid that suddenly you drag in new code (and new problems) late
in your development cycle.
When you have pinned a version you could still backport fixes and put them
in a local overlay.

Good luck!

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

[oe] isuses installing from scratch

2011-08-06 Thread Frans Meulenbroeks

Hi all,

Found the following issues when installing from scratch on ubuntu 11.04
Decided to use the getting started page.
http://wiki.openembedded.net/index.php/Getting_started
This page mentions 1.10.2 from berlios, but the latest version on berlios is
1.12.0
Can't change it in the wiki.

And 1.12.0 also needed python-ply iand python-progressbar installed.

And lastly the example for local.conf is not correct:

For building a .dev branch, in your local.conf file, you should have at
least the following three entries. Example for the Angstrom distribution and
the Openmoko gta01 machine:

BBFILES = /stuff/openembedded/recipes/*/*.bb
DISTRO = angstrom-2010.x
MACHINE = beagleboard

The text talks about gta01, example uses beagleboard

Can someone with edit rights fix this?

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

Re: [oe] unnecessary dependencies?

2011-08-01 Thread Frans Meulenbroeks

2011/8/1 Steffen Sledz sl...@dresearch-fe.de

 We are working on an application which requires libgssdp.

 libgssdp requires libsoup, libsoup inherits gnome, gnome inherits
 gtk-icon-cache, gtk-icon-cache rdepends hicolor-icon-theme. So this icon
 theme (probably a lot more gnome stuff) unnecessarily allocates place in our
 image (we do not have a GUI). :(

 Are these deps really necessary?


I know this does not answer your question, but if you do not have a GUI
maybe libgssdp is not the best choice for your project.
You could consider another upnp library (e.g. libupnp).

And ofc a workaround could be to simply nuke all nonneeded junk at image
creation time.

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

Re: [oe] [meta-oe][PATCH 0/2] Fix parse errors

2011-06-28 Thread Frans Meulenbroeks

2011/6/28 Koen Kooi k...@dominion.thruhere.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 28-06-11 16:59, Otavio Salvador wrote:
  On Tue, Jun 28, 2011 at 11:51, Koen Kooi k...@dominion.thruhere.net
 wrote:
  I'm not going pull those in, since the whole point was to not make them
  machine specific. RP has pushed a workaround for it so parsing
  continues. I'll push a proper fix for systemd later.
 
  What's the difference if the package will be built from same source?
 
  In case you change anything you'll need to rebuild all packages anyway
  so I see no gain in having it per package.

 It makes it easier to deploy updates for the main packages (e.g.
 sysvinit, systemd) to all the targets without having to build it for all
 targets. It's a weird optimization, but makes life a lot easier for
 people needing to support a ton of machines :)


Hm. saving some CPU cycles and wall clock time makes life a lot easier.
Guess you haven't too much of a life then :-)
No kidding, why not keep things simple. and elegant.
(and actually people needing to maintain a lot of machines and keeping them
up to date is somewhat an oddity anyway; My experience is that most embedded
developers need to support only a few machines and typically freeze their
sources and stabilize their product).

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

Re: [oe] [meta-oe][PATCH 0/2] Fix parse errors

2011-06-28 Thread Frans Meulenbroeks

2011/6/28 Tom Rini tom_r...@mentor.com

 On 06/28/2011 10:14 AM, Frans Meulenbroeks wrote:
  2011/6/28 Koen Kooi k...@dominion.thruhere.net
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  On 28-06-11 16:59, Otavio Salvador wrote:
  On Tue, Jun 28, 2011 at 11:51, Koen Kooi k...@dominion.thruhere.net
  wrote:
  I'm not going pull those in, since the whole point was to not make
 them
  machine specific. RP has pushed a workaround for it so parsing
  continues. I'll push a proper fix for systemd later.
 
  What's the difference if the package will be built from same source?
 
  In case you change anything you'll need to rebuild all packages anyway
  so I see no gain in having it per package.
 
  It makes it easier to deploy updates for the main packages (e.g.
  sysvinit, systemd) to all the targets without having to build it for all
  targets. It's a weird optimization, but makes life a lot easier for
  people needing to support a ton of machines :)
 
 
  Hm. saving some CPU cycles and wall clock time makes life a lot easier.
  Guess you haven't too much of a life then :-)
  No kidding, why not keep things simple. and elegant.
  (and actually people needing to maintain a lot of machines and keeping
 them
  up to date is somewhat an oddity anyway; My experience is that most
 embedded
  developers need to support only a few machines and typically freeze their
  sources and stabilize their product).

 Really?  One of those big requests we see a lot is for things like how
 can I support the N different revs of the board for this product.
 Looking over at the kernel side of things that was one of the drivers
 for device tree stuff.  So yes, outside of community based distributions
 like Angstrom and SHR and SlugOS and ... there are commercial uses for
 this change as well.  And it doesn't change the world of one machine
 embedded products at all.


The vendors of embedded products I am aware of (and then I'm talking about
TV's, NAS-es, Audio systems etc etc but also boards running embedded linux
code) focus on stability. Actually none of my managers ever cared if we were
running the latest version of Linux. They do care about stability and
maturity. Some of the products I need to care about still use a 2.6.24
kernel. No way this is going to move. Customers are happy with the product,
and do not care about kernel etc, so for these products only some bug fixing
is done. And yes, we have boards with multiple revs, but we try to keep the
changes small and localized. This might mean some kernel fixes, but
generally no upgrades to newer versions or so.

Of course this is my experience and other places might do things
differently. And of course this is going off-topic.

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

Re: [oe] Distros supporting older kernels?

2011-06-12 Thread Frans Meulenbroeks

2011/6/12 Steffen Sledz sl...@dresearch-fe.de

On 10.06.2011 00:43, Khem Raj wrote:

On 06/09/2011 06:02 AM, Steffen Sledz wrote:

Hi Distro Maintainers,

as you could read in earlier messages of mine, we're forced to use an
older kernel version (2.6.24) for our hardware. This brings a lot of
problems as you can imagine (e.g. we're also bound to udev-141).

Until now we've used angstrom-2008.1 with some own patches according to
the linux-libc-headers and udev versions for our hardware which were
reasonably not accepted by the Angstrom maintainers (see discussions [1]
or [2]).

In there current situation (angstrom-2008.1 is deprecated, the new layer
concept will come up) we're looking for a new, better, less hacky
solution.

My first question therefor is if there are any distros explicitely
supporting older kernels (pre 2.6.27) yet? Or are willing to work on it?

I guess a machine layer on top of oe-core could be something you can work
out and add/override needed recipes in this layer.

I think it's not that easy.

For kernels prior to 2.6.27 you can't use a lot of core components (e.g.
udev with versions higher than 141 or eggdbus) which *a lot of other
components* depend on.

The underlying problem are some kernel API functions like inotify_init1 or
epoll_create1. Some distros (e.g. Angstrom) use linux-libc-headers 2.6.31
which is higher then 2.6.27 (what in my opinion conflicts with [1]). So
there's no chance to detect the mentioned kernel functions correctly at
compile time. :(

As a consequence you have to check this in *all* programs at runtime. This
is a good wish but hard to realize. E.g. the udev maintainers itself
rejected a related patch[2] and say that they are not willing to support
older kernel versions.

So in my opinion there are two possible ways:

1. Use only the old supported versions of the components (udev-141 and
glib-dbus instead of eggdbus) with all the consequences for other programs.

2. Determine *all* critical kernel functions, look for *all* the places
where these are used, and patch them.

Both are a lot more than some override recipes. So i think this needs an
own distro with all the maintenance and testing.

Regards,
Steffen

[1] but a program built against newer kernel headers may not work on an
older kernel
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/make/headers_install.txt;hb=HEAD

[2] http://thread.gmane.org/gmane.linux.hotplug.devel/16590

Steffen, I feel it really depends on what you are aiming at. For our
products we typically freeze on a certain version; if there are bugs that
hurt us we either fix them (backporting a patch) or move to a newer version
of that specific recipe (and stick it in a local overlay).

E.g. some of our maintenance is done on a monotone revision that was frozen
a few years ago.
I feel if you have to use an older kernel and have a dedicated image (e.g.
because you are doing a real embedded control system) you might be better
off doing the same.
The newest packages are not necessarily better for you, and typically newer
versions tend not to become smaller (but ofc exceptions exist).

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

Re: [oe] OpenEmbedded Core - Ready for extended users

2011-05-16 Thread Frans Meulenbroeks

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

 Hi,

 The TSC has been tasked with working out how OE and Yocto could work
 together and people have no doubt seen the discussions about OE-Core.

 We're now pleased to formally announce that we feel OE-Core is ready for
 exposure to more users and we'd like to encourage people to have a look
 at it and experiment and develop with it.

 Just to recap on the background for this, splitting up OE into
 components has been a topic of discussion for a long time, certainly at
 every OEDEM. Until now this hasn't happened partly due to resource
 issues but also lack of tooling and the lack of a well thought out plan.
 We now feel these issues have been addressed and that we have a good
 plan in place. The promotion and use of layers is the only real way OE
 can scale as a project yet stay maintainable and testable.

 Things that aren't part of oe-core fall to the meta-oe layer which is
 where we intend the current wider support contained in oe-devel to be
 maintained. The people working on meta-oe so far would love to see more
 contributions. Both repositories are currently working on a pull model
 and people using them so far have felt a benefit to this for code
 quality.

 Discussion and development on oe-core is happening on the
 openembedded-core mailing list since otherwise it would be hard to
 filter out which patches and discussion were for which repository. We
 look forward to seeing more people getting involved there!

 (http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core)

 Cheers,

 Richard
 (Communicating on behalf of the TSC)


 Richard, thanks for the announcement.

I think the community could benefit if you add info (a pointer) in this
thread
- how to set up a build environment
- policies on what goes into oe-core and meta-oe and what not (and how to
deal with things that do not go into it)
- a migration scenario from the current repo to the new structure (what are
we doing with the existing recipes)
- how to add new distro's and bsp's

I know some (if not all) info has been sent around over time, but I feel it
would help if this announcement would carry the info to get people started
(and/or point to a web page that has the above info).

Best regards, Frans
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] OpenEmbedded eV membership drive

2011-05-03 Thread Frans Meulenbroeks

2011/5/3 Philip Balister phi...@balister.org

[...]


 People ask me why they should join the eV. Besides being a good way to show
 your support for the OpenEmbedded project, the Technical Steering Committee
 is elected by the eV members.

 Sorry but the current TSC is NOT elected by the eV members.

Actually the board even fails to meet its own rules stipulated when they
installed this interim TSC.

From Philip's email from feb 10:

This interim TSC will operate for 2 months when we shall start elections
at two month intervals for the 5 positions on the TSC. The new elected
TSC members will operate under the charter detailed on the wiki here
http://wiki.openembedded.org/index.php/TSCCharter.

We're now almost 3 months later and no election has been held!

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

Re: [oe] OpenEmbedded eV membership drive

2011-05-03 Thread Frans Meulenbroeks

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

 On Tue, 2011-05-03 at 22:05 +0200, Frans Meulenbroeks wrote:
  2011/5/3 Philip Balister phi...@balister.org
 
  [...]
 
  People ask me why they should join the eV. Besides being a
  good way to show your support for the OpenEmbedded project,
  the Technical Steering Committee is elected by the eV members.
 
  Sorry but the current TSC is NOT elected by the eV members.

 The current situation was making the best of a bad set of circumstances,
 the plan is to hold elections and nothing has changed in that regard.

  Actually the board even fails to meet its own rules stipulated when
  they installed this interim TSC.
 
  From Philip's email from feb 10:
  This interim TSC will operate for 2 months when we shall start elections
  at two month intervals for the 5 positions on the TSC. The new elected
  TSC members will operate under the charter detailed on the wiki here
 
  http://wiki.openembedded.org/index.php/TSCCharter.
  We're now almost 3 months later and no election has been held!

 This was discussed at the last TSC meeting and we reviewed the TSC
 meeting minutes where it was recorded that:

 
 Election wise, we'll elect the seats in the order from the board
 announcement email until we have 5 elected members. We will rely on the
 board to call the first election in May.
 

 which the TSC has reminded the board about last week.

 Cheers,

 Richard

 I don't think it is up to the TSC to decide on the re-election timeframe.
As it stands the TSC got a 2 month mandate. See the quote above (from
Philip's email from feb 10).
That is all I wanted to indicate.

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

Re: [oe] [RFC, PATCH] Add minver/maxver to patch.bbclass, update bluez

2011-04-25 Thread Frans Meulenbroeks

2011/4/25 Tom Rini tom_r...@mentor.com

 Hey all,

 In digging at some other bluez problems, I found that at least
 4.91 no longer needs the sbc-thumb patch.  But without moving it to the
 N versions of bluez4 we have or starting a new inc file for later bluez4
 versions, there wasn't a clean way to exclude the patch.  Until now.
 Borrowing the minrev/maxrev logic I added minver/maxver patch params
 and tested them lightly (the patch is applied on 4.89 and not on
 4.91).  I'm cc'ing Koen here because patch #3 adds 4.91 and make it
 default for Angstrom, but all I've done myself is build testing.
 It should be safe, based on upstream changelog tho.

 First question should probably be: do we need 9 versions of bluez4? This is
not too much in line with the version policy the TSC once stipulated and
seems also different from the road oe-core and meta-oe are taking.

Also personally I'm not too keen on minrev/maxrev. It only makes things
again a little bit more complicated.
My preference would be to remove the patch from the .inc file and move to
the individual bb files

My 2 cents.

Frans

PS: two more cents: it seems somewhat odd that some distro's have a DP = 1
for more than one version of a recipe. While technically not wrong this
looks a little bit odd.
Also we seem to have two mechanisms to select a version for a distro. One is
the DP_distro mechanism the other one is the PREFERRED_VERSION_recipe in the
conf file
It seems to me one should be sufficient
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [RFC, PATCH] Add minver/maxver to patch.bbclass, update bluez

2011-04-25 Thread Frans Meulenbroeks

2011/4/25 Tom Rini tom_r...@mentor.com

 On 04/25/2011 01:14 PM, Frans Meulenbroeks wrote:
  2011/4/25 Tom Rini tom_r...@mentor.com
 
  Hey all,
 
  In digging at some other bluez problems, I found that at least
  4.91 no longer needs the sbc-thumb patch.  But without moving it to the
  N versions of bluez4 we have or starting a new inc file for later bluez4
  versions, there wasn't a clean way to exclude the patch.  Until now.
  Borrowing the minrev/maxrev logic I added minver/maxver patch params
  and tested them lightly (the patch is applied on 4.89 and not on
  4.91).  I'm cc'ing Koen here because patch #3 adds 4.91 and make it
  default for Angstrom, but all I've done myself is build testing.
  It should be safe, based on upstream changelog tho.
 
  First question should probably be: do we need 9 versions of bluez4? This
 is
  not too much in line with the version policy the TSC once stipulated and
  seems also different from the road oe-core and meta-oe are taking.

 For bluez4 we could probably drop out 4.31, 4.41 (4.43 seems to
 introduce some startup changes that might require folks to opt-in) and
 then all of the post ones until 4.91, since shr and angstrom would both
 depend on that.  I'd be happy to do that as a follow-up.

  Also personally I'm not too keen on minrev/maxrev. It only makes things
  again a little bit more complicated.
  My preference would be to remove the patch from the .inc file and move to
  the individual bb files

 Well, maybe the better answer is a re-worked series to drop out a number
 of older versions, and then it won't be bad to have the patch in a the
 bb files..  Need to think about this.


I appreciate it if you would.
To me the analysis of what is needed seems sound.


  My 2 cents.
 
  Frans
 
  PS: two more cents: it seems somewhat odd that some distro's have a DP =
 1
  for more than one version of a recipe. While technically not wrong this
  looks a little bit odd.
  Also we seem to have two mechanisms to select a version for a distro. One
 is
  the DP_distro mechanism the other one is the PREFERRED_VERSION_recipe in
 the
  conf file
  It seems to me one should be sufficient

 Well, this is in part something the oe-core/meta-oe/etc policy will help
 with since it does have a planned phasing out / removal of the old
 version, so we would have less in the way of add the latest .z release
 and .z-1 through .z-5 just stick around).


Actually the last remark was mostly triggered by the observation that
distro's have two ways to pin a recipe (and actually use both of them).
Having only one mechanism might reduce the chance of causing confusion
and/or mistakes

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

Re: [oe] [PATCH] schroedinger.inc: remove version dependent checksums

2011-04-17 Thread Frans Meulenbroeks

2011/4/17 Paul Menzel paulepan...@users.sourceforge.net

 Date: Sun, 17 Apr 2011 18:14:13 +0200

 This is a fix up for commit cb84b138 [1].

 [1]
 http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=cb84b138269ed9f3426f4e79f4bb9911e5066387

 Signed-off-by: Paul Menzel paulepan...@users.sourceforge.net
 CC: Frans Meulenbroeks fransmeulenbro...@gmail.com


Thanks!
Having the checksums twice in there is indeed not too useful.
Acked-by:  Frans Meulenbroeks fransmeulenbro...@gmail.com

 ---
  recipes/schroedinger/schroedinger.inc |2 --
  1 files changed, 0 insertions(+), 2 deletions(-)

 diff --git a/recipes/schroedinger/schroedinger.inc
 b/recipes/schroedinger/schroedinger.inc
 index 4dc8a6e..386fc73 100644
 --- a/recipes/schroedinger/schroedinger.inc
 +++ b/recipes/schroedinger/schroedinger.inc
 @@ -5,8 +5,6 @@ DEPENDS = liboil orc-native orc
  INC_PR = r1

  SRC_URI = 
 http://www.diracvideo.org/download/schroedinger/${P}.tar.gz;name=schroedingertargz
 
 -SRC_URI[schroedingertargz.md5sum] = d67ec48b7c506db8c8b49156bf409e60
 -SRC_URI[schroedingertargz.sha256sum] =
 345abcaa72ff0f2e9c1075e22f7141475ee4e6eea23a7f568b69ffc13cc1c723
  SRC_URI += file://configure.ac.patch

  EXTRA_OECONF += STAGING_DIR=${STAGING_DIR_NATIVE}
 --
 1.7.4.4

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

Re: [oe] [PATCH] streamripper: fix depends and license

2011-04-15 Thread Frans Meulenbroeks

2011/4/15 Andreas Oberritter o...@opendreambox.org:
 - Prefer the shared libmad over the one included in streamripper.
 - glib-2.0 is required to build streamripper.
 - libfaad2 will get picked up if built before streamripper. Make
  builds consistent.
 - No need to set RDEPENDS_${PN} (already set by shlibdeps).

 Signed-off-by: Andreas Oberritter o...@opendreambox.org
Acked-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
 ---
  recipes/streamripper/streamripper_1.64.6.bb |    6 +++---
  1 files changed, 3 insertions(+), 3 deletions(-)

 diff --git a/recipes/streamripper/streamripper_1.64.6.bb 
 b/recipes/streamripper/streamripper_1.64.6.bb
 index 342d92e..39fae01 100644
 --- a/recipes/streamripper/streamripper_1.64.6.bb
 +++ b/recipes/streamripper/streamripper_1.64.6.bb
 @@ -1,8 +1,8 @@
  DESCRIPTION = StreamRipper lets you record streaming mp3 to your hard 
 drive.
  SECTION = console/multimedia
 -LICENSE = GPL
 -DEPENDS = libogg libvorbis
 -RDEPENDS_${PN} = libogg libvorbis
 +LICENSE = GPLv2+
 +DEPENDS = faad2 glib-2.0 libmad libogg libvorbis
 +PR = r1

  SRC_URI = 
 ${SOURCEFORGE_MIRROR}/streamripper/streamripper-${PV}.tar.gz;name=src
  SRC_URI[src.md5sum] = a37a1a8b8f9228522196a122a1c2dd32
 --
 1.7.2.5


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


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

Re: [oe] [PATCHv2] kernel/module-base: Append PR to MACHINE_KERNEL_PR

2011-04-05 Thread Frans Meulenbroeks

2011/4/5 Koen Kooi k...@dominion.thruhere.net:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 05-04-11 11:32, Phil Blundell wrote:
 On Tue, 2011-04-05 at 11:23 +0200, Koen Kooi wrote:
 On 05-04-11 11:08, Andreas Oberritter wrote:
 Thereby making MACHINE_KERNEL_PR mandatory for all machines?

 I don't see why not.

 The majority of machines aren't using it at present so this would be an
 unexpected (and presumably unwelcome) change for them.  That seems like
 a bad idea unless there is a compelling reason why it needs to be done.

 First: You don't get to complain about broken kernel module PRs when you
 are against rebuilding them when the kernel changes.

 Second: the majority of machines doesn't even build, so those kind of
 arguments are bogus

In the tree I have handy there are 313 machines.
I'd be rather hesitant to make statements that the majority does not
build without having that tested (and if you have: how many do not
build).

These are the files that have M_K_PR in them:
ea3250.conf:MACHINE_KERNEL_PR   = r0
nokia900.conf:MACHINE_KERNEL_PR = r58
omap3-pandora.conf:MACHINE_KERNEL_PR = r2
smartq5.conf:MACHINE_KERNEL_PR = r1
smartqv7.conf:MACHINE_KERNEL_PR = r0
include/davinci.inc:MACHINE_KERNEL_PR = r50
include/kirkwood.inc:MACHINE_KERNEL_PR = r19
include/omap3.inc:MACHINE_KERNEL_PR = r101
include/omap4.inc:MACHINE_KERNEL_PR = r101
include/palmpre.inc:MACHINE_KERNEL_PR = r93
include/ti814x.inc:MACHINE_KERNEL_PR = r1
include/ti816x.inc:MACHINE_KERNEL_PR = r1

Actually it seems quite some machines used to test the 2011.3 release
do not seem to use M_K_PR
(http://wiki.openembedded.org/index.php/Release-2011.03).

Frans.

PS: the machines I feel responsible for, and use regularly all build.
Not all of them do use M_K_PR.


 So apart from handwaving (presumably unwelcome) do you have any actual
 arguments against moving all machines to MACHINE_KERNEL_PR?

 -BEGIN PGP SI-
 Version: GnuPG v1.4.5 (Darwin)

 iD8DBQFNmvFnMkyGM64RGpERAqqkAJ4vgIlyQ3cgVAnZS2rcjdGJHjn3uQCfTOjt
 UtUZ9dRa9XfWvnganZPrAbg=
 =KtE5
 -END PGP SIGNATURE-


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


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

Re: [oe] [PATCH 3/7] openssl-0.9.8m, binutils-2.20.1: Use linux-uclibceabi instead of uclibcgnueabi

2011-04-01 Thread Frans Meulenbroeks

2011/4/1 Koen Kooi k...@dominion.thruhere.net:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 01-04-11 09:27, Frans Meulenbroeks wrote:
 2011/4/1 Khem Raj raj.k...@gmail.com:
 Signed-off-by: Khem Raj raj.k...@gmail.com
 ---
  .../openssl/openssl-0.9.8m/configure-targets.patch |    4 ++--
  .../binutils-2.20.1/110-arm-eabi-conf.patch        |    4 ++--
  2 files changed, 4 insertions(+), 4 deletions(-)

 maybe partly offtopic but:
 openssl 0.9  is at 0.9.8r; 8m has known security vulnerabilities
 probably better upgrade to 8r.

 So make a patch and do a pull request.

No thanks.
Last time I touched openssl I got so much flames from you because I
made a mistake that I decided not to touch this recipe again.
I'll happily leave it to someone else to burn his/her fingers on this.

Frans

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

Re: [oe] [2011.03-maintenance] Pull request for new TI machines, angstrom and qt4 fixes

2011-03-31 Thread Frans Meulenbroeks

Adding new machines on a maintenance branch seems somewhat odd as new
somewhat conflicts with maintenance.
is this what we want? And if so, what about adding new recipes?

Frans

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

Re: [oe] [2011.03-maintenance] Pull request for new TI machines, angstrom and qt4 fixes

2011-03-31 Thread Frans Meulenbroeks

2011/3/31 Koen Kooi k...@dominion.thruhere.net:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 31-03-11 12:51, Frans Meulenbroeks wrote:
 Adding new machines on a maintenance branch seems somewhat odd as new
 somewhat conflicts with maintenance.
 is this what we want? And if so, what about adding new recipes?

 Since you aren't using, developing or supporting 2011.03-maintenance, I
 strongly object to your usage of 'we'.

I don't think you know what I am using, let alone what I am developing
at the moment, or my plans to support things.

Also the we was a general tone of voice meaning we as OE.

But somehow I guess this is the hostile and unfriendly response to be
expected from you.
Instead of stimulating people to think with you, you bash them away.
And then tomorrow complain that people do not participate.
Now how would that come?

 Furthermore, this isn't the first time that new machines would get added
 to 2011.03-maintenance.

which might not be a good plan either.

 People really should read
 http://wiki.openembedded.org/index.php/2011.03-maintenance

Which does not speficy what should and should not be added
(apart from:
Unless specific to code that no longer resides in a non-maintenance
branch (ie master here or oe-core / meta-oe / etc) code must be a
backport and should say where the code already resides (for ease of
review, interoperability checking and so forth). 
)

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

Re: [oe] [2011.03-maintenance] Pull request for new TI machines, angstrom and qt4 fixes

2011-03-31 Thread Frans Meulenbroeks

2011/3/31 Tom Rini tom_r...@mentor.com:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 03/31/2011 03:51 AM, Frans Meulenbroeks wrote:

 Adding new machines on a maintenance branch seems somewhat odd as new
 somewhat conflicts with maintenance.
 is this what we want? And if so, what about adding new recipes?

 To be clear, I do not have a problem with backporting support for new
 hardware nor support for new recipes to 2011.03-maintenance so long as
 (as stated on the wiki page) they are first and foremost backports and
 secondly something the the users of the branch desire.

Tom, Philip, thanks for your explanation.
As it stands we have no backported patches yet, but they might show up.
Koen's rude reply mostly vaporized my interest to contribute (and
instead keep my patches locally), but your reply at least encourages
it to reconsider.

Best regards, Frans.

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

Re: [oe] [PATCH 4/4] vlc (1.1.4.1): depends on lua5.1

2011-03-23 Thread Frans Meulenbroeks

2011/3/23 Sylvain Paré sylvain.p...@gmail.com:
 Hello
 I was going to fill a bugrepport on OE's bugzilla but as you are already
 speaking of vlc building issue..
 It does not build for me neither : http://pastebin.com/raw.php?i=wK4Sxbv9
 Thanks by advance.

 Regards,

 Sylvain (aka GarthPS)


We did discuss this on irc, and the issue seems to be that
libliveMedia.a is probably a host lib.

Another issue that was noted was that OE_CONF says --enable-live555
(or something like that) but live555 is not in the DEPENDS.
A quick glance over the recipe showed that there seem to be more
things missing in DEPENDS (freetype, apache, png, ...)

Frans


 2011/3/23 Paul Menzel paulepan...@users.sourceforge.net

 Am Mittwoch, den 23.03.2011, 08:51 -0300 schrieb Otavio Salvador:
  On Tue, Mar 22, 2011 at 19:55, Paul Menzel
  paulepan...@users.sourceforge.net wrote:
   What kind of error do you get? The recipe build fine for me using
   `angstrom-2010.x` for `MACHINE = beagleboard`.
 
  It fails to find lua.h so probably you had it built due other dependency.

 No, I made a clean build, i. e. `rm -rf angstrom-dev`. Please post your
 build configuration.


 Thanks,

 Paul

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


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


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

Re: [oe] Eliminating dependency race-conditions

2011-03-23 Thread Frans Meulenbroeks

Dear all,

pb and I had a discussion about this on irc earlier today.

Actually we feel there are three different issues in the proposal:
1. only stage those recipes that are in DEPENDS.
2. stage based on packages instead of recipes (so e.g. you can stage
only a lib package)
3. use tar (or a different tool) to stage things; or in other words,
decouple the storage format and the package format.

I think each of these has its merits. I also understand that
incremental introduction is desired above a big bang approach.

Let us look at the issues in detail:

1. only stage those recipes that are in DEPENDS.

This seems pretty useful as it gives consistent builds not depending
on whatever you have build before (and so making things deterministic)
This is especially useful when doing incremental builds. It can also
solve races.
Introducing it would mean changes in staging; incremental introduction
is possible if e.g. we add a flag PACKAGE_BASED_STAGING or so to the
recipes we want this to have (or add a special class or so).
Once all recipes are moved, the flag can be removed again.

Question is how efficient this can be. It mostly depends on how we
want to achieve the staging.
I'm definitely no expert, but we could e.g.
- create the staging area from earlier package images each time we
build it. Does not seem overly efficient
- stage each package in its own dir and create symlinks in the
required staging area.
- stage each pacakge in its own dir and add to -I and -L to only stage
the packages that are needed.

The staging area for a package to be build should probably be within
the work dir of the recipe otherwise we'll loose the capability to
build things in parallel

2. stage based on packages instead of recipes (so e.g. you can stage
only a lib package)

This gives more fine grained control. Not sure how much it brings and
what it will cost.
It might be possible to do it incrementally by e.g. having a keyword
PACKAGE_DEPENDS.
Question is if it is worth the effort

3. use tar (or a different tool) to stage things; or in other words,
decouple the storage format and the package format.

To me that is a completely different question only loosely related to
the above.
If staging is from packaged images, it would help though to have a
format that is fast to unpack.

Another, perhaps more interesting reason, would be to use a package
manager agnostic format and use that to build packages from (for the
package manager you want to have it).
I don't oversee the impact of this one though.


Your opinion on this proposal, improvement suggestions, discussion on
the best way forward etc is appreciated.

Frans

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

Re: [oe] OE Bugzilla Future

2011-03-20 Thread Frans Meulenbroeks

2011/3/20 Khem Raj raj.k...@gmail.com:
 On 3/19/2011 1:28 AM, Frans Meulenbroeks wrote:
[...]

 Well, I do feel it is one of them, and that is the maintainer of the
 package (who might be the original author).

 To me being the maintainer of a recipe says that one cares about a
 recipe and tries to maintain it (as the word says :-) )
 Maintainership comes with responsibilities. If people do not want to
 take these responsibilities then they should not list themselves as
 maintainer.
 I have seen too many incidents where someone does not care about a
 package or bugs submitted to it, but if someone else steps in and
 fixes things, then suddenly the original author or maintainer feels
 they are stepped onto their toes, and react hostile.

 Its always good to get reviews from people who have prior experience even if
 it comes in ways you don't like since in the end it makes the software
 better. A little attitude adjustment is however needed sometimes :)

May I nominate that last sentence for understatement of the year?


 Btw this is the main reason I stopped trying to fix bugs that do not
 affect me (apart from the recipes I maintain).

 Thats pretty selfish view of world I must say in a community of volunteers
 :)

Sorry but the smiley escapes me.

If you feel it is selfish, that is your opinion.

I prefer to call it self-protection.
I have no interest any more to get rude comments. It brought too much
frustration and irritation.
And as my work apparently not appreciated, I decided to cut back on my
effort, also because I dio not have a home project any more that uses
OE.

Bash a volunteer often enough and at some point he'll not be
volunteering any more.
What OE really needs is a more positive atmosphere towards each other.

Frans.

PS: another reason to wind down my effort is the yocto migration I see
going on.
I have no interest to become an unpaid resource for Intel and the
other LF member companies.

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

Re: [oe] OE Bugzilla Future

2011-03-19 Thread Frans Meulenbroeks

2011/3/19 Richard Purdie richard.pur...@linuxfoundation.org:
 On Fri, 2011-03-18 at 10:15 +, Phil Blundell wrote:
 On Fri, 2011-03-18 at 08:57 +0100, Frans Meulenbroeks wrote:
  2011/3/17 Richard Purdie richard.pur...@linuxfoundation.org:
   On Thu, 2011-03-17 at 19:10 +0100, Michael 'Mickey' Lauer wrote:
   I'm in favor of keeping it, cleaning it up, and improve
   the integration with patchwork / git. Throwing it away
   would be a very bad sign to all those countless people
   who've gone through the pains of actually working with
   the bugtracker.
  
   The simple question is who is actually going to sort out the mess its
   in?
  
   Who is going to look after it on a continuing basis?
  
   If there isn't ownership, nothing is going to change.
 
  Actually I feel the real problem is that:
  - people did not want to get bugs assigned to them (at least that was
  what someone told me in the past)
  - we're lacking a good notion of package or recipe ownership, so even
  if we had someone acting as a bug manager, (s)he would have a hard
  time to find out who to assign an issue to.

 Yes, agreed.  A few people have tried in the past to take responsibility
 for bugzilla itself (in infrastructure terms) and I would be happy
 enough to do that for the future.  But it clearly is not reasonable to
 expect the Bugzilla maintainer(s) to be personally responsible for
 fixing every bug that gets reported.

 This is the key question. Who is responsible for fixing bugs?

 The recipe's original author?
 The maintainer?
 The reporter?
 The bugzilla maintainer?
 The TSC?

 The answer in general is whoever has time and an interest in it and none
 of the above.

Well, I do feel it is one of them, and that is the maintainer of the
package (who might be the original author).

To me being the maintainer of a recipe says that one cares about a
recipe and tries to maintain it (as the word says :-) )
Maintainership comes with responsibilities. If people do not want to
take these responsibilities then they should not list themselves as
maintainer.
I have seen too many incidents where someone does not care about a
package or bugs submitted to it, but if someone else steps in and
fixes things, then suddenly the original author or maintainer feels
they are stepped onto their toes, and react hostile.

Btw this is the main reason I stopped trying to fix bugs that do not
affect me (apart from the recipes I maintain).

 As you say, the real issue here seems to be that someone (presumably the
 TSC) needs to determine the workflow that OE is going to use and then
 convince the developers to stick to it.

 Here lies the problem. All OE's developers are effectively volunteers.
 We have no means to convince developers to stick to anything. Volunteer
 developers have a tendency to rebel as soon as it even remotely looks
 like someone might force them to do something :).

Sorry but  I have to disagree with this.
Even if you volunteer for something, it may (and most often will) come
with responsibilities.

In my view if you volunteer to maintain a recipe, that carries some
obligations and responsibilities.
If you do not want them, fine, don't step up as maintainer.
If you do, act according to them.

I feel a good way would be to define the role of a maintaner.
And eventually recipes fall apart into two groups. The ones with a
maintainer and the ones without.

That does not outrule others form contributing. If you want to
contribute say a new recipe, you still can. It'll be an unmaintained
recipe in that case.

And if people want to apply a patch, well if it is an unmaintained
recipe, I'd say that is fine (if someone really cared about the recipe
so much that he does not want this, he should take up the maintainer
role for that recipe).
And if it is a patch for a maintaned recipe, it passes the recipe maintainer.

Note that I am not saying that it is the responsibility of the
maintainer to dig and resolve every issue reported.
Very specific issues can still be left as is (to give a weird example:
someone reports that recipe X does not build under cygwin :-) ).


 I put the smile in as I don't mean this in a bad way but I do think we
 need to understand that few people have the time to dive into other
 people's problems. This is the underlying issue and I don't think
 anything has changed for OE. I don't think there is anything magic the
 TSC can do either.

 Yocto has different dynamics and I think those could be useful for some
 of this and can help improve things for the better but its never a free
 for all. Yocto has, can and will look at certain bugs but the scope
 needs to be constrained, certainly to OE-Core.

Best regards, Frans.

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

Re: [oe] OE Bugzilla Future

2011/3/17 Richard Purdie richard.pur...@linuxfoundation.org:
 On Thu, 2011-03-17 at 19:10 +0100, Michael 'Mickey' Lauer wrote:
 I'm in favor of keeping it, cleaning it up, and improve
 the integration with patchwork / git. Throwing it away
 would be a very bad sign to all those countless people
 who've gone through the pains of actually working with
 the bugtracker.

 The simple question is who is actually going to sort out the mess its
 in?

 Who is going to look after it on a continuing basis?

 If there isn't ownership, nothing is going to change.

Actually I feel the real problem is that:
- people did not want to get bugs assigned to them (at least that was
what someone told me in the past)
- we're lacking a good notion of package or recipe ownership, so even
if we had someone acting as a bug manager, (s)he would have a hard
time to find out who to assign an issue to.

and of course it takes discipline to look at regular intervals in the
bug tracker to see if there are issues that affect the recipes you
feel responsible for.
A discipline that few people have and that is also easy to forget if
there is only very rarely something for you.

So it is more of a process issue.
(btw this may be something that could be picked up by the TSC).

Frans.

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

Re: [oe] Python-native dependency in libxml2

2011/3/18 Ahsan, Noor noor_ah...@mentor.com:
 Hello Martin/Frans and Khem,

 Any recommendation after following analysis that how should I proceed.
 Should I send the patches to community?

 Regards,
 Noor

I think Martin is in a better position to judge this than I am.
Did you also verify that the generated output (the packages and the
contents of the packages) is identical in the python and no-python
case?

Best regards, Frans

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

Re: [oe] blacklist.bbclass

2011/3/18 Dr. Michael Lauer mic...@vanille-media.de:
 Salut,

 the blacklisting of packages as found in angstrom.bbclass
 is pretty helpful and would be beneficial to all kinds
 of distribution configurations in OE. Would there be
 a strong objection of renaming this to blacklist.bbclass?

 Copying, of course, is also a possibility, but
 in my opinion it would only be the second best choice.

 Cheers,

 :M:

If blacklisting a certain package for all distro's is there then still
a need to keep those blacklisted packages 

Frans

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

Re: [oe] blacklist.bbclass