[yocto] Remove major version number from package name

[Isak Lichtenstein]

Hi all,

I'm relatively new to yocto and open embedded.

I created a few library packages like libdsp for our DSP libraries.

Now when I list all installable packages for libdsp, I noticed that the main 
package gets the major version number added to its name: libdsp0

# opkg list | grep libdsp
libdsp-dbg - 0.1-r26 - libdsp version 0.1-r26 - Debugging files  Board support 
library for the
libdsp-dev - 0.1-r26 - libdsp version 0.1-r26 - Development files  Board 
support library for the
libdsp-staticdev - 0.1-r26 - libdsp version 0.1-r26 - Development files (Static 
Libraries)  Board
libdsp-test - 0.1-r26 - libdsp version 0.1-r26  Board support library for the
libdsp0 - 0.1-r26 - libdsp version 0.1-r26  Board support library for the

What can I add to my recipe to suppress the automatic addition of the major 
version number to the package name?

Kind regards
Isak Lichtenstein


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Changing default SDK path

[Isak Lichtenstein]

Hi

I'm building an SDK and decided to adapt the default SDK path for each release 
to allow users to have the SDK of multiple releases installed in parallel 
without them changing the path during installation.

According to the Yocto Reference Manual, this can be achieved via the SDKPATH 
variable. Unfortunately changing this variable breaks the generated SDK 
installer.

I'm using Yocto 1.7.1 and generate the SDK with the following command:
MACHINE=my-machine bitbake core-image-myimage  -c populate_sdk 

First of all, when building the SDK from scratch (fresh build directory), the 
generated installer looks complete, but when trying to run it, I get the 
following error:
Enter target directory for SDK (default: /opt/mysdk-v2/): 
You are about to install the SDK to "/ opt/mysdk-v2". Proceed[Y/n]?
Extracting SDK...done
Setting it up...ls: cannot access / opt/mysdk-v2/environment-setup-*: 
No such file or directory

Additionally, if I then decide to change the SDK path and generate it NOT from 
scratch, the SDK installer is much smaller, meaning some packages where build 
for the original SDK path only and therefore not installed, if the path changed.

Finally if I revert to use the default SDK path, but don't build it from 
scratch, the installer works, but the generated file is slightly smaller 
(~100K) than the SDK build from scratch.

Is this a bug or maybe SDKPATH isn't meant to be changed?

Best regards

Isak



-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Create own image type

[Isak Lichtenstein]

Hi all,

I'm trying to create my own image type. I thought that it would be enough to 
create a myImage.bbclass file implementing IMAGE_CMD_myImage and extending 
IMAGE_TYPES += " myImage".

But this isn't working and I didn't find anything in the manual.

It this possible at all ( can't imagine that it isn't) ?

Would appreciate any hint possible.

Best regards

Isak
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Create own image type

[Isak Lichtenstein]

Hi Maxim,

> You are no the right way.
>
> You have to add
> IMAGE_CLASSES += "myImage" 
> somewhere in your conf files. I prefer distro.conf for my own distro, but 
> perhaps you can add it to local.conf as well.

That was the needed clue. Thanks a lot

BR

Isak

> BR,
> Maxim.



>>On Wed, Jun 25, 2014 at 5:04 PM, Isak Lichtenstein 
>> wrote:
>>Hi all,
>> 
>>I’m trying to create my own image type. I thought that it would be enough to 
>>create a myImage.bbclass file implementing IMAGE_CMD_myImage and extending 
>>IMAGE_TYPES += “ myImage”.
>>
>>But this isn’t working and I didn’t find anything in the manual.
>> 
>>It this possible at all ( can’t imagine that it isn’t) ?
>> 
>>Would appreciate any hint possible.
>> 
>>Best regards
>> 
>>Isak


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Create own image type

[Isak Lichtenstein]

Hi Lukas,
 
