Re: [oe] Error while bitbake meta-toolchain-qt5
Hi Otavio, Thanks for your mail. Yes, Otavio you are right. There is / at the end of DL_DIR in the local.conf file. I had removed that and once again given bitbake meta-toolchain-qt5 but as result as earlier. See the link below. http://pastebin.com/a8VjfKXh On Fri, Sep 5, 2014 at 5:29 PM, Otavio Salvador wrote: > On Fri, Sep 5, 2014 at 8:08 AM, Switesh Fulpagare > wrote: > > Hi Otavio, > >Thanks for your reply. > > I have applied the patch, now it is fetching qtwayland_git.bb but it is > > giving error for do unpack as shown in below link and > > qtwayland-native_git.bb is not going to fetch. > > > > > > http://pastebin.com/dk2gFin0 > > My bet is that your local.conf, DL_DIR, is pointing to a path with / > at end, fix it. > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.brhttp://code.ossystems.com.br > Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 > -- > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > -- “The contents of this e-mail message and any attachments are confidential and are intended solely for addressee. The information may also be legally privileged. This transmission is sent in trust, for the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail or phone and delete this message and its attachments, if any.” -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-browser][PATCH] chromium: Remove Chromium 35 recipe and obsolete patches
These patches are no longer used or needed anywhere. Chromium 35 is now
obsolete, since Chromium 37.0.2062.94 is the new stable version.
Signed-off-by: Carlos Rafael Giani
---
.../0001-Disable-ANGLE-commit-ID-generation.patch | 71 -
...tracker_notify_deprecated_since_ATK_2_9_4.patch | 17
.../chromium/fix-glib-deprecated-warning.patch | 32 --
.../chromium/chromium/secitem_array.patch | 26 -
.../chromium/chromium/uninitialised-warning.patch | 90 -
recipes-browser/chromium/chromium_35.0.1916.114.bb | 112 -
6 files changed, 348 deletions(-)
delete mode 100644
recipes-browser/chromium/chromium/0001-Disable-ANGLE-commit-ID-generation.patch
delete mode 100644
recipes-browser/chromium/chromium/001-atk_focus_tracker_notify_deprecated_since_ATK_2_9_4.patch
delete mode 100644
recipes-browser/chromium/chromium/fix-glib-deprecated-warning.patch
delete mode 100644 recipes-browser/chromium/chromium/secitem_array.patch
delete mode 100644
recipes-browser/chromium/chromium/uninitialised-warning.patch
delete mode 100644 recipes-browser/chromium/chromium_35.0.1916.114.bb
diff --git
a/recipes-browser/chromium/chromium/0001-Disable-ANGLE-commit-ID-generation.patch
b/recipes-browser/chromium/chromium/0001-Disable-ANGLE-commit-ID-generation.patch
deleted file mode 100644
index 72b978c..000
---
a/recipes-browser/chromium/chromium/0001-Disable-ANGLE-commit-ID-generation.patch
+++ /dev/null
@@ -1,71 +0,0 @@
-From 6ee39ace731dabdbe5e169ac5bc52b713afb1275 Mon Sep 17 00:00:00 2001
-From: Carlos Rafael Giani
-Date: Tue, 29 Jul 2014 12:08:25 +0200
-Subject: [PATCH] Disable ANGLE commit ID generation
-
-As part of the build process, ANGLE generates an ID out of the SRCREV
-of the git repo's HEAD. Since these recipes do not use a git repository,
-but a tarball release of Chromium, there is no HEAD, and building ANGLE
-fails.
-
-This patch replaces the git-based commit ID generation with a dummy ID.
-
-Upstream-Status: Pending
-
-Signed-off-by: Carlos Rafael Giani
- third_party/angle/src/angle.gypi | 2 +-
- third_party/angle/src/commit_id.py | 22 +-
- 2 files changed, 14 insertions(+), 10 deletions(-)
-
-diff --git a/third_party/angle/src/angle.gypi
b/third_party/angle/src/angle.gypi
-index 5339369..c7ef8c1 100644
a/third_party/angle/src/angle.gypi
-+++ b/third_party/angle/src/angle.gypi
-@@ -56,7 +56,7 @@
- {
- 'action_name': 'Generate Commit ID Header',
- 'message': 'Generating commit ID header...',
--'inputs': [
'<(SHARED_INTERMEDIATE_DIR)/commit_id.py', '<(angle_path)/.git/index' ],
-+'inputs': [
'<(SHARED_INTERMEDIATE_DIR)/commit_id.py' ],
- 'outputs': [
'<(SHARED_INTERMEDIATE_DIR)/commit.h' ],
- 'action': [ 'python',
'<(SHARED_INTERMEDIATE_DIR)/commit_id.py',
'<(SHARED_INTERMEDIATE_DIR)/commit.h' ],
- },
-diff --git a/third_party/angle/src/commit_id.py
b/third_party/angle/src/commit_id.py
-index 6339cca..1a3c0a3 100644
a/third_party/angle/src/commit_id.py
-+++ b/third_party/angle/src/commit_id.py
-@@ -1,17 +1,21 @@
- import subprocess as sp
- import sys
-
--def grab_output(*command):
--return sp.Popen(command, stdout=sp.PIPE).communicate()[0].strip()
-+#def grab_output(*command):
-+#return sp.Popen(command, stdout=sp.PIPE).communicate()[0].strip()
-+#
-+#commit_id_size = 12
-+#
-+#try:
-+#commit_id = grab_output('git', 'rev-parse', '--short=%d' %
commit_id_size, 'HEAD')
-+#commit_date = grab_output('git', 'show', '-s', '--format=%ci', 'HEAD')
-+#except:
-+#commit_id = 'invalid-hash'
-+#commit_date = 'invalid-date'
-
-+commit_id = "0123456789ab"
- commit_id_size = 12
--
--try:
--commit_id = grab_output('git', 'rev-parse', '--short=%d' %
commit_id_size, 'HEAD')
--commit_date = grab_output('git', 'show', '-s', '--format=%ci', 'HEAD')
--except:
--commit_id = 'invalid-hash'
--commit_date = 'invalid-date'
-+commit_date = "2014-06-11 17:45:12 +0200"
-
- hfile = open(sys.argv[1], 'w')
-
---
-1.8.3.2
-
diff --git
a/recipes-browser/chromium/chromium/001-atk_focus_tracker_notify_deprecated_since_ATK_2_9_4.patch
b/recipes-browser/chromium/chromium/001-atk_focus_tracker_notify_deprecated_since_ATK_2_9_4.patch
deleted file mode 100644
index a44abff..000
---
a/recipes-browser/chromium/chromium/001-atk_focus_tracker_notify_deprecated_since_ATK_2_9_4.patch
+++ /dev/null
@@ -1,17 +0,0 @@
a/content/browser/accessibility/browser_accessibility_manager_gtk.cc
2013-05-26 00:43:54.0 +0200
-+++ b/content/browser/accessibility/browser_accessibility_manager_gtk.cc
2013-12-14 15:45:44.251138663 +0100
-@@ -55,11 +55,9 @@
- RecursivelySendChildrenChanged(GetRoot()->ToBrowserAccessibilityGtk());
- break;
-
Re: [oe] Style issue for recipes
On 5 September 2014 14:58, Mike Looijmans wrote: > Why not take it one step further and remove the version from the bb > filename? Only use the "versioned" filename if there actually is more than > one version. I wonder what happens if there are multiple layers in place that all have a foo.bb with different PVs set inside them. Do they overlay as they share the same name, or correctly as if the version was in the filename? Ross -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-ruby][0/1] introduce a class to assist in building gems
For a while now we have had functionality in meta-cloud-services in Yocto to assist in building Ruby gems in to the rootfs images. Many of these gems and the ruby.bbclass that was written to facilitate the building of gems are not specific to our work in meta-cloud-services and should be made more widely available by moving them to meta-ruby. So this is my first attempt to get things moved and in doing so make the meta-ruby layer more comprehensive. We have used this ruby.bbclass in meta-cloud-services to build about 25 gems and in doing so we have worked out a number of issues and have been successful in adding new gem recipes easily. Although at this time focus has been on x86 and x86-64 so we have not yet attempting any cross ARCH cross compiling. Since there are many parallels between Ruby and Python we expect that when we do start to cross-compile we will run into similar issues and don't anticipate major obstacles. For now I have included a recipe for single gem, bundler. Including this gem in your image will demonstrate that the class is able to perform as advertised and examining bundler on the target we can confirm the validity of the build: -- root@qemux86-64:~# cat Gemfile source 'https://rubygems.org' gem 'rspec', :require => 'spec' root@qemux86-64:~# bundle install Don't run Bundler as root. Bundler can ask for sudo if it is needed, and installing your bundle as root will break this application for all non-root users on this machine. Fetching gem metadata from https://rubygems.org/. Resolving dependencies... Using diff-lcs 1.2.5 Installing rspec-support 3.1.0 Installing rspec-core 3.1.0 Installing rspec-expectations 3.1.0 Installing rspec-mocks 3.1.0 Installing rspec 3.1.0 Using bundler 1.6.2 Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed. root@qemux86-64:~# bundle show Gems included by the bundle: * bundler (1.6.2) * diff-lcs (1.2.5) * rspec (3.1.0) * rspec-core (3.1.0) * rspec-expectations (3.1.0) * rspec-mocks (3.1.0) * rspec-support (3.1.0) -- Once ruby.bbclass is accepted in to meta-ruby I will submit additional reviews to copy more of our gem recipes from meta-cloud-services. I look forward to hearing feedback and hope that I can get things to a point where we can get this merged. Regards, Mark -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
[oe] [meta-ruby][PATCH] ruby.bbclass: introduce a class to assist in building gems
In order to allow the building of gems we have created a
ruby.bbclass. The building of gems is much like the building of python
packages in that we rely on building up -native gems in order to
facilitate the cross compiling of the gems that will be built for the
target. When dependencies exist between gems they must be satisfied by
the -native gems installed in the host sysroot. This approach is
feasible since the build process is able to query installed gems
without being affected by the ARCH they were built for. At this point
I have yet to come across a situation where the assumption associated
with this approach have failed but so far focus has only been on x86
and x86-64 builds.
The recipes which inherit the ruby.bbclass can optionally define a BPV
in the case where the gemspec version doesn't always map 1:1 to the
PV. This situation has only been encountered on a few occasions so
the class has been made to default BPV to PV.
To demonstrate the ruby.bbclass in use we have included a recipe to
build the bundler gem. Bundler can be used on a running target to
install gems from rubygems.org, which can be useful in itself when you
don't have recipes available for gems but want to try installing and
running pre-built gems.
Signed-off-by: Mark Asselstine
---
meta-ruby/classes/ruby.bbclass | 125 +
meta-ruby/recipes-devtools/ruby/bundler_git.bb | 29 ++
2 files changed, 154 insertions(+)
create mode 100644 meta-ruby/classes/ruby.bbclass
create mode 100644 meta-ruby/recipes-devtools/ruby/bundler_git.bb
diff --git a/meta-ruby/classes/ruby.bbclass b/meta-ruby/classes/ruby.bbclass
new file mode 100644
index 000..9c4fcf9
--- /dev/null
+++ b/meta-ruby/classes/ruby.bbclass
@@ -0,0 +1,125 @@
+BPV ?= "${PV}"
+
+DEPENDS += " \
+ruby-native \
+"
+RDEPENDS_${PN} += " \
+ruby \
+"
+
+def get_rubyversion(p):
+import re
+from os.path import isfile
+import subprocess
+found_version = "SOMETHING FAILED!"
+
+cmd = "%s/ruby" % p
+
+if not isfile(cmd):
+ return found_version
+
+version = subprocess.Popen([cmd, "--version"],
stdout=subprocess.PIPE).communicate()[0]
+
+r = re.compile("ruby ([0-9]+\.[0-9]+\.[0-9]+)*")
+m = r.match(version)
+if m:
+found_version = m.group(1)
+
+return found_version
+
+def get_rubygemslocation(p):
+import re
+from os.path import isfile
+import subprocess
+found_loc = "SOMETHING FAILED!"
+
+cmd = "%s/gem" % p
+
+if not isfile(cmd):
+ return found_loc
+
+loc = subprocess.Popen([cmd, "env"],
stdout=subprocess.PIPE).communicate()[0]
+
+r = re.compile(".*\- (/usr.*/ruby/gems/.*)")
+for line in loc.split('\n'):
+m = r.match(line)
+if m:
+found_loc = m.group(1)
+break
+
+return found_loc
+
+def get_rubygemsversion(p):
+import re
+from os.path import isfile
+import subprocess
+found_version = "SOMETHING FAILED!"
+
+cmd = "%s/gem" % p
+
+if not isfile(cmd):
+ return found_version
+
+version = subprocess.Popen([cmd, "env", "gemdir"],
stdout=subprocess.PIPE).communicate()[0]
+
+r = re.compile(".*([0-9]+\.[0-9]+\.[0-9]+)$")
+m = r.match(version)
+if m:
+found_version = m.group(1)
+
+return found_version
+
+RUBY_VERSION ?= "${@get_rubyversion("${STAGING_BINDIR_NATIVE}")}"
+RUBY_GEM_DIRECTORY ?= "${@get_rubygemslocation("${STAGING_BINDIR_NATIVE}")}"
+RUBY_GEM_VERSION ?= "${@get_rubygemsversion("${STAGING_BINDIR_NATIVE}")}"
+
+export GEM_HOME = "${STAGING_DIR_NATIVE}/usr/lib/ruby/gems/${RUBY_GEM_VERSION}"
+
+RUBY_BUILD_GEMS ?= "${BPN}.gemspec"
+RUBY_INSTALL_GEMS ?= "${BPN}-${BPV}.gem"
+
+RUBY_COMPILE_FLAGS ?= 'LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8"'
+
+ruby_do_compile() {
+ for gem in ${RUBY_BUILD_GEMS}; do
+ ${RUBY_COMPILE_FLAGS} gem build $gem
+ done
+}
+
+
+ruby_do_install() {
+ for gem in ${RUBY_INSTALL_GEMS}; do
+ gem install --ignore-dependencies --local --env-shebang
--install-dir ${D}/${libdir}/ruby/gems/${RUBY_GEM_VERSION}/ $gem
+ done
+
+ # create symlink from the gems bin directory to /usr/bin
+ for i in ${D}/${libdir}/ruby/gems/${RUBY_GEM_VERSION}/bin/*; do
+ if [ -e "$i" ]; then
+ if [ ! -d ${D}/${bindir} ]; then mkdir -p
${D}/${bindir}; fi
+ b=`basename $i`
+ ln -sf ${libdir}/ruby/gems/${RUBY_GEM_VERSION}/bin/$b
${D}/${bindir}/$b
+ fi
+ done
+}
+
+EXPORT_FUNCTIONS do_compile do_install
+
+PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev"
+
+FILES_${PN}-dbg += " \
+${libdir}/ruby/gems/${RUBY_GEM_VERSION}/gems/*/*/.debug \
+${libdir}/ruby/gems/${RUBY_GEM_VERSION}/gems/*/*/*/.debug \
+${libdir}/ruby/gems/${RUBY_GEM_VERSION}/gems/*/*/*/*/.debug \
+${libdir}/ruby/gems/${RUBY_GEM_VERSION}/gems/*/*/*/*/*/.debug \
+"
+
+FILES_${PN} +
Re: [oe] Style issue for recipes
On 09/04/2014 07:29 PM, Andreas Müller wrote: On Thu, Sep 4, 2014 at 6:34 PM, Burton, Ross wrote: On 4 September 2014 15:12, Burton, Ross wrote: Quick question of style for the community to bikeshed on: in the general case should recipes be split into foo_1.2.bb and foo.inc, or should they only split to bb/inc if there are multiple versions and generally there should just be foo_1.2.bb. Another argument against widespread inc files: they encourage the impression that maintaining multiple versions is just a matter of having a .inc file. The moment you start having to put version-specific statements into a .bb you've entered a world of pain in keeping the .bb files in sync, moving options into the .inc as they become used by all versions, and purging old version-specific statements. Ross -- I agree with Ross: It often took me time to find out where functionality comes from. Inc-files do only make sense for multiple versions of recipes or if different recipes share same code (only example I can remember is meta-gnome gvfs/gvfs-gdu-volume-monitor circular-dependency hack). My feeling is that the inc-files are still from classic oe times where we had multiple versions for many recipes and most can be merged into recipes without loosing something. Why not take it one step further and remove the version from the bb filename? Only use the "versioned" filename if there actually is more than one version. I'd propose that the recipe for package "foo" is always called "foo.bb". A "PV" setting in that file can provide the information that bitbake needs. If there's an alternative, but not mainstream or recommended version for that package, it can be named "foo_1.1.bb". That way, you can see in a glance what recipe is the default one and which are the "extras". I guess for 99% of the recipes, there's only one version. It's much easier to track it if the filename remains constant. Yes, I know about git's fancy features, but... What about the mighty simple usecase of just being able to search for "foo.bb" using your favorite search engine and then actually finding it in a public overlay repository on the web? For example, you will be able to find a recipe for libdvdcss by simply hunting for "libdvdcss.bb", but you'll have a hard time finding the hamsterdb recipe because it happens to be named "hamsterdb_git.bb" in that same repository. -- Mike Looijmans -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Error while bitbake meta-toolchain-qt5
On Fri, Sep 5, 2014 at 8:08 AM, Switesh Fulpagare wrote: > Hi Otavio, >Thanks for your reply. > I have applied the patch, now it is fetching qtwayland_git.bb but it is > giving error for do unpack as shown in below link and > qtwayland-native_git.bb is not going to fetch. > > > http://pastebin.com/dk2gFin0 My bet is that your local.conf, DL_DIR, is pointing to a path with / at end, fix it. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Error while bitbake meta-toolchain-qt5
Hi Otavio, Thanks for your reply. I have applied the patch, now it is fetching qtwayland_git.bb but it is giving error for do unpack as shown in below link and qtwayland-native_git.bb is not going to fetch. http://pastebin.com/dk2gFin0 On Fri, Sep 5, 2014 at 3:40 PM, Switesh Fulpagare < switesh.fulpag...@mindastoneridge.com> wrote: > Hi Otavio, >Thanks for your reply. > I have applied the patch, now it is fetching qtwayland_git.bb but it is > giving error as shown log file in below link. > > http://pastebin.com/mzqsp6Nh > > > On Fri, Sep 5, 2014 at 12:06 AM, Otavio Salvador > wrote: > >> On Thu, Sep 4, 2014 at 4:10 AM, Switesh Fulpagare >> wrote: >> > Can you please look at this post? I think it is problem with 'git:// >> > qt.gitorious.org/qt/qtwayland.git >> >> I just sent a patch fixing it; please try it. >> >> -- >> Otavio Salvador O.S. Systems >> http://www.ossystems.com.brhttp://code.ossystems.com.br >> Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 >> -- >> ___ >> Openembedded-devel mailing list >> Openembedded-devel@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel >> > > -- “The contents of this e-mail message and any attachments are confidential and are intended solely for addressee. The information may also be legally privileged. This transmission is sent in trust, for the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail or phone and delete this message and its attachments, if any.” -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Error while bitbake meta-toolchain-qt5
Hi Otavio, Thanks for your reply. I have applied the patch, now it is fetching qtwayland_git.bb but it is giving error as shown log file in below link. http://pastebin.com/mzqsp6Nh On Fri, Sep 5, 2014 at 12:06 AM, Otavio Salvador wrote: > On Thu, Sep 4, 2014 at 4:10 AM, Switesh Fulpagare > wrote: > > Can you please look at this post? I think it is problem with 'git:// > > qt.gitorious.org/qt/qtwayland.git > > I just sent a patch fixing it; please try it. > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.brhttp://code.ossystems.com.br > Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 > -- > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > -- “The contents of this e-mail message and any attachments are confidential and are intended solely for addressee. The information may also be legally privileged. This transmission is sent in trust, for the sole purpose of delivery to the intended recipient. If you have received this transmission in error, any use, reproduction or dissemination of this transmission is strictly prohibited. If you are not the intended recipient, please immediately notify the sender by reply e-mail or phone and delete this message and its attachments, if any.” -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Style issue for recipes
On Thursday 04 September 2014 15:12:02 Burton, Ross wrote: > Quick question of style for the community to bikeshed on: in the > general case should recipes be split into foo_1.2.bb and foo.inc, or > should they only split to bb/inc if there are multiple versions and > generally there should just be foo_1.2.bb. > > Specifically I'm looking at the libunwind patch for oe-core (moving > from meta-oe) which adds libunwind_1.1.bb and libunwind.inc. > Personally I feel that splitting them up complicates packaging and > should only be done if there's actually multiple versions being used. I think the conclusion we've come to is let's not have inc files just for the sake of having them; if we need to add them to share common functionality we will, but as time goes on it may be appropriate to factor some of them out. (Having said that I think it would cause more harm than good to go on a huge spree and merge a load of them away, at least at this point.) Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
