[oe] Fwd: Error when attempting to subscribe to openembedded-devel@lists.openembedded.org
Anfang der weitergeleiteten Nachricht: Von: Thomas Fitzsimmons fitz...@cisco.com Betreff: Error when attempting to subscribe to openembedded-devel@lists.openembedded.org Datum: 7. Februar 2013 21:47:35 MEZ An: mick...@linuxtogo.org Hi, I get a mailman error [1] when I attempt to subscribe to openembedded-devel@lists.openembedded.org. I would prefer to post to the gmane newsgroup gmane.comp.handhelds.openembedded though; I tried that too but my message hasn't showed up, even after the Gmane confirmation step. Do I need to be subscribed in order to use the Gmane newsgroup-to-mailing-list bridge? Thanks, Thomas 1. Bug in Mailman version 2.1.11 We're sorry, we hit a bug! Please inform the webmaster for this site of this problem. Printing of traceback and other system information has been explicitly inhibited, but the webmaster can find this information in the Mailman error logs. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] WebOS OpenEmbedded Layers
Excellent news, finally something to build upon and improve while we go. Thanks for the update, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] oe classic: eglibc
Am 07.09.2012 um 13:27 schrieb Frans Meulenbroeks fransmeulenbro...@gmail.com:
Not sure if anyone is still interested in oe classic, but while rebuilding
some sw using oe classic I noticed the eglibc recipes did not build any
more as upstream changed things in the repo.
I've locally fixed this by changing SRC_URI from
SRC_URI = svn://svn.eglibc.org/branches;module=${EGLIBC_BRANCH};proto=svn \
into
SRC_URI = svn://
www.eglibc.org/svn/branches;module=${EGLIBC_BRANCH};proto=http \
builds and tests fine. If anyone is tempted, feel free to author a patch.
Thanks!
:M:
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] Fwd: Photos App WebOS Touchpad
Forwarding to the actual list address... Anfang der weitergeleiteten E-Mail: Von: Florin Oprea flo...@adam.com.au Betreff: Photos App WebOS Touchpad Datum: 28. Januar 2012 03:46:59 MEZ An: openembedded-devel-ow...@lists.openembedded.org Hi openembedded team. I have a problem with this app. It has stopped syncing with facebook just after I installed ota 3.0.4 webos. A while I blamed it on the update then I found on the webos nation forum a thread about my issue and I left some comments there for the developer team, hoping that the following ota update will fix my issue. The ota has arrived a few days ago and I installed it, but to my disappointment it has not fixed my issue. Is there a patch or ... Some sort of an automated script that your team could make available to all of us having this issue? Thank you in advance. Florin Oprea __ Information from ESET Smart Security, version of virus signature database 6765 (20120103) __ The message was checked by ESET Smart Security. http://www.eset.com ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] request for branch in OpenEmbedded Git repository
Paul, we have always allowed custom branches for developers with write access. Feel free to create as many as you need, please prefix them with your nickname. Cheers, Mickey. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Unwanted dependency on X from ppp
Mike, I think this is quite useful and should be codified as as a .inc. Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] Fwd: Update proposals
Forwarding this to the proper list address, please note that openembedded-devel-owner is for administrative purposes. Von: fabien comte comte_fab...@yahoo.fr Betreff: Update proposals Datum: 6. Juli 2011 14:04:00 MESZ An: openembedded-devel-ow...@lists.openembedded.org Hello, This archive contain some updates for recipes. Could you integrate it ? All are ok but I cannot rebuild jamvm 1.5.4 since icedted build fails. Could you fix icedted if you want that I test jamvm again (i did it few month before and it worked) ? I hope that it will help some users. Fabien Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 3/3] angstrom: Prefer Qt 4.7.3
I reckon you tested Qt 4.7.3 with PyQt before deleting 4.7.2... Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Master broken?
Am 04.04.2011 um 16:43 schrieb Gary Thomas: On 04/04/2011 08:37 AM, Sachin Kamboj wrote: The problem is angstrom-2008.1 has been retired and is no longer available in the master branch. Use angstrom-2010.x instead as your distro. Alternatively, use the maintenance branch: http://www.angstrom-distribution.org/angstrom-20081-moves-maintenance-branch Thanks, that got me going. Why didn't I get an error when I selected DISTRO=angstrom-2008.1? There is no longer a .../conf/distro/angstrom-2008.1.conf file on the master branch. Take a look at bitbake.conf The DISTRO configuration is included via the 'include' directive, which is a permissive include – in contrast to 'require', which is a mandatory include. I don't recall our reasons for keeping it like that, but I remember that 'require' wasn't present at the time we wrote bitbake.conf. Perhaps we should reconsider that 'include'. Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] blacklist.bbclass
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: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
[oe] URGENT: Helpers Wanted for CeBIT
Dear folks, as you might know next week is CeBIT, one of germany's largest computer fairs, where OpenEmbedded has a booth. Until now we only have 3 people to serve the booth and one of them (yours truly) is suffering from an bad flu which makes his appearance questionable. If anyone of you has time to join us, please contact Robert thebohem...@gmx.net, who is coordinating our booth. Thanks, Mickey. ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] minimal.conf: inherit devshell task
Acked-by: Michael 'Mickey' Lauer mla...@vanille-media.de Am 24.01.2011 um 15:39 schrieb Víctor Manuel Jáquez Leal: Everybody loves devshell Signed-off-by: Víctor Manuel Jáquez Leal vjaq...@igalia.com --- conf/distro/minimal.conf |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/conf/distro/minimal.conf b/conf/distro/minimal.conf index f495d13..11525b9 100644 --- a/conf/distro/minimal.conf +++ b/conf/distro/minimal.conf @@ -104,6 +104,9 @@ QA_LOG = 1 #run QA tests on recipes INHERIT += recipe_sanity +#make devshell available as task +INHERIT += devshell + # # PREFERRED VERSIONS # -- 1.7.0.2 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] problems compiling glibc_2.9-r37.4 under Angstrom
ping? Am 21.01.2011 um 16:12 schrieb Dr. Michael Lauer: Philip, unfortunately you're not commenting on Frans' actual point, which no longer has anything to do with the u-boot thing. Board, when can we schedule a meeting? :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] problems compiling glibc_2.9-r37.4 under Angstrom
I fully agree and support this. It has become unbearable again. To the risk of repeating myself, I feel this attitude is damaging the reputation of the OpenEmbedded community and thus its attractivity for contributors, both present and future ones. Board, which options do we have? :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/4] python-wifi: add recipe for version 0.5.0
Acked-by: Michael 'Mickey' Lauer mla...@vanille-media.de ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 2/4] python-wifi: remove version 0.3.1
Acked-by: Michael 'Mickey' Lauer mla...@vanille-media.de ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [oe-commits] Philip Balister : i2c-tools : Stage i2c-dev.h header as i2c-dev-user.h.
Am 10.12.2010 um 15:36 schrieb git version control: Module: openembedded.git Branch: org.openembedded.dev Commit: 48e6a063370a38a35f31a28efd8f6ce6ebf00840 URL: http://gitweb.openembedded.net/?p=openembedded.gita=commit;h=48e6a063370a38a35f31a28efd8f6ce6ebf00840 Author: Philip Balister phi...@balister.org Date: Fri Dec 10 09:31:01 2010 -0500 i2c-tools : Stage i2c-dev.h header as i2c-dev-user.h. Thanks to John Faith for suggesting this approach on the ML. The problem is i2c-tools overwrites the header staged by the kernel. This breaks programs that depend on the kernel header. I don't think this a good solution. Now all programs break which expect this very i2c-dev.h as being staged by i2c-tools. Interestingly, the desktop distros don't bother about staging it differently, so why can't we do the same? Besides, the i2c-dev.h as staged by i2c-tools is supposed to be a superset. If it isn't we should complain with the i2c-tools developers. What can we do in the meantime? :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/7] gsmd.inc: remove useless RDEPENDS_append =
Acked-By: Michael 'Mickey' Lauer mic...@openmoko.org :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 2/7] directfb_2.18: remove useless LDFLAGS_append =
Acked-by: Michael 'Mickey' Lauer mla...@vanille-media.de :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Moving openmoko recipes and classes to obsolete
Acked-by: Michael 'Mickey' Lauer mic...@openmoko.org :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] libgee_0.6.0: gee/Makefile.am:95: HAVE_INTROSPECTION does not appear in AM_CONDITIONAL
That probably needs to be converted into a DEPENDS. Cheers, :M: Am 07.10.2010 um 21:35 schrieb Steve Sakoman sako...@gmail.com: On Wed, Oct 6, 2010 at 4:33 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: Dear OE folks, `configure` fails for me for `libgee_0.6.0.bb` [1]. | gee/Makefile.am:95: HAVE_INTROSPECTION does not appear in AM_CONDITIONAL `libgee_0.5.2.bb` builds correctly because it does not yet use gobject-introspection. This question was brought up before but was left unanswered [2]. There was no file `introspection.m4`, where `HAVE_INTROSPECTION` is defined in, in …/work/armv7a-oe-linux-gnueabi/libgee-1_0.6.0-r1/libgee-0.6.0/m4 as recommended in [3]. Should the m4 file be copied there as it is done for the other m4 files? […] | autoreconf: configure.ac: tracing | autoreconf: running: libtoolize --copy --force | libtoolize: putting auxiliary files in `.'. | libtoolize: copying file `./ltmain.sh' | libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. | libtoolize: copying file `m4/libtool.m4' | libtoolize: copying file `m4/ltoptions.m4' | libtoolize: copying file `m4/ltsugar.m4' | libtoolize: copying file `m4/ltversion.m4' | libtoolize: copying file `m4/lt~obsolete.m4' […] I manually put the m4 file [4] into `libgee-0.6.0/m4/` and added `m4/introspection.m4` to `EXTRA_DIST` in `Makefile.am` to `` but bitbake -c configure libgee still failed. Do you have any ideas? I found that if I built gobject-introspection-native manually, then libgee would complete without error. The DEPENDS_virtclass-native = gobject-introspection-native in the libgee recipe isn't triggering the build automatically. Steve ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] minimal-uclibc: freesmartphone/libfsobasics_git.bb: do_compile() failed: utilities.c:35:22: fatal error: execinfo.h: No such file or directory
Hi Paul, utilities.c:35:22: fatal error: execinfo.h: No such file or directory compilation terminated. make[3]: *** [utilities.lo] Error 1 make[3]: Leaving directory `/oe/build-minimal-uclibc/minimal-uclibc-dev/work/armv7a-oe-linux-uclibceabi/libfsobasics-1_0.9.10+gitr0+b163e36f9c960c6fea92168e88201be98dcceaef-r2.0/git/libfsobasics/fsobasics' make[2]: *** [all] Error 2 make[2]: Leaving directory `/oe/build-minimal-uclibc/minimal-uclibc-dev/work/armv7a-oe-linux-uclibceabi/libfsobasics-1_0.9.10+gitr0+b163e36f9c960c6fea92168e88201be98dcceaef-r2.0/git/libfsobasics/fsobasics' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/oe/build-minimal-uclibc/minimal-uclibc-dev/work/armv7a-oe-linux-uclibceabi/libfsobasics-1_0.9.10+gitr0+b163e36f9c960c6fea92168e88201be98dcceaef-r2.0/git/libfsobasics' make: *** [all] Error 2 FATAL: oe_runmake failed ERROR: Function do_compile failed Does anyone have a clue on how that can be fixed. `execinfo.h` is not available in uClibc and is a “GNUism” [2]. The dependency in in `linux.vapi` [3] and got included in [4]. Unfortunately I do not know how to exclude that. I guess Autotools should check if `execinfo.h` is available and only use it if it is. But I do not know how to do that. Michael, are those libraries intended to be used with uClibc? Yeah. I'll think about a way to fix it when I'm back end of next week (currently on vacation). If this is too much work, how can I exclude this recipe from console-image for minimal-uclibc? I bet there are some of my debugging utilities dragging this in, check – and remove for now – these. Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 1/2] python-2.6: remove python-dev from python-modules
Hi Eric, thanks for your patches. Unfortunately we can't apply them in the present form since (as you can see when you read the first couple of lines of manifest.inc) the manifest is autogenerated by a script in our contrib/python directory. Please patch this script rather than the manifest itself. Thanks! :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OE MediaWiki Version
Am 08.09.2010 um 08:43 schrieb Steffen Sledz: Am 07.09.2010 13:03, schrieb Dr. Michael Lauer: Just a little hint to the OE wiki admins: The running MediaWiki version 1.12.0 (see http://wiki.openembedded.net/index.php/Special:Version) is really outdated. There are a lot of bug and security fixes (see http://www.mediawiki.org/wiki/News). May be there's some time to run a little update. ;-) I'm afraid there's no one feeling responsible for it atm., e.g. the wiki still runs on amethyst although I asked for it to be moved to the main server months ago... If there's really nobody responsible for it i could (try to) do the work. Cool. Rolf used to do that, but he's no longer OE these days. OK, so who's the contact for the server itself? We can ask Rod Whitby to get you an account on the new server, I can give you access to amethyst. But i cannot engage myself to maintain it all the time in the future. Sure. Do you have experience with linux server configuration etc.? Yes, for a lot of years. Excellent :) :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OE MediaWiki Version
Am 07.09.2010 um 12:42 schrieb Steffen Sledz: Am 06.09.2010 20:10, schrieb Michael 'Mickey' Lauer: Am Montag, den 06.09.2010, 17:20 +0200 schrieb Steffen Sledz: Just a little hint to the OE wiki admins: The running MediaWiki version 1.12.0 (see http://wiki.openembedded.net/index.php/Special:Version) is really outdated. There are a lot of bug and security fixes (see http://www.mediawiki.org/wiki/News). May be there's some time to run a little update. ;-) I'm afraid there's no one feeling responsible for it atm., e.g. the wiki still runs on amethyst although I asked for it to be moved to the main server months ago... If there's really nobody responsible for it i could (try to) do the work. Cool. Rolf used to do that, but he's no longer OE these days. But i cannot engage myself to maintain it all the time in the future. Sure. Do you have experience with linux server configuration etc.? Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] utils.bbclass: remove tests for checksums.ini
Acked-by: Michael 'Mickey' Lauer mic...@vanille-media.de
Am 02.09.2010 um 11:02 schrieb Frans Meulenbroeks:
Bump
2010/8/16 Frans Meulenbroeks fransmeulenbro...@gmail.com:
Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
---
As we have checksums in recipes for quite a while now, I feel the time has
come to
remove the checksums.ini code from utils.bbclass and to remove the (now
empty)
checksums.ini file.
Attached is the patch.
Your feedback is appreciated
classes/utils.bbclass | 45 +
1 files changed, 1 insertions(+), 44 deletions(-)
delete mode 100644 conf/checksums.ini
diff --git a/classes/utils.bbclass b/classes/utils.bbclass
index 7740ea3..83cf33c 100644
--- a/classes/utils.bbclass
+++ b/classes/utils.bbclass
@@ -157,50 +157,7 @@ def base_get_checksums(pn, pv, src_uri, localpath,
params, data):
expected_md5sum = bb.data.getVarFlag(SRC_URI, md5flag, data)
expected_sha256sum = bb.data.getVarFlag(SRC_URI, sha256flag, data)
-if (expected_md5sum and expected_sha256sum):
-return (expected_md5sum,expected_sha256sum)
-else:
-# missing checksum, parse checksums.ini
-
-# Verify the SHA and MD5 sums we have in OE and check what do
-# in
-checksum_paths = bb.data.getVar('BBPATH', data, True).split(:)
-
-# reverse the list to give precedence to directories that
-# appear first in BBPATH
-checksum_paths.reverse()
-
-checksum_files = [%s/conf/checksums.ini % path for path in
checksum_paths]
-try:
-parser = base_chk_load_parser(checksum_files)
-except ValueError:
-bb.note(No conf/checksums.ini found, not checking checksums)
-return (None,None)
-except:
-bb.note(Creating the CheckSum parser failed: %s:%s %
(sys.exc_info()[0], sys.exc_info()[1]))
-return (None,None)
-pn_pv_src = %s-%s-%s % (pn,pv,src_uri)
-pn_src= %s-%s % (pn,src_uri)
-if parser.has_section(pn_pv_src):
-expected_md5sum= parser.get(pn_pv_src, md5)
-expected_sha256sum = parser.get(pn_pv_src, sha256)
-elif parser.has_section(pn_src):
-expected_md5sum= parser.get(pn_src, md5)
-expected_sha256sum = parser.get(pn_src, sha256)
-elif parser.has_section(src_uri):
-expected_md5sum= parser.get(src_uri, md5)
-expected_sha256sum = parser.get(src_uri, sha256)
-else:
-return (None,None)
-
-if name:
-bb.note(This package has no checksums in corresponding recipe
'%s', please consider moving its checksums from checksums.ini file \
-\nSRC_URI[%s.md5sum] = \%s\\nSRC_URI[%s.sha256sum] =
\%s\\n % (bb.data.getVar(FILE, data, True), name, expected_md5sum,
name, expected_sha256sum))
-else:
-bb.note(This package has no checksums in corresponding recipe
'%s', please consider moving its checksums from checksums.ini file \
-\nSRC_URI[md5sum] = \%s\\nSRC_URI[sha256sum] = \%s\\n
% (bb.data.getVar(FILE, data, True), expected_md5sum, expected_sha256sum))
-
-return (expected_md5sum, expected_sha256sum)
+return (expected_md5sum,expected_sha256sum)
def base_chk_file(pn, pv, src_uri, localpath, params, data):
(expected_md5sum, expected_sha256sum) = base_get_checksums(pn, pv,
src_uri, localpath, params, data)
diff --git a/conf/checksums.ini b/conf/checksums.ini
deleted file mode 100644
index e69de29..000
--
1.7.0.4
___
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] minimal.conf: added ivp4 and ipv6 as distro features
Am Donnerstag, den 26.08.2010, 16:55 +0200 schrieb Frans Meulenbroeks: minimal.conf has nfs as distro feature but not ip4 or ipv6. This makes that busybox does not generate networking applets Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com Acked-by: Michael 'Mickey' Lauer mla...@vanille-media.de Well spot, thanks! :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [RFC] review process
Am Freitag, den 27.08.2010, 14:15 +0200 schrieb Frans Meulenbroeks: 1. If a patch does not get any review feedback in X weeks time; it is ok to apply it. People who need more time to review a patch can mention that in a short reply. In that case they are granted Y more weeks to review. (suggestion: X = Y = 2) 2. If someone NAKs a patch it is obligatory to provide an explanation why the patch is not good. Rationale is that a) people can fix the problem seen by the reviewer b) people learn from it c) if there is a disagreement it can be discussed (and if needed raised to the TSC) 3) NAKs that are not motivated/explained can be ignored as not given. Your feedback, suggestions, additions, amendments, whatever is appreciated. I agree with that. If someone does the work to create a patch he thinks is worthwhile to apply the least we can do when NAKing is to explain why it is not a good idea. :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Write access for Simon Busch
Simon, send Cliff and me your SSH key. Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] rename files dirs
Currently lots of our patches reside in a directory called files. Somewhere in the past koen explained me that that is not really proper (and I agree with them). I disagree with that. In fact I'd rather suggest the other way, which is: Put them all into files/ unless you have a compelling reason not to, i.e. the moment one patch does not apply any longer to all versions of the recipes; then it should be moved to PN-PV directory. Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] `DEFAULT_PREFERENCE = -1` of current (upstream) releases (was: [PATCH] openssl: update 1.0.0 to 1.0.0a)
Am 17.08.2010 um 09:26 schrieb Paul Menzel: Am Dienstag, den 17.08.2010, 10:50 +0400 schrieb Roman I Khimov: В сообщении от Понедельник 16 августа 2010 23:35:59 автор Khem Raj написал: IMO the newest version in a recipe should always be default preference this way we can stabilize recipe upgrades quicker. This also means a wider testing before pushing a new recipe DEFAULT_PREFERENCE = -1 makes it to escape the testing. Well, consider Perl, for example. Making 5.10.1 a default preference would break binary packaged perl modules built for 5.8.8, so technically some massive PR bump (most probably DISTRO_PR) is needed when updating to 5.10.1. Forcing distro maintainers to do that is not nice, IMO. Although the way it is now Perl 5.10.1 seems to be rarely used, which is also not nice. Probably, there is no way to solve this problem for everyone. With D_P it's not used much, removing D_P is asking for YOU BROKE MY BUILD!!! love messages from random corners. What about removing `DEFAULT_PREFERENCE = -1` and have the distributions not wanting it pinning to the old version? This could be done after a period of time after the push and an announcement to the list asking what distribution prefers what and make that change in one commit. That sounds good to me. We should really try to keep a reasonable default set of preferences so that certain DISTRO setting are not mandatory. Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] rename files dirs
Am 17.08.2010 um 10:55 schrieb Koen Kooi: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17-08-10 10:39, Dr. Michael Lauer wrote: Currently lots of our patches reside in a directory called files. Somewhere in the past koen explained me that that is not really proper (and I agree with them). I disagree with that. In fact I'd rather suggest the other way, which is: Put them all into files/ unless you have a compelling reason not to, i.e. the moment one patch does not apply any longer to all versions of the recipes; then it should be moved to PN-PV directory. What's wrong with putting those patches in PN/ instead of files/? Having them in files/ significantly threatens all efforts to clean up the recipes/ structure :( I didn't say it's wrong, but rather that the workflow I presented feels more natural to me. I can live with putting them all in PN. Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] CALL FOR ACTION: get rid of native recipes
Hi Frans, that's pretty cool, however I think we should restrict this list to those recipes which also have a non-native variant. E.g. the 2nd entry in this list is android-image-utils-native for which a non-native variant makes little sense. Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] 500+ recipes: remove do_stage
Acked-by: Michael 'Mickey' Lauer mla...@vanille-media.de
Am 02.08.2010 um 22:19 schrieb Frans Meulenbroeks:
This patch removes all occurrences of
do_stage() {
autotools_stage_all
}
including all kind of variants w.r.t whitespace
Signed-off-by: Frans Meulenbroeks fransmeulenbro...@gmail.com
[...]
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] CALL FOR ACTION: get rid of native recipes
Am 03.08.2010 um 14:46 schrieb Richard Purdie: On Tue, 2010-08-03 at 10:21 +0200, Dr. Michael Lauer wrote: that's pretty cool, however I think we should restrict this list to those recipes which also have a non-native variant. E.g. the 2nd entry in this list is android-image-utils-native for which a non-native variant makes little sense. Just to add, there are some cases where the -native recipe still makes sense as the alternative is rather ugly for example, python-native, perl-native and a handful of others. The number of these cases is extremely small however. BBCLASSEXTEND makes sense in most cases. Oh right, the recipes for those pesky scripting languages are quite finnicky, so I would prefer to not change them unless absolutely necessary :) Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] OE recipe tree quality
Am 30.07.2010 um 11:01 schrieb Frans Meulenbroeks: people are quite clear on this, pick a version and stick with it. You're hitting the nail on head with this. One of the problems of OE is that we want to support too many versions at the same time. dev head should not have two versions of bluez in the first place. With this I wholeheartedly agree (in principle – there will always be exceptions due to combination problems). BTW and blacklisting is only a side observation on why things fail. It would still be good to fix the dependency issues. Agreed. :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] htcdream.conf: use xf86-video-fbdev and xf86-video-tslib
Acked-by: Michael 'Mickey' Lauer mla...@vanille-media.de Am 06.07.2010 um 08:01 schrieb Denis 'GNUtoo' Carikli: Signed-off-by: Denis 'GNUtoo' Carikli gnu...@no-log.org --- conf/machine/htcdream.conf | 11 +++ recipes/tasks/task-x11.bb |2 +- 2 files changed, 12 insertions(+), 1 deletions(-) diff --git a/conf/machine/htcdream.conf b/conf/machine/htcdream.conf index a10edb8..3cf1ebf 100644 --- a/conf/machine/htcdream.conf +++ b/conf/machine/htcdream.conf @@ -19,3 +19,14 @@ MACHINE_EXTRA_RRECOMMENDS = \ PREFERRED_PROVIDER_virtual/kernel = linux-leviathan + +XSERVER = \ +xserver-xorg \ +xserver-xorg-extension-glx \ +xserver-xorg-extension-dri \ +xf86-input-tslib \ +xf86-input-evdev \ +xf86-input-mouse \ +xf86-input-keyboard \ +xf86-video-fbdev \ + diff --git a/recipes/tasks/task-x11.bb b/recipes/tasks/task-x11.bb index 5eeb8ba..77e281e 100644 --- a/recipes/tasks/task-x11.bb +++ b/recipes/tasks/task-x11.bb @@ -2,7 +2,7 @@ DESCRIPTION = The X Window System -- install this task to get a client/server b SECTION = x11/server LICENSE = MIT PV = 1.0 -PR = r4 +PR = r5 # WORK IN PROGRESS -- 1.7.0.4 ___ 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 1/9] mesa: remove old 6.0 and 6.4 recipes which are not using any include file
Am 28.06.2010 um 13:41 schrieb Koen Kooi: And if cutting is too hard, there's always the option to top post :) Agreed. In that case I think top-posting is perfectly acceptable. Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] who here has an active twitter account worth following?
http://twitter.com/DrMickeyLauer Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 00/12] motorola-ezx related changes
Am 31.05.2010 um 12:20 schrieb Stefan Schmidt: Hello. On Mon, 2010-05-31 at 11:55, Antonio Ospite wrote: Hi, here's some motorola-ezx related changes, plus a couple of other fixes I am using here. Namely, the non ezx related changes are 01 and 02. Can anyone review and apply, please? I would prefer if you could push it yourself after the review. Therefor I propose write-access for Antonio. +1. Antonio, please send Cliff and me your SSH key. :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Broken recipes
Hi Bill, Can someone tell me the reason for keeping broken recipes in the tree? Define 'broken'; some packages only build for a certain combination of $MACHINE and $DISTRO, and sometimes perhaps even $OUT_OF_TREE_OVERLAY. If a package is definitely broken, we should move it to 'broken' (if there is still any interest in it), or remove it altogether. Most of the time it's maintainers disappearing and who knows when or if they will appear again, so why annoy them by removing the recipe? There's also lack of manpower to throw into the equation. Which concrete recipes do you mean? I'd agree with removing a dozen of openmoko ones for distributions that noone works on any longer (i.e. Openmoko 2007.2 and Openmoko 2008), but please tell me exactly which ones. Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] Add error handling to stage-manager
Am 23.04.2010 um 14:42 schrieb Mickaël Chazaux:
Add an error message telling the cause of the crash to the user.
---
recipes/stage-manager/files/stage-manager | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/recipes/stage-manager/files/stage-manager
b/recipes/stage-manager/files/stage-manager
index 536d1af..a2ecebe 100755
--- a/recipes/stage-manager/files/stage-manager
+++ b/recipes/stage-manager/files/stage-manager
@@ -29,11 +29,15 @@ def read_cache(cachefile):
lines = f.readlines()
f.close()
for l in lines:
-data = l.split('|')
-cache[data[0]] = {}
-cache[data[0]]['ts'] = int(data[1])
-cache[data[0]]['size'] = int(data[2])
-cache[data[0]]['seen'] = False
+ try:
+data = l.split('|')
+cache[data[0]] = {}
+cache[data[0]]['ts'] = int(data[1])
+cache[data[0]]['size'] = int(data[2])
+cache[data[0]]['seen'] = False
+ except IndexError, e:
+print(Corrupted line in cachefile + cachefile + : + l)
+ raise e
return cache
Completely unrelated, but this code is slow. The recurring
evaluation of cache[data[0]] is not being cached or optimized,
I suggest something along:
d = cache[data[0]] = {}
d[ts] = int(data[1])
d[size] = int(data[2])
...
:M:
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] About having a static /dev
Am 22.04.2010 um 14:46 schrieb Antonio Ospite: On Thu, 22 Apr 2010 12:55:43 +0100 Phil Blundell ph...@gnu.org wrote: On Thu, 2010-04-22 at 13:43 +0200, Antonio Ospite wrote: 2. If I install any package which depends on udev then udev is brought in and the static layout is gone at the next boot. I think your best option is probably to make udev be a DISTRO_FEATURE and not set it for your own distribution. If you genuinely want udev to be selected (for your particular DISTRO) on a per-MACHINE basis then you'll have to invent some way to nobble its startup script so that it just doesn't do anything on machines where it isn't wanted. A per-MACHINE way would be better IMHO, I am thinking about adding a check on something like /dev/.staticdev (suggested in [1]) to both udev init script and to the 'device' script from initscripts, and make the image class add the /dev/.staticdev file when IMAGE_DEV_MANAGER == (or maybe == static or none?) Does this sound reasonable? Please also handle the case where we neither want an IMAGE_DEV_MANAGER nor static device population, since we use devtmpfs. :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] frameworkd-config-shr: fix a nasty typo
Thanks a lot, Antonio. Well spotted! I have since removed all remaining traces of om3d7k. Cheers, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] python-setuptools: Version bump to 0.6c11
Acked-by: Michael 'Mickey' Lauer mla...@vanille-media.de
Cheers,
:M:
Am 26.03.2010 um 22:57 schrieb Stefan Schmidt
ste...@datenfreihafen.org:
Hello.
Mickey, do you have a moment to review and comment on this python
related patch?
regards
Stefan Schmidt
On Mon, 2010-02-22 at 17:54, Michael Lippautz wrote:
* Adds python module 'pkg_resources'.
Signed-off-by: Michael Lippautz michael.lippa...@gmail.com
---
.../python-setuptools/fix-log-usage-0.6c11.patch | 18 ++
++
recipes/python/python-setuptools_0.6c11.bb | 22 ++
++
2 files changed, 40 insertions(+), 0 deletions(-)
create mode 100644 recipes/python/python-setuptools/fix-log-
usage-0.6c11.patch
create mode 100644 recipes/python/python-setuptools_0.6c11.bb
diff --git a/recipes/python/python-setuptools/fix-log-
usage-0.6c11.patch b/recipes/python/python-setuptools/fix-log-
usage-0.6c11.patch
new file mode 100644
index 000..b860700
--- /dev/null
+++ b/recipes/python/python-setuptools/fix-log-usage-0.6c11.patch
@@ -0,0 +1,18 @@
+--- a/setuptools/command/sdist.py2010-02-22 14:57:56.0
+0100
b/setuptools/command/sdist.py2010-02-22 14:57:31.0
+0100
+@@ -1,6 +1,5 @@
+ from distutils.command.sdist import sdist as _sdist
+ from distutils.util import convert_path
+-from distutils import log
+ from glob import glob
+ import os, re, sys, pkg_resources
+
+@@ -94,7 +93,7 @@
+ try: svnver = int(data.splitlines()[0])
+ except: pass
+ if svnver8:
+-log.warn(unrecognized .svn/entries format in %s,
dirname)
++print(unrecognized .svn/entries format in %s,
dirname)
+ return
+ for record in map(str.splitlines, data.split('\n\x0c\n')
[1:]):
+ if not record or len(record)=6 and record[5]
==delete:
diff --git a/recipes/python/python-setuptools_0.6c11.bb b/recipes/
python/python-setuptools_0.6c11.bb
new file mode 100644
index 000..bccafa4
--- /dev/null
+++ b/recipes/python/python-setuptools_0.6c11.bb
@@ -0,0 +1,22 @@
+DESCRIPTION = Download, build, install, upgrade, and uninstall
Python packages
+HOMEPAGE = http://cheeseshop.python.org/pypi/setuptools;
+SECTION = devel/python
+PRIORITY = optional
+LICENSE = MIT
+DEPENDS_${PN}-native = python-native
+RDEPENDS_${PN} = python-distutils python-compression
+PR = ml3
+
+SRC_URI = \
+ http://cheeseshop.python.org/packages/source/s/setuptools/${SRCNAME}-${PV}.tar.gz;name=setuptools
\
+ file://fix-log-usage-0.6c11.patch;patch=1 \
+
+SRC_URI[setuptools.md5sum] = 7df2a529a074f613b509fb44feefe74e
+SRC_URI[setuptools.sha256sum] =
630fea9b726320b73ee3ca6ff61732cb32675b0389be658080fe46383b87a1d3
+
+SRCNAME = setuptools
+S = ${WORKDIR}/${SRCNAME}-${PV}
+
+inherit distutils
+
+BBCLASSEXTEND = native
--
1.6.4.4
___
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] [PATCH 1/1] alsa-state: Add support for at91 boards
Some distros - e.g. Minimal - use the concept of a MACHINE_CLASS which
You define in the machine conf (take a look at htc-msm7.inc or ezx-
base) and that can then be used as OVERRIDE.
Cheers,
:M:
Am 15.03.2010 um 07:55 schrieb Ulf Samuelsson
ulf.samuels...@atmel.com:
Marcin Juszkiewicz skrev:
Dnia poniedziałek, 15 marca 2010 o 00:29:13 Ulf Samuelsson napisał
(a):
Add ALSA configuration files for at91 boards
Add bump PR of alsa-state and I will push such version.
Regards,
OK.
Base on your comment on linux, I will change to have a common
directory
as well, but is there a smarter way?
What I'd often like to do is to have one directory
for a group of machines.
So instead of:
++
FILES_XXX = Something
SRC_URI_at91sam92620ek = ${FILES_XXX}
SRC_URI_at91sam92621ek = ${FILES_XXX}
SRC_URI_at91sam92623ek = ${FILES_XXX}
I'd like to do:
-
SRC_URI_at91 = Something
+
--
Best Regards
Ulf Samuelsson
___
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] samba-essential upgrade or remove?
Am 15.03.2010 um 08:46 schrieb Holger Hans Peter Freyther: On Monday 15 March 2010 08:30:09 Frans Meulenbroeks wrote: Do we feel we have that responsibility? I didn't feel that sentiment when it came to removing other legacy recipes (some of which definitely also will have security issues). E.g. for openssl we have openssl_0.9.7e.bb openssl_0.9.7g.bb openssl_0.9.7m.bb openssl_0.9.8g.bb openssl_0.9.8m.bb I'm pretty certain the last one will fix some vulnerabilities present in the first one. Well you are comparing two different things here. One is having the _default_ of a recipe with known security issues, and one is keeping old non default recipes with security issues. If a distro maker decides to use an ancient version of OpenSSL it was his choice, if he just typed bitbake foo-image and he has a vulnerable daemon waiting to be owned in his default image... the story is a bit different. I think we have at least three options on how to deal with it: 1.) Put a big fat warning on Openembedded.org saying it should not be used for users that have network connectivity or might put a SDcard/Storage with content on a device as we don't care about fixing vulnerable software. Gets my vote; however with less dramatic wording. :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] samba-essential upgrade or remove?
While I'm not using it atm., I recall that samba-essential was the only recipe that worked relatively painless when Matthias Hentges create it back then. :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [RFC} glib-2.0 cleanup
Am 01.03.2010 um 15:35 schrieb Koen Kooi: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 28-02-10 22:35, Michael 'Mickey' Lauer wrote: please both the lets-keep-everything-no-matter-how-rotten and also the lets-strive-for-few-high-quality recipes. Note that plainly deleting them as proposed does neither, it doesn't make the remaining recipes high quality, it just reduces the amount of recipes. Absolutely true, however it is my belief that a load of similar yet different recipes for a package decrease the motivation to get started and improving something. And I want to reiterate the importance of new-style staging and leveraging that for BBCLASSEXTEND. Sure. That's certainly a good step, I just think it's not enough. :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH] ezx: Use pulseaudio 0.9.15
Hi Antonio, Be patient but my knowledge of OE is still limited, the point here is that distros can override PREFERRED_VERSIONs set in machine files, isn't it? Machines should not limit versions, only providers; distros and local configurations are the ones supposed to specify versions. Then again, this assumption relies on the default configuration being working, which -- in case of pulseaudio -- it obviously is not. Of course one could argue that there is a bug in the OE recipes metadata rather than the distro, since the pulseaudio recipes are known broken for certain architectures -- however they don't contain any blacklisting or whitelisting except for om-gta01/om-gta02 which I added when I became aware of the problem. Antonio, lets just blacklist the broken versions for the machines you're interested in. :M: I can well add DEFAULT_PREFERENCE_om-a780 = -1 in both pulseaudio_0.9.21.bb and pulseaudio_0.9.19.bb Is that what you mean Mickey? Yes. Way better than my solution but still a bit hackish. Not necessarily. It would be better if we could limit it for armv4(t) and armv5(t), however we don't have such fine granular overrides, hence we need to blacklist on machine basis. If that's OK for you, it'll be fine with me as well. :) About fixing distro, isn't 'minimal' supposed to build all the latest recipes? If so a conf/distro/include/preferred-minimal-versions.inc would not have much sense if we can't set preference rules per machines (or archs). We can set preference rules per machine or arch, however the general consensus is that this is being done in the distro or local conf. Yes that codifies machine knowledge in distro and may have to be revisited, but at least it has been our working style until now. :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Can I use python-pyqt_4.4.3.bb with qt4-embedded_4.4.3.bb
You need to try that. For some years I used to maintain the embedded support of PyQt after Phil Thompson stopped supporting it. I used that a lot in my Zaurus projects, however I'm no longer interested in that. Chances are you have to catch up with a large number of changes in Qt/E. Good speed, :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] [PATCH 2/2] python-cython: add version 0.12
Acked-by: Michael 'Mickey' Lauer mic...@vanille-media.de
Am 28.01.2010 um 23:51 schrieb Martin Jansa:
Signed-off-by: Martin Jansa martin.ja...@gmail.com
---
recipes/python/python-cython-native_0.12.bb | 10 ++
recipes/python/python-cython_0.12.bb| 16
2 files changed, 26 insertions(+), 0 deletions(-)
create mode 100644 recipes/python/python-cython-native_0.12.bb
create mode 100644 recipes/python/python-cython_0.12.bb
diff --git a/recipes/python/python-cython-native_0.12.bb
b/recipes/python/python-cython-native_0.12.bb
new file mode 100644
index 000..95886ae
--- /dev/null
+++ b/recipes/python/python-cython-native_0.12.bb
@@ -0,0 +1,10 @@
+require python-cython_${PV}.bb
+inherit native
+DEPENDS = python-native
+RDEPENDS =
+
+do_stage() {
+PYTHONPATH=${STAGING_BINDIR} BUILD_SYS=${BUILD_SYS} HOST_SYS=${HOST_SYS}
\
+STAGING_LIBDIR=${STAGING_LIBDIR} STAGING_INCDIR=${STAGING_INCDIR} \
+${STAGING_BINDIR}/python setup.py install
--prefix=${STAGING_BINDIR}/.. --install-data=${STAGING_DATADIR}
+}
diff --git a/recipes/python/python-cython_0.12.bb
b/recipes/python/python-cython_0.12.bb
new file mode 100644
index 000..846be47
--- /dev/null
+++ b/recipes/python/python-cython_0.12.bb
@@ -0,0 +1,16 @@
+DESCRIPTION = Cython is a language specially designed for writing Python
extension modules. \
+It's designed to bridge the gap between the nice, high-level, easy-to-use
world of Python \
+and the messy, low-level world of C.
+SECTION = devel/python
+PRIORITY = optional
+LICENSE = GPL
+SRCNAME = Cython
+PR = ml0
+
+SRC_URI =
http://www.cython.org/release/${SRCNAME}-${PV}.tar.gz;name=archive;
+S = ${WORKDIR}/${SRCNAME}-${PV}
+
+SRC_URI[archive.md5sum] = f73ad2258115c92ce982d34d27580076
+SRC_URI[archive.sha256sum] =
90d611aeff8d017a5ccca3b1e02ec8d6dd0efc7dfd29806f721bc718d3774ea3
+
+inherit distutils
--
1.6.6.1
___
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 1/2] python: add version 2.6.4
Great work, thanks! Acked-by: Michael 'Mickey' Lauer mic...@vanille-media.de Am 28.01.2010 um 23:51 schrieb Martin Jansa: Signed-off-by: Martin Jansa martin.ja...@gmail.com --- .../00-fix-bindir-libdir-for-cross.patch | 20 +++ .../01-use-proper-tools-for-cross-build.patch | 116 .../python-2.6.4/02-remove-test-for-cross.patch| 94 + .../python-2.6.4/03-fix-tkinter-detection.patch| 40 ++ .../python-2.6.4/04-default-is-optimized.patch | 52 .../05-enable-ctypes-cross-build.patch | 28 .../python-2.6.4/99-ignore-optimization-flag.patch | 19 +++ recipes/python/python-2.6.4/sitecustomize.py | 45 +++ .../00-fix-bindir-libdir-for-cross.patch | 20 +++ .../04-default-is-optimized.patch | 18 +++ .../10-distutils-fix-swig-parameter.patch | 16 +++ .../11-distutils-never-modify-shebang-line.patch | 18 +++ ...2-distutils-prefix-is-inside-staging-area.patch | 60 + recipes/python/python-native-2.6.4/debug.patch | 27 .../python/python-native-2.6.4/nohostlibs.patch| 53 .../python/python-native-2.6.4/sitecustomize.py| 45 +++ recipes/python/python-native_2.6.4.bb | 33 + recipes/python/python_2.6.4.bb | 139 18 files changed, 843 insertions(+), 0 deletions(-) create mode 100644 recipes/python/python-2.6.4/00-fix-bindir-libdir-for-cross.patch create mode 100644 recipes/python/python-2.6.4/01-use-proper-tools-for-cross-build.patch create mode 100644 recipes/python/python-2.6.4/02-remove-test-for-cross.patch create mode 100644 recipes/python/python-2.6.4/03-fix-tkinter-detection.patch create mode 100644 recipes/python/python-2.6.4/04-default-is-optimized.patch create mode 100644 recipes/python/python-2.6.4/05-enable-ctypes-cross-build.patch create mode 100644 recipes/python/python-2.6.4/99-ignore-optimization-flag.patch create mode 100644 recipes/python/python-2.6.4/sitecustomize.py create mode 100644 recipes/python/python-native-2.6.4/00-fix-bindir-libdir-for-cross.patch create mode 100644 recipes/python/python-native-2.6.4/04-default-is-optimized.patch create mode 100644 recipes/python/python-native-2.6.4/10-distutils-fix-swig-parameter.patch create mode 100644 recipes/python/python-native-2.6.4/11-distutils-never-modify-shebang-line.patch create mode 100644 recipes/python/python-native-2.6.4/12-distutils-prefix-is-inside-staging-area.patch create mode 100644 recipes/python/python-native-2.6.4/debug.patch create mode 100644 recipes/python/python-native-2.6.4/nohostlibs.patch create mode 100644 recipes/python/python-native-2.6.4/sitecustomize.py create mode 100644 recipes/python/python-native_2.6.4.bb create mode 100644 recipes/python/python_2.6.4.bb diff --git a/recipes/python/python-2.6.4/00-fix-bindir-libdir-for-cross.patch b/recipes/python/python-2.6.4/00-fix-bindir-libdir-for-cross.patch new file mode 100644 index 000..2559e3a --- /dev/null +++ b/recipes/python/python-2.6.4/00-fix-bindir-libdir-for-cross.patch @@ -0,0 +1,20 @@ +# $(exec_prefix) points to the wrong directory, when installing +# a cross-build. @bindir@ and @libdir@ works better and doesn't +# affect the native build. +# Signed-Off: Michael 'Mickey' Lauer mic...@vanille-media.de + +Index: Python-2.6.1/Makefile.pre.in +=== +--- Python-2.6.1.orig/Makefile.pre.in Python-2.6.1/Makefile.pre.in +@@ -86,8 +86,8 @@ exec_prefix= @exec_prefix@ + datarootdir=@datarootdir@ + + # Expanded directories +-BINDIR= $(exec_prefix)/bin +-LIBDIR= $(exec_prefix)/lib ++BINDIR= @bindir@ ++LIBDIR= @libdir@ + MANDIR= @mandir@ + INCLUDEDIR= @includedir@ + CONFINCLUDEDIR= $(exec_prefix)/include diff --git a/recipes/python/python-2.6.4/01-use-proper-tools-for-cross-build.patch b/recipes/python/python-2.6.4/01-use-proper-tools-for-cross-build.patch new file mode 100644 index 000..e89faa4 --- /dev/null +++ b/recipes/python/python-2.6.4/01-use-proper-tools-for-cross-build.patch @@ -0,0 +1,116 @@ +# We need to ensure our host tools get run during build, not the freshly +# built cross-tools (this will not work), so we introduce HOSTPYTHON and HOSTPGEN. +# Signed-Off: Michael 'Mickey' Lauer mic...@vanille-media.de + +Index: Python-2.6.1/Makefile.pre.in +=== +--- Python-2.6.1.orig/Makefile.pre.in Python-2.6.1/Makefile.pre.in +@@ -175,6 +175,7 @@ UNICODE_OBJS= @UNICODE_OBJS@ + + PYTHON= python$(EXE) + BUILDPYTHON=python$(BUILDEXE) ++HOSTPYTHON= $(BUILDPYTHON) + + # The task to run while instrument when building the profile-opt target + PROFILE_TASK=
Re: [oe] python-lang causing Alignment trap and Segfault
Try running python -v to find out exactly which module is triggering that. Cheers, :M: Am 23.01.2010 um 20:45 schrieb Josh Kropf j...@slashdev.ca: I've compiled an image for my mini2440 board (armv4t) from the stable/2009 branch in git using angstrom distribution. One of the python packages I need depends on python-lang but I'm finding that python segfaults when python-lang is installed. The kernel logs the following before the segfault: Alignment trap: python (2303) PC=0x403f007c Instr=0x28001c05 Address=0x FSR 0x813 Removing python-lang package makes python work again. Just wondering if anyone has run into this problem or has some pointers on debugging this. Thanks, - Josh ___ 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] Getting patches committed
Am 21.01.2010 um 11:02 schrieb Holger Hans Peter Freyther: 2. Is there a way to have a staging branch where all patches are committed to, which have not been reviewed for let us say one week, to get more testing and before they go into the dev branch? Maybe it is easier for people to at least test build such a branch? Would you be interested in creating such a branch for us? I assume it is certainly easier to git cherry-pick a patch than to download the mbox and use git am.. I fully agree. I'm neither using patchwork nor do I find patches on the list a good idea. I'd welcome for-oe-upstream trees that would contain patches that -- if good -- we could just pull from. :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] Error while running bibake
Am 01.12.2009 um 11:29 schrieb Frans Meulenbroeks: 2009/12/1 vivek tambakad vivektamba...@gmail.com: hi I want cross compile linphone for compulab EM-x270 board.when i try sudo bitbake -b /home/development/em-x270/stuff/openembedded/recipes/linphone/ linphone_3.1.0.bb then i will get the following error *bb.parse.ParseError: Could not inherit file classes/autotools.bbclass * pleasse guide me in compiling linphone for compulab board. first remark: there is no need to run bitbake as root. 2nd thing you could check is if the file exists in your tree and if so if your path is set properly. More remarks: 1. Don't use -b unless you really know what you are doing, better use 'bitbake linphone'. 2. Check whether BBPATH is correctly set (pointing to your conf files). :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Re: [oe] compiling linphone using openembedded
Now i login as a user. I exported following paths export OEBASE=/home/development/em-x270/stuff export PATH=$OEBASE/bitbake/bin:$PATH export BBPATH=$OEBASE/build:$OEBASE/openembedded export BB_ENV_EXTRAWHITE=OEBASE and set CACHE variable in usr/share/bitbake/conf/bitbake.conf as CACHE = /home/development/em-x270/stuff/build/tmp when i compile bitbake linphone i get following error [vi...@primary build]$ bitbake linphone Traceback (most recent call last): File /home/development/em-x270/stuff/bitbake/bin/bitbake, line 143, in module main() File /home/development/em-x270/stuff/bitbake/bin/bitbake, line 123, in main cooker.parseConfiguration() File /home/development/em-x270/stuff/bitbake/lib/bb/cooker.py, line 68, in parseConfiguration self.parseConfigurationFile( os.path.join( conf, bitbake.conf ) ) File /home/development/em-x270/stuff/bitbake/lib/bb/cooker.py, line 402, in parseConfigurationFile bb.fetch.fetcher_init(self.configuration.data) File /home/development/em-x270/stuff/bitbake/lib/bb/fetch/__init__.py, line 93, in fetcher_init pd = persist_data.PersistData(d) File /home/development/em-x270/stuff/bitbake/lib/bb/persist_data.py, line 52, in __init__ bb.mkdirhier(self.cachedir) File /home/development/em-x270/stuff/bitbake/lib/bb/__init__.py, line 138, in mkdirhier if e.errno != 17: raise e *OSError: [Errno 13] Permission denied: '/home/development/em-x270/stuff/build/tmp' Sounds like your previous building with root messed up permissions. Use chmod/chown to correct. :M: ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
