package/build problems with dropped packages

package/build problems with dropped packages

[Alexander Stohr]

i've sent these lines to bitbake developer mailing list
a few days ago - they responded that its probably not
a problem of bitbake but rather a problem induced by
what represents the build system, e.g. that of open embedded.
over there is just silently agreed. now i am asking here again...

here's my previous posting to those list:


Subject: package/build problems in old bitbake versions - resolved in current version?
Date: Mon, 20 Sep 2010 18:01:06 +0200
Von: Alexander Stohr <Alexander.Stohr@gmx.de>
An: <bitbake-dev@lists.berlios.de>

Hello,

i was working with bitbake for cross building file system images
for an embedded project. in this setup i was updating a bigger
package to a more recent version. for some reasons it created
noticeable fewer packages for me leading to the state that
bitbake simply kept the corresponding result packages from an older
not-really-matching version from a prior build attempt in place.

for the reason of using a probably working pair of tools and recipes
i was doing my tasks using an older version of bitbake (1.8.12).
(surely there is 1.8.18 and 1.10.0 available to me
but i just did not check that versions sufficiently for now.)


my short term work-around was this:
i was manually sending the old packages to the morgue
and then started researching reasons for the changed
package build results. later packages should now be
in state to fault when something is missing instead
of being inadequately served by something older.
the first case is desirable, the later feels buggy.


does someone know how bitbake should behave in cases
where a newer recipe version does no longer produce a
certain package since no files were installed by the build?

does that further mean an ever added results package
must stay in the recipe for an indefinitely long period
even if it will be empty just for forced removal?

if that scenario is already addressed by some patch
then please drop me a note on the current state.

regards, Alex.

-- 
GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 für nur 19,99 Euro/mtl.!*
http://portal.gmx.net/de/go/dsl

Re: package/build problems with dropped packages

[Khem Raj]

On (27/09/10 14:10), Alexander Stohr wrote:
> i've sent these lines to bitbake developer mailing list
> a few days ago - they responded that its probably not
> a problem of bitbake but rather a problem induced by
> what represents the build system, e.g. that of open embedded.
> over there is just silently agreed. now i am asking here again...
> 
> here's my previous posting to those list:
> 
> 
> Subject: package/build problems in old bitbake versions - resolved in current version?
> Date: Mon, 20 Sep 2010 18:01:06 +0200
> Von: Alexander Stohr <Alexander.Stohr@gmx.de>
> An: <bitbake-dev@lists.berlios.de>
> 
> Hello,
> 
> i was working with bitbake for cross building file system images
> for an embedded project. in this setup i was updating a bigger
> package to a more recent version. for some reasons it created
> noticeable fewer packages for me leading to the state that
> bitbake simply kept the corresponding result packages from an older
> not-really-matching version from a prior build attempt in place.
> 
> for the reason of using a probably working pair of tools and recipes
> i was doing my tasks using an older version of bitbake (1.8.12).
> (surely there is 1.8.18 and 1.10.0 available to me
> but i just did not check that versions sufficiently for now.)
> 
> 
> my short term work-around was this:
> i was manually sending the old packages to the morgue
> and then started researching reasons for the changed
> package build results. later packages should now be
> in state to fault when something is missing instead
> of being inadequately served by something older.
> the first case is desirable, the later feels buggy.
> 
> 
> does someone know how bitbake should behave in cases
> where a newer recipe version does no longer produce a
> certain package since no files were installed by the build?

Well if there is a difference in packaging then there should be an upgrade
path designed so the newer packages upgrade the older packages correctly.
This is something the package manager has to take care of it is not
somethig that bitbake can control. Bitbake picks the recipes and builds
them and emits the packages thats it
> 
> does that further mean an ever added results package
> must stay in the recipe for an indefinitely long period
> even if it will be empty just for forced removal?
> 
> if that scenario is already addressed by some patch
> then please drop me a note on the current state.
> 
> regards, Alex.
> 
> -- 
> GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 für nur 19,99 Euro/mtl.!*
> http://portal.gmx.net/de/go/dsl
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Package Grouping, Development Libraries and Headers.

[Dale Weber]

	Greetings,

	I need to have development libraries and headers installed for certain 
packages and was told that package grouping would accomplish this. I am not so 
sure that is true and have serious doubts. Below is what I have for errors and 
the recipe I am trying to modify to get development libraries and headers 
installed.

	How can I accomplish what I need to do without doing a bunch of native 
builds just to get development libraries and headers?

	8-Dale


