Re: [yocto] Kernel module not installed in rootfs
On Tuesday 02 June 2015 19:58:50 Vuille, Martin wrote: > Yocto 1.6.1 > > I have added a module to my kernel. > > The module is getting built, I see a kernel-module-blah-blah RPM > and it contains the .ko > > I add kernel-module-blah-blah to one of the packagegroups > contained in my image, I see do_rootfs task run, but the module > is not in the image. In log.do_rootfs I see that the module is NOT > one of the packages installed. > > I did a cleansstate on the image and the packagegroup, I did a > cleanall on virtual/kernel, makes no difference. > > If I do a "clean build" from scratch, then the module is installed. > > Any thoughts on what I'm missing here? Something is definitely strange here. If you cleansstate and rebuild the packagegroup *after* building the kernel with the module in it, does that make a difference? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Smart package manager problems
Hi Alex, On Tuesday 02 June 2015 15:50:20 Alexandru Vaduva wrote: > I experiences a problem related to smart package manager that I wanted to > discuss with you. I was interested in your feedback, knowledge of this and > maybe advices on how should we proceed further. > > The bug I experienced can be duplicated with the information available in > the "patch-info.txt" file attached to this email. I also attached the log > of the error for easier read in the "image-build-info.txt" file. > > After some careful investigation I discovered that the problem is caused by > the smart package manager, after the install_complementary function call > when it in fact tries to call smart with "install --attempt -y" arguments. > It is not able to see the fact that those packages were already installed > and tries to do it again. This error behavior might also be related to the > problems mentioned here: > https://www.mail-archive.com/yocto@yoctoproject.org/msg24279.html > and https://bugs.launchpad.net/smart/+bug/1238492 Would you mind filing a bug in the Yocto Project bugzilla to cover this? I think the likely solution will be just to whitelist the warnings. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Smart package manager problems
Thanks Paul, I will do that, but the smart package manager cannot be used as a rootfs package. The fact that is does not correctly identify which of the dependencies are already installed could cause further problems. Alex -Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: Wednesday, June 03, 2015 10:46 AM To: Alexandru Vaduva Cc: yocto@yoctoproject.org Subject: Re: [yocto] Smart package manager problems Hi Alex, On Tuesday 02 June 2015 15:50:20 Alexandru Vaduva wrote: > I experiences a problem related to smart package manager that I wanted > to discuss with you. I was interested in your feedback, knowledge of > this and maybe advices on how should we proceed further. > > The bug I experienced can be duplicated with the information available > in the "patch-info.txt" file attached to this email. I also attached > the log of the error for easier read in the "image-build-info.txt" file. > > After some careful investigation I discovered that the problem is > caused by the smart package manager, after the install_complementary > function call when it in fact tries to call smart with "install --attempt -y" > arguments. > It is not able to see the fact that those packages were already > installed and tries to do it again. This error behavior might also be > related to the problems mentioned here: > https://www.mail-archive.com/yocto@yoctoproject.org/msg24279.html > and https://bugs.launchpad.net/smart/+bug/1238492 Would you mind filing a bug in the Yocto Project bugzilla to cover this? I think the likely solution will be just to whitelist the warnings. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Smart package manager problems
I think you may be overstating the issue - I'm convinced the warnings are harmless. As I said before, it's likely these warnings have been present for a long time, the only recent change is we are now exposing them - the quickest fix would be to stop doing that. However, if you'd like to dig into the smart code and fix the underlying issue, you're more than welcome. Cheers, Paul On Wednesday 03 June 2015 08:42:13 Alexandru Vaduva wrote: > Thanks Paul, > > I will do that, but the smart package manager cannot be used as a rootfs > package. The fact that is does not correctly identify which of the > dependencies are already installed could cause further problems. > > > Alex > > -Original Message- > From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] > Sent: Wednesday, June 03, 2015 10:46 AM > To: Alexandru Vaduva > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] Smart package manager problems > > Hi Alex, > > On Tuesday 02 June 2015 15:50:20 Alexandru Vaduva wrote: > > I experiences a problem related to smart package manager that I wanted > > to discuss with you. I was interested in your feedback, knowledge of > > this and maybe advices on how should we proceed further. > > > > The bug I experienced can be duplicated with the information available > > in the "patch-info.txt" file attached to this email. I also attached > > the log of the error for easier read in the "image-build-info.txt" file. > > > > After some careful investigation I discovered that the problem is > > caused by the smart package manager, after the install_complementary > > function call when it in fact tries to call smart with "install --attempt > > -y" arguments. It is not able to see the fact that those packages were > > already > > installed and tries to do it again. This error behavior might also be > > related to the problems mentioned here: > > https://www.mail-archive.com/yocto@yoctoproject.org/msg24279.html > > and https://bugs.launchpad.net/smart/+bug/1238492 > > Would you mind filing a bug in the Yocto Project bugzilla to cover this? I > think the likely solution will be just to whitelist the warnings. > > Cheers, > Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Python Error in SDK
Hi Erik,
I'm really not sure what to advise, other than debugging it by checking
variable values with bitbake -e, adding print/bb.warn statements at various
points, etc.
Sorry, this message was sitting in my inbox for some time - I don't suppose
you have found anything since April?
Cheers,
Paul
On Wednesday 08 April 2015 17:39:52 Erik Bolton wrote:
> Hey Paul:
>
> Thanks very much for the help.
>
> I already have a meta-toolchain.bbappend in our project so I added
> nativesdk-python-modules to the TOOLCHAIN_HOST_TASK append line in there.
>
> The system doesn't seem to detect the change, though. If I "bitbake
> meta-toolchain" no tasks are performed. If I "bitbake meta-toolchain -c
> cleanall" and rebuild it just repackages the toolchain...no new packages
> are added and there's no nativesdk-python-modules dir in the work dir for
> the SDK.
>
> This is really odd, because I added some jibberish to meta-toolchain.append
> and tried again. It fails with a parsing error on the lines I added, so I
> know the file is being re-parsed.
>
> Any thoughts?
>
> Thanks again.
> -Erik
>
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: Wednesday, April 08, 2015 9:22 AM
> To: Erik Bolton
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Python Error in SDK
>
> Hi Erik,
>
> On Tuesday 07 April 2015 06:44:01 Erik Bolton wrote:
> > This has been brought up before (although I think the error was
> > different), but I'm having a lot of issues with the version of Python
> > included with the SDK.
> >
> > We use Python for code generation as part of our project. If I source
> > the environment script and try to run our Python scripts I get this:
> >
> > Traceback (most recent call last):
> > File
> >
> > "/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/lib/python2.7/site.
> > py",
> > line 569, in main()
> >
> > File
> >
> > "/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/lib/python2.7/site.
> > py", line 551, in main known_paths = addusersitepackages(known_paths)
> >
> > File
> >
> > "/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/lib/python2.7/site.
> > py", line 278, in addusersitepackages user_site =
> > getusersitepackages()
> >
> > File
> >
> > "/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/lib/python2.7/site.
> > py", line 253, in getusersitepackages user_base = getuserbase() # this
> > will also set USER_BASE
> >
> > File
> >
> > "/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/lib/python2.7/site.
> > py", line 242, in getuserbase from sysconfig import get_config_var
> >
> > File
> >
> > "/opt/poky/1.7.1/sysroots/x86_64-pokysdk-linux/usr/lib/python2.7/sysconfig
> > .
> > py", line 10, in 'stdlib':
> > '{base}/'+sys.lib+'/python{py_version_short}',
> > AttributeError: 'module' object has no attribute 'lib'
> >
> > If I try running something that doesn't exist I get this:
> >
> > Fatal Python error: Py_Initialize: Unable to get the locale encoding
> > ImportError: No module named 'encodings'
> > Aborted (core dumped)
> >
> > I've tried using update-alternatives to point the SDK python to my
> > local python (Ubuntu 14.10, Python 2.7.8), but the errors persist.
> >
> > I know a few people have simply deleted the python binary from the
> > SDK, but I don't think that will help in my case.
> >
> > I would try to remove it from the SDK in the actual package groups,
> > but smartpm and a few other programs depend on it. I'm not sure they
> > would play nice with my local version.
> >
> > Any suggestions on how to fix this "correctly"?
>
> Basically when python (technically, "nativesdk-python" when talking about
> the SDK) gets pulled in, that's the minimal python core and not all of the
> modules in the normal Python distribution, resulting in failures such as
> these. You can add those however by adding the following either in your
> image recipe (if using -c populate_sdk) or in your configuration:
>
> TOOLCHAIN_HOST_TASK_append = " nativesdk-python-modules"
>
> Rebuild and re-install the SDK and things should work a bit better after
> that.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> Disclaimer: This message contains information that may be privileged or
> confidential and is the property of AgJunction Inc and its subsidiaries. It
> is intended only for the person to whom it is addressed. If you are not the
> intended recipient, you are not authorized to read, print, retain, copy,
> disseminate, distribute, or use this message or any part thereof. If you
> receive this message in error, please notify the sender immediately and
> delete all copies of this message.
--
Paul Eggleton
Intel Open Source Technology Centre
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Smart package manager problems
Here is the Bugzilla bug link: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7840 -Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: Wednesday, June 03, 2015 11:52 AM To: Alexandru Vaduva Cc: yocto@yoctoproject.org Subject: Re: [yocto] Smart package manager problems I think you may be overstating the issue - I'm convinced the warnings are harmless. As I said before, it's likely these warnings have been present for a long time, the only recent change is we are now exposing them - the quickest fix would be to stop doing that. However, if you'd like to dig into the smart code and fix the underlying issue, you're more than welcome. Cheers, Paul On Wednesday 03 June 2015 08:42:13 Alexandru Vaduva wrote: > Thanks Paul, > > I will do that, but the smart package manager cannot be used as a > rootfs package. The fact that is does not correctly identify which of > the dependencies are already installed could cause further problems. > > > Alex > > -Original Message- > From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] > Sent: Wednesday, June 03, 2015 10:46 AM > To: Alexandru Vaduva > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] Smart package manager problems > > Hi Alex, > > On Tuesday 02 June 2015 15:50:20 Alexandru Vaduva wrote: > > I experiences a problem related to smart package manager that I > > wanted to discuss with you. I was interested in your feedback, > > knowledge of this and maybe advices on how should we proceed further. > > > > The bug I experienced can be duplicated with the information > > available in the "patch-info.txt" file attached to this email. I > > also attached the log of the error for easier read in the > > "image-build-info.txt" file. > > > > After some careful investigation I discovered that the problem is > > caused by the smart package manager, after the install_complementary > > function call when it in fact tries to call smart with "install > > --attempt -y" arguments. It is not able to see the fact that those > > packages were already installed and tries to do it again. This error > > behavior might also be related to the problems mentioned here: > > https://www.mail-archive.com/yocto@yoctoproject.org/msg24279.html > > and https://bugs.launchpad.net/smart/+bug/1238492 > > Would you mind filing a bug in the Yocto Project bugzilla to cover > this? I think the likely solution will be just to whitelist the warnings. > > Cheers, > Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Issue with 8250/16550 UART1 access in raspberrypi (meta-raspberrypi)
Hello, After a long break, I have returned to the Yocto project, and generally very pleased. A lot of progress has been done since I last used the project (two years ago), and now in my opinion everything works very smoothly. I have used yocto to build a custom image for the RaspberryPi Compute Module. Generally everything works ok, however I am experiencing problem with accessing the UART1 port on the raspberryPi. I am using a library called wiringPi to put the appropriate GPIO pins in the correct mode (alt5) for RXD1/TXD1 (pins 32/33). Also I have used menuconfig to enable the 8250/16550 serial port support in the kernel (3.18.5+). After booting the image I examined the dmesg output, and it shows following information related to 8250/16550: .. [ 1.010958] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 1.013920] serial8250.0: ttyS0 at MMIO 0x20215040 (irq = 29, base_baud = 7812500) is a 8250 . Then I put the pins 32/33 into alternative mode alt5, and try to connect to the port /dev/ttyS0 using minicom (baud 115200). Trying to enter something into the Mincom terminal does not give any indications on our connected oscilloscope (connected to the relevant pins), however change of the alt mode earlier was observed correctly. The serial port should not be using any flow control, but when trying to disable the flow control using Minicom (it was on by default) freezes the complete RaspberryPi system (requiring to disconnect and reconnect power). Does anyone have any thoughts what could be the cause of these issues (e.g., problems with driver etc)? Any information would be greatly appreciated. In the project we are working on we would need to use both uart ports (0/1) provided by the compute module (the uart0 is a pl011 and by disabling console use of /dev/ttyAMA0 we were able to successfully connect to that port). Thanks for the great work with the Yocto platform. Sincerely, Andreas Enbacka SW designer Gasera Ltd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2] [layerindex-web] Support for recipe inherits field v2
Modified: models.py, update.py, recipes.html, detail.html,
recipedetail.html, additional.css
To identify image recipes and provide inheritance data for recipes, an
inherits field was added to the recipe model, and then populated using
refactored data from __inherit_cache. Finally the field was also added
to Toaster templates, along with style changes proposed in attachment.
Inherits field skips recipes from globally inherited data as proposed.
[YOCTO #7575]
Signed-off-by: Alex Franco
---
layerindex/models.py | 2 +-
layerindex/static/css/additional.css | 11 ++-
layerindex/update.py | 4
templates/layerindex/detail.html | 4 +++-
templates/layerindex/recipedetail.html | 4
templates/layerindex/recipes.html | 4 +++-
6 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/layerindex/models.py b/layerindex/models.py
index dd291a3..c9e9620 100644
--- a/layerindex/models.py
+++ b/layerindex/models.py
@@ -242,7 +242,7 @@ class Recipe(models.Model):
bugtracker = models.URLField(blank=True)
provides = models.CharField(max_length=255, blank=True)
bbclassextend = models.CharField(max_length=100, blank=True)
-
+inherits = models.CharField(max_length=255, blank=True)
updated = models.DateTimeField(auto_now = True)
def vcs_web_url(self):
diff --git a/layerindex/static/css/additional.css
b/layerindex/static/css/additional.css
index 0703257..0d74db3 100644
--- a/layerindex/static/css/additional.css
+++ b/layerindex/static/css/additional.css
@@ -198,4 +198,13 @@ padding: 8px;
.buttonblock-btn {
margin-left: 8px;
-}
\ No newline at end of file
+}
+
+.icon-hdd {
+ margin-left: 2px;
+}
+
+.icon-hdd:hover {
+ cursor: pointer;
+}
+
diff --git a/layerindex/update.py b/layerindex/update.py
index a56507b..4419745 100755
--- a/layerindex/update.py
+++ b/layerindex/update.py
@@ -65,6 +65,10 @@ def update_recipe_file(data, path, recipe, layerdir_start,
repodir):
recipe.bugtracker = envdata.getVar("BUGTRACKER", True) or ""
recipe.provides = envdata.getVar("PROVIDES", True) or ""
recipe.bbclassextend = envdata.getVar("BBCLASSEXTEND", True) or ""
+# Handle recipe inherits for this recipe
+gr = set(data.getVar("__inherit_cache", True) or [])
+lr = set(envdata.getVar("__inherit_cache", True) or [])
+recipe.inherits = ' '.join(sorted({split_recipe_fn(r)[0] for r in lr
if r not in gr}))
recipe.save()
# Get file dependencies within this layer
diff --git a/templates/layerindex/detail.html b/templates/layerindex/detail.html
index e013e4c..c9439b3 100644
--- a/templates/layerindex/detail.html
+++ b/templates/layerindex/detail.html
@@ -198,7 +198,7 @@
{% for recipe in layerbranch.sorted_recipes %}
-{{ recipe.name }}
+{{ recipe.name }}{% if 'image' in recipe.inherits %}{% endif %}
{{ recipe.pv }}
{{ recipe.short_desc
}}
@@ -321,6 +321,8 @@
e.preventDefault();
$(this).tab('show');
})
+
+$('.icon-hdd').tooltip({title:"Inherits image"});
});
});
diff --git a/templates/layerindex/recipedetail.html
b/templates/layerindex/recipedetail.html
index 658694e..cde8e50 100644
--- a/templates/layerindex/recipedetail.html
+++ b/templates/layerindex/recipedetail.html
@@ -83,6 +83,10 @@
Layer
{{
recipe.layerbranch.layer.name }} ({{ recipe.layerbranch.branch.name}}
branch)
+
+Inherits
+{{ recipe.inherits }}
+
diff --git a/templates/layerindex/recipes.html
b/templates/layerindex/recipes.html
index 6777ed2..f1a7834 100644
--- a/templates/layerindex/recipes.html
+++ b/templates/layerindex/recipes.html
@@ -52,7 +52,7 @@
{% for recipe in recipe_list %}
0
%}class="muted"{% endif %}>
-{{
recipe.name }}
+{{
recipe.name }}{% if 'image' in recipe.inherits %}{%
endif %}
{{ recipe.pv }}
{{ recipe.short_desc }}
{{ recipe.layerbranch.layer.name }}
@@ -82,6 +82,8 @@
firstfield = $("#filter-form input:text").first()
if( ! firstfield.val() )
firstfield.focus()
+
+$('.icon-hdd').tooltip({title:"Inherits image"});
});
{% endblock %}
--
2.4.1
--
___
[yocto] [PATCH 2/2] [layerindex-web] Add recipe inherit migration file
New file: 0009_auto__add_field_recipe_inherits.py
Django migration file, to add the inherits column to the recipe table.
[YOCTO #7575]
Signed-off-by: Alex Franco
---
.../0009_auto__add_field_recipe_inherits.py| 196 +
1 file changed, 196 insertions(+)
create mode 100644
layerindex/migrations/0009_auto__add_field_recipe_inherits.py
diff --git a/layerindex/migrations/0009_auto__add_field_recipe_inherits.py
b/layerindex/migrations/0009_auto__add_field_recipe_inherits.py
new file mode 100644
index 000..dd0490c
--- /dev/null
+++ b/layerindex/migrations/0009_auto__add_field_recipe_inherits.py
@@ -0,0 +1,196 @@
+# -*- coding: utf-8 -*-
+from south.utils import datetime_utils as datetime
+from south.db import db
+from south.v2 import SchemaMigration
+from django.db import models
+
+
+class Migration(SchemaMigration):
+
+def forwards(self, orm):
+# Adding field 'Recipe.inherits'
+db.add_column('layerindex_recipe', 'inherits',
+ self.gf('django.db.models.fields.CharField')(default='',
max_length=255, blank=True),
+ keep_default=False)
+
+
+def backwards(self, orm):
+# Deleting field 'Recipe.inherits'
+db.delete_column('layerindex_recipe', 'inherits')
+
+
+models = {
+'auth.group': {
+'Meta': {'object_name': 'Group'},
+'id': ('django.db.models.fields.AutoField', [], {'primary_key':
'True'}),
+'name': ('django.db.models.fields.CharField', [], {'unique':
'True', 'max_length': '80'}),
+'permissions': ('django.db.models.fields.related.ManyToManyField',
[], {'to': "orm['auth.Permission']", 'symmetrical': 'False', 'blank': 'True'})
+},
+'auth.permission': {
+'Meta': {'ordering': "('content_type__app_label',
'content_type__model', 'codename')", 'unique_together': "(('content_type',
'codename'),)", 'object_name': 'Permission'},
+'codename': ('django.db.models.fields.CharField', [],
{'max_length': '100'}),
+'content_type': ('django.db.models.fields.related.ForeignKey', [],
{'to': "orm['contenttypes.ContentType']"}),
+'id': ('django.db.models.fields.AutoField', [], {'primary_key':
'True'}),
+'name': ('django.db.models.fields.CharField', [], {'max_length':
'50'})
+},
+'auth.user': {
+'Meta': {'object_name': 'User'},
+'date_joined': ('django.db.models.fields.DateTimeField', [],
{'default': 'datetime.datetime.now'}),
+'email': ('django.db.models.fields.EmailField', [], {'max_length':
'75', 'blank': 'True'}),
+'first_name': ('django.db.models.fields.CharField', [],
{'max_length': '30', 'blank': 'True'}),
+'groups': ('django.db.models.fields.related.ManyToManyField', [],
{'to': "orm['auth.Group']", 'symmetrical': 'False', 'blank': 'True'}),
+'id': ('django.db.models.fields.AutoField', [], {'primary_key':
'True'}),
+'is_active': ('django.db.models.fields.BooleanField', [],
{'default': 'True'}),
+'is_staff': ('django.db.models.fields.BooleanField', [],
{'default': 'False'}),
+'is_superuser': ('django.db.models.fields.BooleanField', [],
{'default': 'False'}),
+'last_login': ('django.db.models.fields.DateTimeField', [],
{'default': 'datetime.datetime.now'}),
+'last_name': ('django.db.models.fields.CharField', [],
{'max_length': '30', 'blank': 'True'}),
+'password': ('django.db.models.fields.CharField', [],
{'max_length': '128'}),
+'user_permissions':
('django.db.models.fields.related.ManyToManyField', [], {'to':
"orm['auth.Permission']", 'symmetrical': 'False', 'blank': 'True'}),
+'username': ('django.db.models.fields.CharField', [], {'unique':
'True', 'max_length': '30'})
+},
+'contenttypes.contenttype': {
+'Meta': {'ordering': "('name',)", 'unique_together':
"(('app_label', 'model'),)", 'object_name': 'ContentType', 'db_table':
"'django_content_type'"},
+'app_label': ('django.db.models.fields.CharField', [],
{'max_length': '100'}),
+'id': ('django.db.models.fields.AutoField', [], {'primary_key':
'True'}),
+'model': ('django.db.models.fields.CharField', [], {'max_length':
'100'}),
+'name': ('django.db.models.fields.CharField', [], {'max_length':
'100'})
+},
+'layerindex.bbappend': {
+'Meta': {'object_name': 'BBAppend'},
+'filename': ('django.db.models.fields.CharField', [],
{'max_length': '255'}),
+'filepath': ('django.db.models.fields.CharField', [],
{'max_length': '255', 'blank': 'True'}),
+'id': ('django.db.models.fields.AutoField', [], {'primary_key':
'True'}),
+'layerbranch': ('django.db.models.fields.related.ForeignKey', [],
{'to': "orm['layerindex.LayerBranch']"})
+},
+'layerindex.bbclass': {
+
Re: [yocto] Kernel module not installed in rootfs
> -Original Message- > From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] > Sent: June 03, 2015 3:42 AM > > On Tuesday 02 June 2015 19:58:50 Vuille, Martin wrote: > > Yocto 1.6.1 > > > > I have added a module to my kernel. > > > > The module is getting built, I see a kernel-module-blah-blah RPM and > > it contains the .ko > > > > I add kernel-module-blah-blah to one of the packagegroups contained in > > my image, I see do_rootfs task run, but the module is not in the > > image. In log.do_rootfs I see that the module is NOT one of the > > packages installed. > > > > I did a cleansstate on the image and the packagegroup, I did a > > cleanall on virtual/kernel, makes no difference. > > > > If I do a "clean build" from scratch, then the module is installed. > > > > Any thoughts on what I'm missing here? > > Something is definitely strange here. > > If you cleansstate and rebuild the packagegroup *after* building the kernel > with the module in it, does that make a difference? > Hi Paul, Overnight I deleted build/tmp and build/sstate-cache from my workspace and rebuilt everything. Then this morning I added the module to the packagegroup and rebuilt the image. This time the .ko did show up in the rootfs. So it seems there was some sort of gremlin lurking and now it's gone. I hope for good. Thanks for your help MV -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] layerindex
Hi, Does the layer index provide a REST api? -or- Would (could) it be possible to somehow grab/access the data that drives the layer index (preferably without scraping)? Best regards, Trevor -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Library not getting installed to intended path
Hi,
I am using yocto 1.6 and I have written a component and written bitbake
recipe file for this component. When rootfs is created my library is found
in "/lib" directory but I want it to be installed to "/lib/gstreamer-0.10"
directory (which is already created by open source gstreamer packages).
Following is the content of my bb file:
DESCRIPTION = "Plugin for support in GStreamer"
LICENSE = "BSD | LGPLv2.1"
LIC_FILES_CHKSUM = "file://COPYING;md5=7e2d09b34a9cdf39567252d39ce57cca"
DEPENDS = "virtual/libc \
system-utils \
gstreamer \
gst-plugins-base \
"
PR = "r0"
TD_PKG_REPO = "td-gst-plugin"
inherit autotools td_package td_paths
library is installed to /lib/gstreamer-0.10 if I add this line to
Makefile.am
libdir = /lib/gstreamer-0.10
and these to bb file
FILES_${PN} += "/lib/gstreamer-0.10"
FILES_${PN}-dbg += "/lib/gstreamer-0.10/.debug"
INSANE_SKIP_${PN} += "dev-so
Is this correct to use INSANE_SKIP or is it not recommended?
Should I consider not to inherit autotools? I have seen a lot of packages
doing that. In this case whatever path I assign here in FILES variable , my
library is installed to that path but with autotools I have to use
INSANE_SKIP option.
Thanks,
Yogesh
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] layerindex
On Thu, Jun 4, 2015 at 8:34 AM, Trevor Woerner wrote: > Hi, > > Does the layer index provide a REST api? http://layers.openembedded.org/layerindex/api/ It is self documented to some degree :). > > -or- > > Would (could) it be possible to somehow grab/access the data that drives > the layer index (preferably without scraping)? The "bitbake-layers" tool might also be of interest as accesses this api: http://git.openembedded.org/bitbake/tree/bin/bitbake-layers#n261 Regards, Nathan > > Best regards, > Trevor > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
