* package/build problems with dropped packages @ 2010-09-27 12:10 Alexander Stohr 2010-10-29 19:21 ` Khem Raj 0 siblings, 1 reply; 3+ messages in thread From: Alexander Stohr @ 2010-09-27 12:10 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: package/build problems with dropped packages 2010-09-27 12:10 package/build problems with dropped packages Alexander Stohr @ 2010-10-29 19:21 ` Khem Raj 2010-10-29 21:00 ` Package Grouping, Development Libraries and Headers Dale Weber 0 siblings, 1 reply; 3+ messages in thread From: Khem Raj @ 2010-10-29 19:21 UTC (permalink / raw) To: openembedded-devel 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Package Grouping, Development Libraries and Headers. 2010-10-29 19:21 ` Khem Raj @ 2010-10-29 21:00 ` Dale Weber 0 siblings, 0 replies; 3+ messages in thread From: Dale Weber @ 2010-10-29 21:00 UTC (permalink / raw) To: openembedded-devel 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? ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-10-29 21:10 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-09-27 12:10 package/build problems with dropped packages Alexander Stohr 2010-10-29 19:21 ` Khem Raj 2010-10-29 21:00 ` Package Grouping, Development Libraries and Headers Dale Weber
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.