NOTE: Handling BitBake files: \ (7100/7100) [100 %]
Parsing of 7100 .bb files complete (6687 cached, 413 parsed). 7347 targets, 301 
skipped, 0 masked, 0 errors.

Build Configuration:
BB_VERSION        = "1.10.0"
METADATA_BRANCH   = "master"
METADATA_REVISION = "f503cc21ff0c6dbc06c22b05975c2a2c6d16ede9"
TARGET_ARCH       = "arm"
TARGET_OS         = "linux-gnueabi"
MACHINE           = "beagleboard"
DISTRO            = "angstrom"
DISTRO_VERSION    = "2010.7-test-20101029"
TARGET_FPU        = "hard"

========
THE ERRORS
========

ERROR: '['/xdev/Devel/Beagle/sources/openembedded/recipes/images/walter-
console-dev-image.bb']' RDEPENDS/RRECOMMENDS or otherwise requires the runtime 
entity 'task-sdk-native-dev' but it wasn't found in any PACKAGE or RPROVIDES 
variables
ERROR: Required build target 'walter-console-dev-image' has no buildable 
providers.
Missing or unbuildable dependency chain was: ['walter-console-dev-image', 
'task-sdk-native-dev']
NOTE: Resolving any missing task queue dependencies
ERROR: '['/xdev/Devel/Beagle/sources/openembedded/recipes/images/walter-
console-dev-image.bb']' RDEPENDS/RRECOMMENDS or otherwise requires the runtime 
entity 'task-sdk-native-dev' but it wasn't found in any PACKAGE or RPROVIDES 
variables
Unknown Event: <bb.event.NoProvider instance at 0x10bbf14c>
NOTE: Runtime target 'task-sdk-native-dev' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['task-sdk-native-dev']
ERROR: Required build target 'walter-console-dev-image' has no buildable 
providers.
Missing or unbuildable dependency chain was: ['walter-console-dev-image', 
'task-sdk-native-dev']
Command execution failed: Traceback (most recent call last):
  File "/xdev/Devel/Beagle/sources/bitbake/lib/bb/command.py", line 88, in 
runAsyncCommand
    commandmethod(self.cmds_async, self, options)
  File "/xdev/Devel/Beagle/sources/bitbake/lib/bb/command.py", line 174, in 
buildTargets
    command.cooker.buildTargets(pkgs_to_build, task)
  File "/xdev/Devel/Beagle/sources/bitbake/lib/bb/cooker.py", line 784, in 
buildTargets
    taskdata.add_unresolved(localdata, self.status)
  File "/xdev/Devel/Beagle/sources/bitbake/lib/bb/taskdata.py", line 562, in 
add_unresolved
    self.remove_runtarget(self.getrun_id(target))
  File "/xdev/Devel/Beagle/sources/bitbake/lib/bb/taskdata.py", line 535, in 
remove_runtarget
    self.fail_fnid(fnid, missing_list)
  File "/xdev/Devel/Beagle/sources/bitbake/lib/bb/taskdata.py", line 490, in 
fail_fnid
    self.remove_buildtarget(target, missing_list)
  File "/xdev/Devel/Beagle/sources/bitbake/lib/bb/taskdata.py", line 519, in 
remove_buildtarget
    raise bb.providers.NoProvider
NoProvider

beagle@intrepid:/xdev/Devel/Beagle$ cat 
sources/openembedded/recipes/images/walter-console-dev-image.bb 

========
THE RECIPE:
========

#Angstrom bootstrap image
require console-base-image.bb

DEPENDS += "task-base-extended \
           "
IMAGE_FEATURES += "dev"
IMAGE_FEATURE_dev = "alsa-lib \
                        curl \
                        libusb \
                        openssl \
                        "

IMAGE_INSTALL += "task-base-extended \
    task-sdk-native \
    angstrom-led-config \
    apmd \
    minicom \
    cvs \
    git \
    subversion \
    ntp \
    tzdata \
    cherokee \
    vsftpd \
    i2c \
    i2c-tools \
    dosfstools \
    e2fsprogs \
    e2tools \
    sqlite \
    xchat \
    cron \
    sox \
    screen \
    rt73-firmware \
# Native build these for now
#    curl \
#    alsa-lib \
#    openssl \
#    libusb \
    "

export IMAGE_BASENAME = "walter-console-dev-image"

-- 
Open your mind, Read, Learn, Think, Apply..
AllStar Node 2392 / EchoLink 541558 / 73, from N7PKT!
http://www.hybotics.com - NEW main site
Just because we can, does it follow that we should?