> Hello,
> 
> I can't directly help you with this, however I recommend taking a look at 
> meta-
> raspberrypi ( https://github.com/djwillis/meta-raspberrypi ) as it adds it's 
> own
> image type "rpi-sdimg".

Thanks for the hint. Was really useful. Managed to generate my image by using 
the "rpi-sdimg" recipe as base.

BR

Isak
> 
> Lukas
> 
> On 25 Jun 2014, at 16:04, Isak Lichtenstein  
> wrote:
> 
> > Hi all,
> >
> > I'm trying to create my own image type. I thought that it would be enough to
> create a myImage.bbclass file implementing IMAGE_CMD_myImage and extending
> IMAGE_TYPES += " myImage".
> >
> > But this isn't working and I didn't find anything in the manual.
> >
> > It this possible at all ( can't imagine that it isn't) ?
> >
> > Would appreciate any hint possible.
> >
> > Best regards
> >
> > Isak
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Bash parser

[Isak Lichtenstein]

Hi all,

I'm creating my own image by implementing IMAGE_CMD_ in my custom 
.bbclass file.

In this method I'm using the bash syntax. But a lot of time the parser doesn't 
manage to parse my file properly. Examples:

TMP="file1 file2"
read -a scripts <<< $tmp
generates
ShellSyntaxError: expecting here-document name, got '<'

Or 

TMP="file1 file2"
scripts=(${TMP})
generate
ShellSyntaxError: LexToken(TOKEN,'${TMP}',0,0)


Other bash commands are parsed properly, but generate an error while executing 
them. Example:
TMP="file1, file2"
tmp=${TMP//,/ }
generates
Bad substitution
| WARNING: exit code 2 from a shell command.


Does a page exist somewhere describing the bash features supported by the 
parser and also the execution environment? 
Are arrays supported at all?

Best regards

Isak Lichtenstein
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Bash parser

[Isak Lichtenstein]

Hi Olof,

Thank you very much for your prompt answer
> 
> On 14-07-16 11:36 +0200, Isak Lichtenstein wrote:
> > In this method I'm using the bash syntax. But a lot of time the parser
> > doesn't manage to parse my file properly. Examples:
> >
> > TMP="file1 file2"
> > read -a scripts <<< $tmp
> > generates
> > ShellSyntaxError: expecting here-document name, got '<'
> >
> > Or
> >
> > TMP="file1 file2"
> > scripts=(${TMP})
> > generate
> > ShellSyntaxError: LexToken(TOKEN,'${TMP}',0,0)
> >
> >
> > Other bash commands are parsed properly, but generate an error while
> > executing them. Example:
> > TMP="file1, file2"
> > tmp=${TMP//,/ }
> > generates
> > Bad substitution
> > | WARNING: exit code 2 from a shell command.
> 
> Note that these features you describe here are all bash extensions. For Debian
> users (and I think Ubuntu users as well?), the default /bin/sh is dash and 
> does not
> support either of these extensions. There are cases where the bitbake parser 
> will
> refuse valid portable shell script features as well though, like shell 
> arithmetics, e.g.:

Ubuntu default is actually bash.
> 
>  n=$((n+1))
> 
> > Does a page exist somewhere describing the bash features supported by
> > the parser and also the execution environment?
> > Are arrays supported at all?
> 
> I don't know of any such documentation, but if you stick to portable shell 
> script
> features, you should be mostly fine.
> 
Thanks for the advice. Will try to stick to it.

Isak
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to get fw_env.config installed

[Isak Lichtenstein]

 Hi Matt,

> I'm working on including the u-boot fw utility tools in my image, specifically
> fw_printenv and fw_setenv.
> For these to work the file fw_env.config needs to be placed at 
> /etc/fw_env.config.
> 
> I can see in oe-core/meta/recipes-bsp/u-boot/u-boot.inc there is a test that 
> if
> fw_env.config is in the working dir it will be installed in ${sysconfdir} and 
> I can see
> in the meta-ti/recipes-bsp/u-boot/u-boot-beagleboard_2011.09.bb they simply
> include file://fw_env.conf in the SRC_URI list to get the file in the working 
> dir.
> 
> So I created a bbappend file for the ti u-boot recipe 
> (u-boot-ti-staging_2013.10.bb)
> that I'm using and build and I don't get the file in my image root filesystem.
> 
> If I run bitbake -c install virtual/bootloader I can see that the file does 
> get copied
> into u-boot's working dir image/etc directory but it never makes it into the 
> final root
> filesystem.
> 
> What am I missing?

The u-boot.inc file is looking for  a ".config" file, not ".conf".

BR

Isak

> 
> Thanks,
> Matt S.
> 
> PS I should note that I'm working Dylan branch with the TI Arago layer.
> 
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to get fw_env.config installed

[Isak Lichtenstein]

> >
> >> I'm working on including the u-boot fw utility tools in my image,
> >> specifically fw_printenv and fw_setenv.
> >> For these to work the file fw_env.config needs to be placed at
> /etc/fw_env.config.
> >>
> >> I can see in oe-core/meta/recipes-bsp/u-boot/u-boot.inc there is a
> >> test that if fw_env.config is in the working dir it will be installed
> >> in ${sysconfdir} and I can see in the
> >> meta-ti/recipes-bsp/u-boot/u-boot-beagleboard_2011.09.bb they simply 
> >> include
> file://fw_env.conf in the SRC_URI list to get the file in the working dir.
> >>
> >> So I created a bbappend file for the ti u-boot recipe
> >> (u-boot-ti-staging_2013.10.bb) that I'm using and build and I don't get 
> >> the file in
> my image root filesystem.
> >>
> >> If I run bitbake -c install virtual/bootloader I can see that the
> >> file does get copied into u-boot's working dir image/etc directory
> >> but it never makes it into the final root filesystem.
> >>
> >> What am I missing?
> >
> > The u-boot.inc file is looking for  a ".config" file, not ".conf".
> >
> Thanks Isak, I'm aware of that I just miss typed it in that one sentence in 
> my e-mail.
> I got it right everywhere else including my code. Can I ask have you used this
> mechanism and does it work for you?
> 
Sorry to disappoint you. 
As I've got a whole bunch of files to install in /etc, I'm using a custom 
recipe.

Regards

Isak 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Added package to RDEPENDS in packagegroup, image that IMAGE_INSTALLs packagegroup not rebuilt

[Isak Lichtenstein]

Hi Martin,


> -Ursprüngliche Nachricht-
> Von: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
> Im Auftrag von Vuille, Martin (Martin)
> Gesendet: 05 November 2014 17:39
> An: Paul Eggleton
> Cc: yocto@yoctoproject.org
> Betreff: Re: [yocto] Added package to RDEPENDS in packagegroup, image that
> IMAGE_INSTALLs packagegroup not rebuilt
> 
> > -Original Message-
> > From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> > Sent: November 05, 2014 11:04 AM
> >
> > OK, so this kind of explains it. To be perfectly honest the bitbake
> > memory resident functionality (which Toaster uses behind the scenes)
> > does have some holes in picking up changes, but I hadn't realised it
> > would manifest in this particular manner. It seems like at the moment
> > you'd need to stop and restart Toaster to be sure that the change gets 
> > picked
> up.
> >
> 
> - Stopped Toaster
> - Removed the two cache directories
> - bitbake 
> 

I've spent yesterday morning trying to debug a similar problem. I had INHERIT 
+= "rm_work" enabled in my local.conf file, and when removing it, I go the 
following error.:
ERROR: No such task: do_rm_work
ERROR: Task 10 
(/home/user/branches/dev/yocto/meta-libtest/recipes-support/libtest/libtest_1.0.bb,
 do_rm_work) failed with exit code '1'.

bitbake -e libtest | grep INHERIT showed me that rm_work was still around 
despite having removed it from my local.conf .
INHERIT=" rm_work own-mirrors buildhistory toaster poky-sanity 
package_ipk image-mklibs image-prelink debian devshell sstate license blacklist 
sanity toaster buildhistory"


Eventually I worked out that it was because I had Toaster running that the 
changes in local.conf where only partially picked up, and that's what created 
the error.

I'm not sure if this bug is related to the one you're seeing, but in case it 
is, it's definitely easier to reproduce than deleting/renaming the cache 
directories.

BR

Isak 

> is working. It is running do_package on each of the packages in the
> packagegroup.
> 
> Thanks for your time debugging this.
> 
> MV
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How to enforce installation of image specific config file/package

[Isak Lichtenstein]

Hi,

I've got a package "A" that has a runtime dependency to a configuration file. 
This configuration file is image specific. For each image I've got a specific 
configuration package "config-image-X" that installs this needed configuration 
file and I build multiple image in the same build directory.
How can I enforce that each image containing package "A" also installs an image 
specific configuration package? 
I've tried with virtual providers, but then at the second image it always tried 
to install the virtual provider from the first image as well, which leads to 
the following failure during the rootfs task:

check_data_file_clashes: Package config-image-1 wants to install file 
/home/root/build/build_dev/tmp/work/poky-linux-gnueabi/core-image-test/1.0-r0/rootfs/usr/bin/config
But that file is already provided by package  * config-image-2


I'm using yocto jethro.

Best regards

Isak
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to enforce installation of image specific config file/package

[Isak Lichtenstein]

Hi Joël,
> 
> Hi,
> 
> One idea may be to create one recipe per configuration file.
> So in each image recipe, you would add one of those recipes to
> IMAGE_INSTALL_append.

That's exactly what I'm doing now. But as my base package "A" is in a 
layer that is used by other developers, I would like to enforce somehow
that every image containing this package also provides a config package
for it.

BR

Isak
> 
> Interested in other ideas for this use case!
> 
> Joël Esponde
> Honeywell | Sensing and Productivity Solutions
> 
> > -Message d'origine-
> > De : yocto-boun...@yoctoproject.org [mailto:yocto-
> > boun...@yoctoproject.org] De la part de Isak Lichtenstein Envoyé :
> > vendredi 1 avril 2016 11:35 À : yocto@yoctoproject.org Objet : [yocto]
> > How to enforce installation of image specific config file/package
> >
> > Hi,
> >
> > I've got a package "A" that has a runtime dependency to a configuration 
> > file.
> > This configuration file is image specific. For each image I've got a
> > specific configuration package "config-image-X" that installs this
> > needed configuration file and I build multiple image in the same build 
> > directory.
> > How can I enforce that each image containing package "A" also installs
> > an image specific configuration package?
> > I've tried with virtual providers, but then at the second image it
> > always tried to install the virtual provider from the first image as
> > well, which leads to the following failure during the rootfs task:
> >
> > check_data_file_clashes: Package config-image-1 wants to install file
> > /home/root/build/build_dev/tmp/work/poky-linux-gnueabi/core-image-
> > test/1.0-r0/rootfs/usr/bin/config
> > But that file is already provided by package  * config-image-2
> >
> >
> > I'm using yocto jethro.
> >
> > Best regards
> >
> > Isak
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to enforce installation of image specific config file/package

[Isak Lichtenstein]

Hi Raj
> 
> 
> > On Apr 1, 2016, at 5:38 AM, Isak Lichtenstein 
> > 
> wrote:
> >
> > Hi Joël,
> >>
> >> Hi,
> >>
> >> One idea may be to create one recipe per configuration file.
> >> So in each image recipe, you would add one of those recipes to
> >> IMAGE_INSTALL_append.
> >
> > That's exactly what I'm doing now. But as my base package "A" is in a
> > layer that is used by other developers, I would like to enforce
> > somehow that every image containing this package also provides a
> > config package for it.
> 
> you can use bitbake diagnostics in a image post process function to implement
> this logic or in a bbclass which is inherited by every image you build.

Thank you for your suggestion. Will try to solve it as you suggest, but I will 
need
to kneel myself into the bitbake library classes to see what methods they 
provide
to easily implement this bbclass.


> >> > Hi,
> >> > 
> >> > I've got a package "A" that has a runtime dependency to a configuration 
> >> > file.
> >> > This configuration file is image specific. For each image I've got a 
> >> > specific configuration package "config-image-X" that installs this 
> >> > needed configuration file and I build multiple image in the same build 
> >> > directory.
> >> > How can I enforce that each image containing package "A" also installs 
> >> > an image specific configuration package?
> >> > I've tried with virtual providers, but then at the second image it 
> >> > always tried to install the virtual provider from the first image as 
> >> > well, which leads to the following failure during the rootfs task:
> >> > 
> >> > check_data_file_clashes: Package config-image-1 wants to install file
> >> > /home/root/build/build_dev/tmp/work/poky-linux-gnueabi/core-image-
> >> > test/1.0-r0/rootfs/usr/bin/config
> >> >  But that file is already provided by package  * config-image-2

Nevertheless, when I tried using the provider class, I found it's behavior 
a bit weird.

When I have a package build dependency and 2 providers, I expect that 
Yocto pull in/uses the provider with the highest priority.
But if a package has got a run time dependency, and the image containing 
the package also includes already a provider for the package, I would expect 
that the run time dependency is satisfied despite the provider included isn't 
the
one with the highest prio. In reality I found that the image always tried to 
also 
include the highest prio provider.

Is that really the expected behavior?

BR

Isak


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Necessary changes between SDK and eSDK builds

[Isak Lichtenstein]

Hi

I'm using yocto thud 2.6.1 always build & provide sdk's to our customers 
without problem.
Now a customer requested an eSDK instead.

According to the manual 
(https://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html#sdk-building-an-sdk-installer),
 this should work identically by simply using "-c populate_sdk_ext".

Unfortunately the tasks do_populate_sdk_ext fails with the following error 
message:


Exception: FileNotFoundError: [Errno 2] No such file or directory: 
'/home/root/build/dev/tmp/work/myboard-poky-linux-gnueabi/core-image-myboard/1.0-r0/sdk-ext/image//opt/myboard/2.6.1/conf/local.conf.bak'
 -> 
'/home/root/build/dev/tmp/work/myboard-poky-linux-gnueabi/core-image-myboard/1.0-r0/sdk-ext/image//opt/myboard/2.6.1/conf/local.conf'

ERROR: core-image-myboard-1.0-r0 do_populate_sdk_ext: Function failed: 
copy_buildsystem
ERROR: Logfile of failure stored in: 
/home/root/build/dev/tmp/work/myboard-poky-linux-gnueabi/core-image-myboard/1.0-r0/temp/log.do_populate_sdk_ext.17712
ERROR: Task 
(/home/root/yocto/meta-evalboard/recipes-core/images/core-image-myboard.bb:do_populate_sdk_ext)
 failed with exit code '1'

What do I need to change in order to build the extensible SDK?

Best regards
Isak
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Necessary changes between SDK and eSDK builds

[Isak Lichtenstein]

Hi



I’m using yocto thud 2.6.1 and always build & provide sdk’s to our
customers without problem.

Now a customer requested an eSDK instead.



According to the manual (
https://www.yoctoproject.org/docs/2.6/sdk-manual/sdk-manual.html#sdk-building-an-sdk-installer
),
this should work identically by simply using “-c populate_sdk_ext”.



Unfortunately the tasks do_populate_sdk_ext fails with the following error
message:



….

Exception: FileNotFoundError: [Errno 2] No such file or directory:
'/home/root/build/dev/tmp/work/myboard-poky-linux-gnueabi/core-image-myboard/1.0-r0/sdk-ext/image//opt/myboard/2.6.1/conf/local.conf.bak'
->
'/home/root/build/dev/tmp/work/myboard-poky-linux-gnueabi/core-image-myboard/1.0-r0/sdk-ext/image//opt/myboard/2.6.1/conf/local.conf'



ERROR: core-image-myboard-1.0-r0 do_populate_sdk_ext: Function failed:
copy_buildsystem

ERROR: Logfile of failure stored in:
/home/root/build/dev/tmp/work/myboard-poky-linux-gnueabi/core-image-myboard/1.0-r0/temp/log.do_populate_sdk_ext.17712

ERROR: Task
(/home/root/yocto/meta-evalboard/recipes-core/images/core-image-myboard.bb:do_populate_sdk_ext)
failed with exit code '1'



What do I need to change in order to build the extensible SDK?



Best regards

Isak
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto