Re: [yocto] How does python-native work?
On Wed, Apr 23, 2014 at 8:44 AM, Gary Thomas wrote: > First, it's a bit worrisome that you're inheriting a class for distutils >> when your build doesn't actually use distutils.. but beyond that, I don't >> think the classes inherited by >> distutils assume you'll be running python-config. Add this: >> >> export BUILD_SYS >> export HOST_SYS >> > > I went back to only inheriting pythonnative (I was a bit > overzealous to follow your 'or a class that inherits it'). > > I found that I also needed: > export STAGING_INCDIR > export STAGING_LIBDIR > > Perhaps pythonnative should imply those exports, as without > them, python-config is useless. > > Anyway, now the recipe successfully builds the python interface!! Ah! I knew there was exports needed, but apparently I remembered them wrong. Sorry about that. Glad you got it going, though. I don't think pythonnative exporting those would necessarily be appropriate, though. Not everyone inheriting pythonnative needs to do anything more than run python itself :) Perhaps we need a new class.. though the class proliferation is already a bit much. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How does python-native work?
On Wed, Apr 23, 2014 at 7:57 AM, Gary Thomas wrote:
> On 2014-04-23 08:21, Chris Larson wrote:
>
> On Wed, Apr 23, 2014 at 7:15 AM, Gary Thomas > g...@mlbassoc.com>> wrote:
>>
>> How is python-native supposed to work? I can see that it's
>> built and installed in my tmp/sysroots/HOST but it's installed
>> in a sub-directory which is not found by normal means.
>>
>>
>> inherit pythonnative (or one of the classes that inherit it)
>>
>
> Thanks, I imported 'distutils' and that helped, but I still have problems
> with it. Looking
> at log.do_configure:
> checking for python... /local/rpi_2014-04-10/tmp/
> sysroots/x86_64-linux/usr/bin/python-native/python
> checking for python-config... /local/rpi_2014-04-10/tmp/
> sysroots/x86_64-linux/usr/bin/python-native/python-config
> Traceback (most recent call last):
> File
> "/local/rpi_2014-04-10/tmp/sysroots/x86_64-linux/usr/bin/python-native/python-config",
> line 6, in
> from distutils import sysconfig
> File "/local/rpi_2014-04-10/tmp/sysroots/x86_64-linux/usr/lib/
> python2.7/distutils/sysconfig.py", line 22, in
> PREFIX = os.path.normpath(sys.prefix).replace(
> os.getenv("BUILD_SYS"), os.getenv("HOST_SYS") )
> TypeError: expected a character buffer object
>
> When I ran python-config before (original email), the results
> were from outside the build environment, i.e. the command line
> where I run 'bitbake'. When do_configure() runs in my recipe,
> the environment seems to be quite different. If I try to run
> python-config from devshell (for my recipe), it fails as above.
>
First, it's a bit worrisome that you're inheriting a class for distutils
when your build doesn't actually use distutils.. but beyond that, I don't
think the classes inherited by distutils assume you'll be running
python-config. Add this:
export BUILD_SYS
export HOST_SYS
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How does python-native work?
On Wed, Apr 23, 2014 at 7:15 AM, Gary Thomas wrote: > How is python-native supposed to work? I can see that it's > built and installed in my tmp/sysroots/HOST but it's installed > in a sub-directory which is not found by normal means. > inherit pythonnative (or one of the classes that inherit it) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [poky] ERROR: Function failed: do_rootfs, when using ipk package class
On Wed, Apr 16, 2014 at 9:28 AM, Elvis Dowson wrote: > I just tries a build with poky master, and meta-xilinx master branch, and > got the following build error. > > For some reason the yocto build process fails is PACKAGE_CLASSES is set to > package_ipk. > > ERROR: Unable to install packages. Command > '/tool/yocto/build/zc706/tmp/sysroots/x86_64-lux/usr/bin/opkg-cl -f > /tool/yocto/build/zc706/tmp/work/zc706_zynq7-poky-linux-gnueabi/core-image-minimal/1.0-r0/opkg.conf > -o > /tool/yocto/build/zc706/tmp/work/zc706_zynq7-poky-linux-gnueabi/core-image-minimal/1.0-r0/rootfs > --force_postinstall --prefer-arch-to-version install run-postinsts > packagegroup-core-boot' returned 255: > Installing run-postinsts (1.0-r9) to root... > Downloading > file:/tool/yocto/build/zc706/tmp/deploy/ipk/all/run-postinsts_1.0-r9_all.ipk. > Installing update-rc.d (0.7-r5) to root... > Downloading > file:/tool/yocto/build/zc706/tmp/deploy/ipk/all/update-rc.d_0.7-r5_all.ipk. > sh: 1: /tmp/opkg-RUBbug/run-postinsts-mxgou5/preinst: Permission denied > Sounds like your /tmp is mounted disallowing execution there, and opkg must assume it's able to execute its scripts there. Either use a different package manager, fix opkg to change this behavior, or change your /tmp mount to no longer be noexec. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] weston: Add weston.ini
On Tue, Apr 15, 2014 at 5:45 AM, Sujith H wrote: > From: Sujith H > > Adding weston.ini to $HOME/.config. With this change > user can login to $HOME and launch weston with ivi-shell. > > Signed-off-by: Sujith H > 1) the package manager shouldn't install user files, unless absolutely necessary, and if you're going to do something like that, you should at least split it out into a separate package, IMO 2) you hardcode /home/root rather than using the variable for root's home directory (see bitbake.conf) 3) you don't actually mention what layer this patch is destined for. I'm guessing meta-yocto? -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Confusion about autotools
On Thu, Apr 10, 2014 at 5:12 PM, Patrick Doyle wrote:
> ok, that makes sense. Trying to pattern match against too many
> patterns, and not spending enough time understanding the underlying
> technology. Thank you for the explanation.
>
> If you don't mind, I'll move on to my next question...
>
> I now have a "do_fetch()" task that looks like this:
>
> do_fetch () {
> bberror "Hello World"
> exit 1
> }
>
> Where would I see "Hello World" pop out? I don't see it in the log file.
>
It should show up in the do_fetch log (not the cooker log), which lives
next to the run script. That said, it's possible you're hitting an issue
due to the base.bbclass fetch implementation being python, not shell.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Confusion about autotools
On Thu, Apr 10, 2014 at 4:43 PM, Patrick Doyle wrote:
> I am trying to write a recipe for a custom gstreamer plugin that
> compiles fine (natively) with autotools.
>
> I thought it would be as simple as writing a recipe that said something
> like:
>
> inherit autotools
>
> myplugin_do_fetch() {
> commands_to_make_a_copy_of_my_source_code_in_build_tree;
> }
> EXPORT_FUNCTIONS do_fetch
>
> (I am leaving out the boilerplate DESCRIPTION, LICENSE, etc...
>
> But when I try to run my recipe, I get an error that ends like:
>
> 109: /home/wpd/.../run.do_fetch.1234 do_fetch: not found
>
> and when I look at run.do_fetch, I see on line 109
>
> do_fetch
>
> I thought that do_fetch would be inherited from base.bbclass. I look
> in autotools.bbclass and I don't see a do_fetch function task defined
> there.
>
EXPORT_FUNCTIONS is an inheritance mechanism, to let you override a
function in a class you inherit but still be able to explicitly call the
function defined by that class. Unless you have a 'myplugin' class, nothing
will translate myplugin_do_fetch to do_fetch. If you want to override a
function like do_fetch in your recipe, just override that function, don't
prefix it.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dogfooding and usability testing Toaster
On Wed, Apr 9, 2014 at 4:33 PM, Rudolf Streif wrote: > That is exciting. I just ran with it and started a build with toaster in > the background. A couple of observations from the get-go: > >- South 0.8.4 is also needed in addition to Django. The Toaster Wiki >[1] does not say that but the Contribute to Toaster page [2] does. >- You need to run 'sudo pip install ...' for Django and South >otherwise the installation fails with 'permission denied' for >/usr/lib/python2.7 >- Clicking on "Show me the manual" in the Toaster UI directs to [3] >which requires a log in >- Is it possible to relocate/rename the toaster.sqlite database via >configuration setting? If so, could I use the same database for different >build environments? > > Side note: you can use pip install --user ... rather than sudo pip, to install it to your user site-packages directory under ~/.local, which won't impact the rest of the system. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] do_populate_sysroot_setscene needs pseudo-native
On Wed, Apr 9, 2014 at 1:52 PM, Jate S wrote: > WARNING: Setscene task 45 > (/home/jate/workspace/poky/meta/recipes-connectivity/avahi/ > avahi-ui_0.6.31.bb, > do_populate_sysroot_setscene) failed with exit code '1' - real task > will be run instead > > The task log.do_populate_sysroot_setscene has the following WARNING: > > NOTE: Performing useradd with [--root > /home/jate/workspace/poky/qemux86/tmp/sysroots/qemux86 --system --home > /var/run/avahi-daemon --no-create-home > --shell /bin/false --user-group avahi] > and 10 times of retry > > /home/jate/workspace/poky/qemux86/tmp/work/i586-poky-linux/avahi-ui/0.6.31-r7.0/temp/run.useradd_sysroot_sstate.17299: > line 284: > /home/jate/workspace/poky/qemux86/tmp/sysroots/i686-linux/usr/bin/pseudo: > No such file or directory > WARNING: useradd command did not succeed. Retrying... > > If I bitbake pseudo-native manually first, I can eliminate the > warning. I tried adding pseudo-native to the useradd.bbclass, but that > doesn't cause a rebuild. > > Any thoughts on how to do this? > You likely need something like: do_populate_sysroot_setscene[depends] += "pseudo-native:do_populate_sysroot_setscene" If you grep around oe-core/poky, there are a couple examples of this. I actually just ran into a case like this, where gdk-pixbuf-native needed jpeg-native to run its setscene postinst, but the dep was missing, causing setscene failure. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CGL compliance layer initiative
On Tue, Apr 8, 2014 at 8:34 AM, Vali Cobelea wrote: > Here at ENEA we decided to take the initiative regarding the CGL > compliance when it comes to the Yocto Project. > For this we started the work on a dedicated layer called 'meta-cgl' which > can be accessed / cloned from here: > > http://git.enea.com/git/?p=linux/meta-cgl.git > git clone g...@git.enea.com:linux/meta-cgl > git clone git://git.enea.com/linux/meta-cgl.git for those of us who don't work for ENEA, works fine :) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CGL compliance layer initiative
On Tue, Apr 8, 2014 at 8:41 AM, Vali Cobelea wrote: > It should work as I tried it outside the company network; otherwise I'll > ping back the IT guys to allow anonymous access. > You tried it, yes, but you have the ssh keys necessary to authenticate as the git user on that server, which no one outside your company does :) If you want folks to be able to clone your repository without having to add their public keys to your ssh server config, then you will indeed want to contact IT to get anonymous access going. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CGL compliance layer initiative
On Tue, Apr 8, 2014 at 8:34 AM, Vali Cobelea wrote: > Here at ENEA we decided to take the initiative regarding the CGL > compliance when it comes to the Yocto Project. > For this we started the work on a dedicated layer called 'meta-cgl' which > can be accessed / cloned from here: > > http://git.enea.com/git/?p=linux/meta-cgl.git > git clone g...@git.enea.com:linux/meta-cgl > > Have a look of the things we got there so far, please remember that there > is still plenty of work to be done (layer architecture, CGL requirements > coverage mode and so on). > It is a little bit more than a stub layer, consider it a starting point > for the direction we would like to have with this layer. > > Any input is much appreciated, lets keep the discussion by this email > thread and see where it goes. > Is there no anonymous clone url, or are you giving us your ssh keys? ;) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Missing Python modules on target
On Wed, Mar 19, 2014 at 8:40 AM, Jonatan Magnusson < jonatan.magnus...@gmail.com> wrote: > I am trying to use Python on my target. > > I added ”python” to IMAGE_INSTALL. But then the "base64" module was not > installed. > Very well, I added ”python-modules” to IMAGE_INSTALL, and now "base64" was > installed. > > But now "wsgiref" was missing. As far as I can see the only modules and > packages that are/can be > installed are the ones listed in > ”meta/recipes-devtool/python/python-2.7-manifest.inc” and ”wsgiref” is not > mentioned there. > > What to do? > > Is ”wsgiref” left out because it is incompatible with Yocto for some > reason? Or can I add it myself in some way? > Is there perhaps a way to install *all* modules/packages of the Python > standard library? Disk space is not a problem. > That's what python-modules is for. If it didn't include it, then it sounds like it wasn't built at all in the python build, so that's where you'd need to look, I'd think. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [RFC] Blubber, a tool to set up yocto/poky projects easily
On Mon, Mar 10, 2014 at 5:02 AM, Josef Holzmayr < jholzm...@the-exact-steps.net> wrote: > Hello Alex, > > > Alex J Lennon hat am 10. März 2014 um > 12:43 > > geschrieben: > > > fwiw I'd have thought myself that string comparison should be string > > comparison (==) as if you use an object identity comparison as a string > > comparison (is), you potentially introduce opaque problems when the > > strings are the same - i.e. same bytes of data - but the objects are not > > the same for whatever reason. > > I've interpreted it roughly the same so far, but they ValueError point > seems to > valid to me too (gah, I really know why I usually avoid dynamically typed > languages!). But the solution for me in this context seems to be then to > use > something like: > > DUMMYSTRING = "foobar" > def safestringcompare(stra, strb): > return type(DUMMYSTRING) == type(stra) and type(stra) == type(strb) and > stra > == strb > Strings should be compared with ==, not is. And there's nothing that will explode if you compare against None with ==. Try it yourself. >>> "foo" == None False -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] GLIB-2.0 target compile issue
On Wed, Mar 5, 2014 at 8:47 AM, Rick Bianchi wrote: > Can I just add the dev-pkgs to my local.conf? EXTRA_IMAGE_FEATURES += "dev-pkgs" -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] GLIB-2.0 target compile issue
On Wed, Mar 5, 2014 at 8:29 AM, Rick Bianchi wrote: > I have add IMAGE_INSTALL_append =" glib-2.0" to my local.conf and compile > the image on the host without any issues. > > When I try to compile on the target I get the following error: > > checking pkg-config is at least version 0.9.0... yes > checking for PACKAGE... no > configure: error: Package requirements (glib-2.0 >= 2.6.0) were not met: > > No package 'glib-2.0' found > You did install the development files, either with the dev-pkgs image feature, or by directly installing them (glib-2.0-dev, .)? Our packaging is quite granular, so the 'glib-2.0' package won't provide development files, just the files necessary to run software using glib. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dealing with new git fetcher
On Fri, Dec 6, 2013 at 8:08 AM, Gary Thomas wrote: > The 'git' fetcher was recently changed to expect/need the branch > name for the desired revision. Many recipes don't have this and > the revision is not on the master branch, hence leading to errors > like this: > ERROR: Fetcher failure: Unable to find revision > f89bc066db0569008418fac1a0408a9a57f2232f in branch master even from > upstream > ERROR: Function failed: Fetcher failure for URL: 'git://github.com/ > boundarydevices/u-boot-imx6.git'. Unable to fetch URL from any source. > ERROR: Logfile of failure stored in: /local/imx6_new/tmp/work/ > sabrelite-amltd-linux-gnueabi/u-boot-script-boundary/v2013. > 01+gitAUTOINC+f89bc066db-r0/temp/log.do_fetch.25272 > ERROR: Task 144 (/local/poky-multi/meta-fsl- > arm-extra/recipes-bsp/u-boot/u-boot-script-boundary_git.bb, do_fetch) > failed with exit code '1' > > So the problem becomes how to identify the branch? In the case > above, I have a checked out copy of this repository and when I > try to find the branch, I come up empty: > $ git branch --contains f89bc066db0569008418fac1a0408a9a57f2232f > $ git log f89bc066db0569008418fac1a0408a9a57f2232f > commit f89bc066db0569008418fac1a0408a9a57f2232f > Author: Eric Nelson > Date: Mon Aug 26 17:36:35 2013 -0700 > i.MX6: nitrogen6x: Add Yocto boot script > > So I see that the commit is present, but when I ask what branch, I > get nothing... > You asked git only about local branches. $ git branch -a --contains f89bc066db0569008418fac1a0408a9a57f2232f remotes/origin/production-before-20131107 -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The difference of & and | in LICENSE definition
On Fri, Dec 6, 2013 at 7:23 AM, Kumita Bruce wrote: > I don't know whether this is the right place to ask the question. Hope to > get some help from here. > > I see below two types definition of LICENSE in Yocto recipe: > LICENSE = "license-1 & license-2" > LICENSE = "license-1 | license-2" > > Can somebody help to give some explanation for the difference of those two > formats? And how to determinate which format should be used for a package. > & is AND. | is OR. Some software can be licensed under this OR that license, others have components which are under a variety of different licenses (AND). -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to build a non-autotools package that contains only a lib. Getting empty archive - package is not generated
On Thu, Dec 5, 2013 at 9:21 AM, Brian Hutchinson wrote:
> I had FILES_${PN} += “${libdir}/*.so” in there and that didn't work.
> Maybe it was because I was missing the FILES_SOLIBSDEV = “" you mentioned.
> I'll play with it some more and see what happens. I first started out with
> FILES_${PN} += “${libdir}/*.so” and when that didn't work I tried other
> things in the FILES_${PN} = line to try and get it picked up. When I
> couldn't get any of it to work and then saw others (well, at least the link
> I provided) were seeing the same thing I figured it was time to quit
> spinning my wheels and consult the big guns :)
Heh :) The issue there is that the patterns are matched in the order of the
PACKAGES variable. The first package to include a file gets it, and
${PN}-dev is in PACKAGES before ${PN}. By emptying FILES_SOLIBSDEV, that’ll
remove the .so from FILES_${PN}-dev, letting the ${PN} package get it
instead.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to build a non-autotools package that contains only a lib. Getting empty archive - package is not generated
On Thu, Dec 5, 2013 at 6:42 AM, Brian Hutchinson wrote:
> On Wed, Dec 4, 2013 at 5:38 PM, Chris Larson wrote:
>
>>
>> On Wed, Dec 4, 2013 at 3:29 PM, Brian Hutchinson wrote:
>>
>>> On Wed, Dec 4, 2013 at 5:10 PM, Chris Larson wrote:
>>>
>>>>
>>>> do_install is the task that installs. If your makefile has an install
>>>> target, you’d define a do_install that runs it. But not all makefiles
>>>> provide an equivalent to automake’s DESTDIR, which is why we don’t provide
>>>> a do_install for non-autotools make-based buildsystems. Either manually
>>>> install the library where it belongs in your do_install, e.g. with the
>>>> ‘install’ or ‘cp’ commands, or define one which runs the appropriate make
>>>> command to install the files into ${D}.
>>>> --
>>>>
>>>> Thanks Chris.
>>>
>>> I do have a do_install that is copying stuff to ${D}/usr/lib which puts
>>> things in my sysroot ... but what target do I use to get stuff into the
>>> package which is used by my IMAGE_INSTALL line? When I tar tvf my
>>> core-image.tar and grep for my .so it currently isn't there ... but it and
>>> the headers are in the sysroot.
>>>
>>
>> do_install. The contents of ${D} are where the FILES globs are matched.
>> We don’t include the raw libfoo.so, since that’s supposed to be a symlink.
>> If your lib is missing an SONAME, it’d be named incorrectly and be missing
>> a symlink, and the lib would end up in the -dev package instead of the main
>> package.
>> --
>>
>> The lib that the makefile generates is just a soname like libfoo.so. So
> you're telling me it will not pick that file up? I guess I need to find
> the class that handles this and study it as I'm probably not picking up all
> you're telling me. Like I said, this used to work and now it doesn't so
> I'm still at a loss as to what I need to do. It is making it into the
> sysroot but not the package and the rootfs image is built from all the
> IMAGE_INSTALL package names so it isn't making it into the rootfs.
>
> Do I just cheat and make my do_install copy my .so file to
> packages-split/mypackage/usr/lib?
>
The best fix would be to properly name and version your library, e.g.
libfoo.so.2.4, with libfoo.so.2 and libfoo.so symlinks, which is the most
common practice, but if that’s not an option, or will take too much time,
yes, you can absolutely make your .so end up in the main package.
As i said earlier, it’s the *packaging* process that puts the .so in the
-dev package, as common practice is that the .so is a symlink only used in
development. If your do_install already installs the .so to ${D}${libdir},
you just need to alter the globs used in the FILES variables to change
which package it ends up in. To add your non-symlink .so to the main
package rather than the ${PN}-dev package:
# Add the .so to the main package’s files list
FILES_${PN} += “${libdir}/*.so”
# Make sure it isn’t in the dev package’s files list
FILES_SOLIBSDEV = “"
Should do it, as far as I can tell.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to build a non-autotools package that contains only a lib. Getting empty archive - package is not generated
On Wed, Dec 4, 2013 at 3:29 PM, Brian Hutchinson wrote:
> On Wed, Dec 4, 2013 at 5:10 PM, Chris Larson wrote:
>
>>
>> do_install is the task that installs. If your makefile has an install
>> target, you’d define a do_install that runs it. But not all makefiles
>> provide an equivalent to automake’s DESTDIR, which is why we don’t provide
>> a do_install for non-autotools make-based buildsystems. Either manually
>> install the library where it belongs in your do_install, e.g. with the
>> ‘install’ or ‘cp’ commands, or define one which runs the appropriate make
>> command to install the files into ${D}.
>> --
>>
>> Thanks Chris.
>
> I do have a do_install that is copying stuff to ${D}/usr/lib which puts
> things in my sysroot ... but what target do I use to get stuff into the
> package which is used by my IMAGE_INSTALL line? When I tar tvf my
> core-image.tar and grep for my .so it currently isn't there ... but it and
> the headers are in the sysroot.
>
do_install. The contents of ${D} are where the FILES globs are matched. We
don’t include the raw libfoo.so, since that’s supposed to be a symlink. If
your lib is missing an SONAME, it’d be named incorrectly and be missing a
symlink, and the lib would end up in the -dev package instead of the main
package.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to build a non-autotools package that contains only a lib. Getting empty archive - package is not generated
On Wed, Dec 4, 2013 at 3:02 PM, Brian Hutchinson wrote:
> I appear to be having the same problem this guy had:
> https://lists.yoctoproject.org/pipermail/poky/2013-June/009017.html
>
> I'm trying to build a Makefile based project (not autotools) that just
> generates a shared library. When I bitbake my recipe I get a -dev and -dbg
> .ipk package but not ${PN}. So I added ALLOW_EMPTY_${PN} = "1" and that
> generated the package but apparently the lib is not in the package!
>
> The lib I want to be in the package is sitting in ${WORKDIR}/src and ${S}
> is set to that. So I tried to set FILES_${PN} = ${S}/sharedlib.so and that
> still doesn't pick it up.
>
> I've tried everything I can think of and can't get the lib in the
> package! This is with 1.5 Dora.
>
> Any idea why my lib isn't put in the package?
do_install is the task that installs. If your makefile has an install
target, you’d define a do_install that runs it. But not all makefiles
provide an equivalent to automake’s DESTDIR, which is why we don’t provide
a do_install for non-autotools make-based buildsystems. Either manually
install the library where it belongs in your do_install, e.g. with the
‘install’ or ‘cp’ commands, or define one which runs the appropriate make
command to install the files into ${D}.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] why is "package-management" defined as a PACKAGE_GROUP?
On Sun, Nov 17, 2013 at 9:17 AM, Robert P. J. Day wrote:
> $ bb show -r core-image-base ROOTFS_PKGMANAGE
> Parsing recipes..done.
> # ROOTFS_PKGMANAGE=opkg opkg-collateral ${EXTRAOPKGCONFIG}
> ROOTFS_PKGMANAGE="opkg opkg-collateral poky-feed-config-opkg"
> $
>
> but that feature *also* pulls in additional processing as it's defined
> in image.bbclass.
>
If you’re referring to the bootstrap bits, technically that doesn’t do
something when it’s included in image features, it does something when it’s
*not* included in image features — include ROOTFS_PKGMANAGE_BOOTSTRAP
instead of ROOTFS_PKGMANAGE.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] why is "package-management" defined as a PACKAGE_GROUP?
On Sun, Nov 17, 2013 at 5:45 AM, Robert P. J. Day wrote:
> leaving aside the bug report, i am now hopelessly confused. are you
> saying this line:
>
> PACKAGE_GROUP_package-management = "${ROOTFS_PKGMANAGE}"
>
> from core-image.bbclass is currently *necessary* to properly support
> the image feature of "package-management" in core images? i don't see
> how or why. using that logic, you'd also need lines of that form for
> "read-only-rootfs" and "debug-tweaks", which certainly don't exist.
>
> are you sure you're answering the question i'm asking?
>
> rday
>
> p.s. i just don't see how that line has any value based on a few
> simple tests i ran. using dora to build for a beagle xm, i can display
> some variables:
>
> $ bb show -r core-image-base IMAGE_FEATURES
> Parsing recipes..done.
> IMAGE_FEATURES="debug-tweaks splash"
> $ bb show -r core-image-base
> EXTRA_IMAGE_FEATURES
> Parsing recipes..done.
> EXTRA_IMAGE_FEATURES="debug-tweaks"
> $
>
> which looks correct. now let's edit my local.conf and change:
>
> EXTRA_IMAGE_FEATURES = "debug-tweaks"
>
> to
>
> EXTRA_IMAGE_FEATURES = "debug-tweaks package-management"
>
> save, exit and verify:
>
> $ bb show -r core-image-base IMAGE_FEATURES
> Parsing recipes..done.
> IMAGE_FEATURES="debug-tweaks splash package-management"
> $ bb show -r core-image-base
> EXTRA_IMAGE_FEATURES
> Parsing recipes..done.
> EXTRA_IMAGE_FEATURES="debug-tweaks package-management"
>
> good. and now, let's edit core-image.bbclass and remove the line:
>
> PACKAGE_GROUP_package-management = "${ROOTFS_PKGMANAGE}"
>
> save, exit and test:
>
> $ bb show -r core-image-base IMAGE_FEATURES
> Parsing recipes..done.
> IMAGE_FEATURES="debug-tweaks splash package-management"
> $ bb show -r core-image-base
> EXTRA_IMAGE_FEATURES
> Parsing recipes..done.
> EXTRA_IMAGE_FEATURES="debug-tweaks package-management"
> $
>
> seems like the "package-management" image feature is being picked up
> just fine.
>
This test you did makes no sense. Of course it’s in IMAGE_FEATURES, you put
it there. What you didn’t check is whether ${ROOTFS_PKGMANAGE} ended up
being installed in the image, which it won’t be.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Happy Birthday, Yocto Project
On Fri, Nov 15, 2013 at 1:07 PM, Mark Hatle wrote: > On 11/15/13, 1:54 PM, Mark Hatle wrote: > >> On 11/14/13, 9:58 PM, Jeff Osier-Mixon wrote: >> >>> Hm, a day that will live in infamy indeed >>> >>> On Fri, Nov 15, 2013 at 3:09 AM, Philip Balister >>> wrote: >>> >>>> On 11/14/2013 08:22 PM, Robert P. J. Day wrote: >>>> >>>>> On Thu, 14 Nov 2013, Jeff Osier-Mixon wrote: >>>>> >>>>> Happy birthday, Yocto Project! >>>>>> >>>>> >>>>> what's a birthday without cake? >>>>> >>>>> http://www.instructables.com/id/Brain-Cake/ >>>>> >>>>> rday >>>>> >>>>> >>>> Berlios suggests bitbake was born on Dec 7, 2004. So in a few weeks we >>>> will celebrate the 9'th birthday of the OpenEmbedded build system. >>>> >>> >> I found a presentation that seems to have a bit more history in it. >> >> OpenEmbedded & BitBake - Denx. >> www.denx.de/wiki/pub/ELDKHistory/.../OpenEmbeddedv1.ppt >> December 2004: OpenEmbedded is split up into the BitBake build system and >> the >> OpenEmbedded metadata. OpenZaurus. OpenEmbedded is the successor to .. >> >> http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&; >> cd=6&ved=0CE0QFjAF&url=http%3A%2F%2Fwww.denx.de%2Fwiki% >> 2Fpub%2FELDKHistory%2FDocumentationLinks%2FOpenEmbeddedv1.ppt&ei= >> n3eGUseFHKyh4APFs4CgBQ&usg=AFQjCNGZtQsaGso-YaqLYSlOJaJfhDiaug&sig2= >> JzdEhA4q-4bhBDhE1NOxMQ&bvm=bv.56643336,d.dmg >> >> 2001: Sharp introducestheSL-5000 PDA running Linux >> >> 2002: Chris Larson finds out that the SharpROM sucks and starts hacking >> on a >> build system for a customized Linux distribution called "OpenZaurus” >> >> 2002-2003: The OpenZaurus build system is getting stretched (beyond >> belief) by >> adding support for many more packages and target devices >> >> January 2003: Brainstorming towards a new distribution and device >> independent >> build system >> >> February 2003: Holger Schurig creates the OpenEmbedded repository and >> starts >> hacking on the first version >> >> May 2003: Chris Larson adds major functionality to the OpenEmbedded core >> and >> starts converting packages from the OpenZaurus build system >> >> December 2003: Michael Lauer releases OpenZaurus3.3.5, abandons the >> OpenZaurus >> build system, and converts100s of packages to OpenEmbedded >> >> December 2004: OpenEmbedded is split up into the BitBake build system and >> the >> OpenEmbedded metadata >> >> So the magic Dec 7 2004 date is the split of OpenEmbedded into bitbake >> and the >> 'metadata'. the actual work was almost 20 months prior. >> >> The sourceforge openembedded project was registerd 2003-01-21: >> >> http://sourceforge.net/projects/openembedded/ >> >> Also I found a repository that appears it may contain the original >> OpenEmbedded.. first commit is: >> >> Author: Chris Larson >> Date: Mon Jun 2 21:19:02 2003 + >> >> Initial repository create >> >> BKrev: 3edbbf46Zm7UJzG9iGisj7ELSsUuZQ >> > > Never thought to look at the Bitbake repository.. first commit: > > commit af645b03b585a9c92dc88756b8f6badfec5f > Author: Chris Larson > > Date: Fri Feb 21 04:03:45 2003 + > > .oe file parser function > > So I think that Jives with the Approx Feb 2003 timeframe.. and I'd say > the code birthday then would be Feb 21 2003 -- so in 3 months we're looking > at the 12th anniversary of Bitbake/OE. https://docs.google.com/spreadsheet/ccc?key=0AjCkwYM6wjBQdGx6Umt2cjBETjNsS09CUFNxRUwzVEE has some dates I started to gather years ago, in case it’s at all of use. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Stalled with setting up Yocto 1.5 on CentOS 6.4 with Python 2.7.3
On Wed, Nov 13, 2013 at 10:17 PM, ben wrote: > This is my first foray into embedded linux Yocto-Style. > > I've got an RPM for Python2.7 installed that doesn't trash my system > (which needs 2.6.6). > > But the initial 'source oe-init-build-env' doesn't work... > > Google is not helping me find a definitive page to instruct getting around > this (looked on wiki too). > > Little help? > I've had the best results using the buildtools-tarball that yocto itself can produce. Use a more recent host to 'bitbake buildtools-tarball', then execute the shell archive it puts in tmp/deploy/sdk/ on the CentOS 5 or 6 machine, and source its setup script before sorucing oe-init-build-env. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] explanation for ALTERNATIVE_LINK_NAME in ref manual seems incomplete
On Sat, Nov 2, 2013 at 3:13 AM, Robert P. J. Day wrote:
> on my quest to spiff up the ref manual variables glossary, a question
> about ALTERNATIVE_LINK_NAME, explained here:
>
>
> http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-ALTERNATIVE_LINK_NAME
>
> at first glance, that explanation *suggests* that the purpose of that
> variable is to support an alternative name to an existing command, but
> it doesn't make it clear that a *very* common usage is to simply
> create a link with precisely the same name elsewhere. you see a *lot*
> of this throughout the recipes (like this snippet from util-linux):
>
> ALTERNATIVE_LINK_NAME[dmesg] = "${base_bindir}/dmesg"
> ALTERNATIVE_LINK_NAME[kill] = "${base_bindir}/kill"
> ALTERNATIVE_LINK_NAME[more] = "${base_bindir}/more"
> ALTERNATIVE_LINK_NAME[mkswap] = "${base_sbindir}/mkswap"
> ALTERNATIVE_LINK_NAME[blockdev] = "${base_sbindir}/blockdev"
>
> which appears to simply create symlinks from /bin to programs in
> /usr/bin, yes? (that's what it's doing, right?) i suspect it would be
> useful to mention that application in the explanation, unless i'm
> totally misunderstanding what i'm reading.
>
I’m pretty sure that’s not the case. Afaik it creates a link from
ALTERNATIVE_TARGET[name] to ALTERNATIVE_LINK_NAME[name]. If the target
isn’t defined, iirc it defaults to adding a .${BPN} suffix to the link
name. See lines 41 through 45 of update-alternatives.bbclass:
# NOTE: If ALTERNATIVE_TARGET is not defined, it will inherit the value
# from ALTERNATIVE_LINK_NAME.
#
# NOTE: If the ALTERNATIVE_LINK_NAME and ALTERNATIVE_TARGET are the
same,
# ALTERNATIVE_TARGET will have '.{BPN}' appended to it.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] undocumented/inconsistent use of KERNEL_DEVICETREE variable
On Thu, Oct 24, 2013 at 8:27 AM, Robert P. J. Day wrote:
> simple observation -- the KERNEL_DEVICETREE variable is not
> mentioned in the ref manual variable glossary.
>
> more weirdly, though, i've always been used to seeing it used this
> way, like in the meta-yocto-bsp layer (that is, referring to the .dts
> *source* files):
>
> beagleboard.conf:KERNEL_DEVICETREE =
> "${S}/arch/arm/boot/dts/omap3-beagle.dts
> ${S}/arch/arm/boot/dts/omap3-beagle-xm.dts"
> mpc8315e-rdb.conf:KERNEL_DEVICETREE =
> "${S}/arch/powerpc/boot/dts/mpc8315erdb.dts"
>
> but i just noticed this in the meta-fsl-asm layer:
>
> meta-fsl-arm/conf/machine/imx23evk.conf:KERNEL_DEVICETREE = "imx23-evk.dtb"
> meta-fsl-arm/conf/machine/imx6dlsabresd.conf:KERNEL_DEVICETREE =
> "imx6dl-sabresd.dtb"
> meta-fsl-arm/conf/machine/imx6dlsabreauto.conf:KERNEL_DEVICETREE =
> "imx6dl-sabreauto.dtb"
> meta-fsl-arm/conf/machine/imx6qsabresd.conf:KERNEL_DEVICETREE =
> "imx6q-sabresd.dtb"
>
> where the variable contains references to the .dtb *blob* files.
>
> is there a standard? recommended? either way fine?
>
The behavior changed a couple months back.
See 03b3e4b62f22a8ef435252c0401c5369defabe71 in poky, aka “linux-dtb: Use
kernel build system to generate the dtb files”. The new style is the dtb
filename, the others likely need updating, unless those bsp layers override
the default linux-dtb behavior, afaik.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] is *anyone* using BBVERSIONS?
On Mon, Oct 14, 2013 at 3:38 AM, Robert P. J. Day wrote: > really more of a bitbake question but ... i'm also zipping through > the inline user manual that comes with bitbake and in section 2.1.20, > there is a discussion of Variants that includes: > > BBVERSIONS = "1.0 2.0 git" > SRC_URI_git = "git://someurl/somepath.git" > > BBVERSIONS = "1.0.[0-6]:1.0.0+ \ > 1.0.[7-9]:1.0.7+" > SRC_URI_append_1.0.7+ = > "file://some_patch_which_the_new_versions_need.patch;patch=1" > > i have over a dozen layers checked out, and i don't see the use of > BBVERSIONS in *any* of them -- the only thing a recursive search turns > up is BBVERSIONS being mentioned in the docs. > > is this feature active? deprecated? just curious. > The idea was we could avoid scattering metadata across many files and instead handle it the way we do with bbclassextend, but I don't think anyone ever really used it, except me when I was implementing it :) I'm not sure if it'll end up deprecated or not, but it wouldn't surprise me given the lack of use. If you want to see my testing repository where I was playing with this in actual recipes, see https://gist.github.com/kergoth/338382 - where I was working on teaching the system to be able to build every version of nano that had been released, because I'm crazy like that. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] DISTRO_FEATURES and shared SSTATE
On Sun, Oct 13, 2013 at 8:04 AM, seth bollinger wrote: > How does yocto know which package version to choose for an image if the > package can be altered (compilation difference, or perhaps config > alteration, etc.) by a DISTRO_FEATURE? > > For instance, if I make a change to sysvinit-inittab/inittab based on a > DISTRO_FEATURE, I can have multiple versions of sysvinit-inittab, but only > one shipping package, right? If I'm building two different images that > have that DISTRO_FEATURE set differently, won't one of the builds have the > incorrect sysvinit-inittab package installed? > Changing such a variable will alter the checksum of the task, resulting in re-execution of altered tasks if appropriate, or pulling from a different sstate archive. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is there anything like FILES_${PN}_append??
On Wed, Oct 9, 2013 at 1:24 AM, Amit Tomer wrote: > Now for variable SRC_URI ,I can do something like SRC_URI_append_xyz where > xyz is my platform where changes should be reflected. > This isn't specific to SRC_URI, it's general bitbake syntax that works for any variable. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to find the source of a variable value?
On Mon, Sep 16, 2013 at 11:34 AM, Paul D. DeRocco wrote: > > > On Mon, Sep 16, 2013 at 10:02 AM, Paul D. DeRocco > > > wrote: > > > > > > This image recipe has some Python that complains > > > because "x11" is in > > > DISTRO_FEATURES. How do I find out where that "x11" is > > > coming from? This > > > is a Gumstix build, so I suspect it's indirectly > > > related to my selecting > > > "overo" as the MACHINE, because otherwise building this > > > image would never > > > have worked with the plain Yocto meta-data. So how do I > > > track this down? > > > From: Chris Larson > > > > Assuming you're using recent metadata, bitbake -e somerecipe > > will show you this. > > This isn't working for me. The image I'm trying to build is > core-image-gtk-directfb. The recipe is in meta/recipes-graphics/images. If > I just type "bitbake -k core-image-gtk-directfb", I get two errors: > > ERROR: Nothing PROVIDES 'core-image-gtk-directfb' > ERROR: core-image-gtk-directfb was skipped: FEATURE "x11" is in > DISTRO_FEATURES, Please remove "x11" from DISTRO_FEATURES, use > "gtk-directfb" instead of it > > I don't understand the "Nothing PROVIDES" error. Doesn't a recipe called > x.bb PROVIDE x by default? The second error comes from the bit of Python > in that recipe, which at least proves that it's reading that recipe. > It does, but in this case it 'skips' itself, telling bitbake it's not available to be built given the current context, hence isn't provided by that recipe. If I type "bitbake -e core-image-gtk-directfb", I just get the first > error. This happens almost instantly, before it's done any real work, so > I'm not getting any further output. It's raising that error to bitbake in the parsing process, unfortunately, which means it can't be used as a target even for informational purposes like -e. To look at a global variable like DISTRO_FEATURES, use bitbake -e without any arguments. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to find the source of a variable value?
On Mon, Sep 16, 2013 at 10:02 AM, Paul D. DeRocco wrote: > This image recipe has some Python that complains because "x11" is in > DISTRO_FEATURES. How do I find out where that "x11" is coming from? This > is a Gumstix build, so I suspect it's indirectly related to my selecting > "overo" as the MACHINE, because otherwise building this image would never > have worked with the plain Yocto meta-data. So how do I track this down? > Assuming you're using recent metadata, bitbake -e somerecipe will show you this. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Bitbake on live (uncommitted) code
On Thu, Sep 12, 2013 at 4:53 PM, Brad Litterell wrote: > I've grown to really appreciate bitbake for compiling code from a myriad > of sources, however, what is the recommended course for source I am > currently doing live development on? My code base lives in a couple of git > repos that do NOT map one-to-one with recipes and I don't really want to > store the source mixed in with the recipe meta data anyway, nor do I want > to be forced to commit it to git just to do a build. > > Currently I run a pre-bitbake script that creates a tarball out of the > source, but that is easy to forget and makes building a new image a two > step proces. Since it is a build step I'd like it to be done by bitbake. > > Is there a recommended way to go about this? > See externalsrc.bbclass. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to tweak a build with a setup.cfg file
On Mon, Aug 19, 2013 at 11:40 PM, Paul D. DeRocco wrote: > I suspect what happened is that support for the "subdir=" option on local > files was added in 2009, then someone thought, why have this obscure > syntax? Simpler to impose the directory structure on the local files in > the metadata, allow file:// to refer to any pathname, not just a filename, > and have the file copy routine create any necessary subdirectories in the > build tree. So they took that option out. Just a guess. > We've always supported directories in file:// uris. The unpacking process was moved from base.bbclass into the bitbake fetchers. See https://github.com/openembedded/bitbake/blob/master/lib/bb/fetch2/__init__.py#L1234-L1240. Not sure why it didn't work for you, though. I'm guessing it has to do with the way it changes the current working directory before running the command, rather than directly altering the destination directory — if the command being run uses an absolute path, the current working directory wouldn't affect anything. *shrug* -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to tweak a build with a setup.cfg file
On Mon, Aug 19, 2013 at 3:52 PM, Paul D. DeRocco wrote:
> I'm trying to build python-matplotlib from the Danny branch of
> meta-openembedded/meta-oe/recipes-devtools/python. I need to add a
> setup.cfg file to tweak the build, but I don't know how to get it into the
> right place.
>
> I put the setup.cfg into a python-matplotlib subdirectory in my recipes
> directory, and added a python-matplotlib_1.1.0.bbappend file which
> contains the following lines:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> PRINC := "${@int(PRINC) + 2}"
> SRC_URI += "file://setup.cfg"
>
> The file is being copied into
> .../work/armv7a-vfp-neon-poky-linux-gnueabi/python-matplotlib-1.1.0-r3
> rather than
> .../work/armv7a-vfp-neon-poky-linux-gnueabi/python-matplotlib-1.1.0-r3/mat
> plotlib-1.1.0 where it needs to be. How do I push it down a level?
>
By default, anything in SRC_URI goes into ${WORKDIR}, not ${S}. You should
be able to change this like so:
SRC_URI += "file://setup.cfg;subdir=matplotlib-${PV}"
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] can not build yocto on NFS mounted NAS
On Thu, Aug 8, 2013 at 6:57 AM, Robert Berger < gm...@reliableembeddedsystems.com> wrote: > Is it like this by design, or should I file a bug in bugzilla? > > Previous experiments (only SSTATE and DL from NFS/NAS) seem to work and > I guess that's also your autobuilder cluster setup. > TMPDIR on NFS has never been supported with oe/yocto, and I doubt it will be at any time in the near future, but if that's changed, I'm sure someone will jump into the thread and mention it. As you say, SSTATE_DIR and DL_DIR work fine there. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] easiest way to add opkg and all .ipk data to core-image-minimal?
On Mon, Aug 5, 2013 at 1:19 PM, Robert P. J. Day wrote:
> i should know this but, if i don't want to define a new image, what
> is the canonical way to add "opkg" and full ipk data to a stock build
> of, say, core-image-minimal? i can see that what i'll want is to
> inherit rootfs_ipk in some way, but i'm not sure of the correct way.
>
You should never have to inherit rootfs_ipk. image.bbclass inherits the
appropriate rootfs class based on the packaging class(es) you have
inherited and a variable.
>From what I can recall, you'd need to add "package-management" to its
IMAGE_FEATURES, or copy and modify its IMAGE_INSTALL to include
${ROOTFS_PKGMANAGE} rather than ${ROOTFS_PKGMANGE_BOOTSTRAP}.
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] External toolchain (sourcery)
On Wed, Jul 24, 2013 at 1:55 PM, Brian Hutchinson wrote: > On Wed, Jul 24, 2013 at 10:49 AM, Laszlo Papp wrote: > >> is this officially supported by the Yocto project? I would not like to >> use Yocto for my own purposes if it is something unsupported, and I would >> need to put a significant investment into to it to make the releases >> buildable, et cetera. >> > I'm not certain as to the official Yocto support stance on external-sourcery as it exists in or-core at this time, but if you do want to use the Sourcery G++ toolchain rather than one of the alternatives suggested by others in this thread, you can use the meta-sourcery layer, which while it isn't officially supported by Yocto, is officially supported by Mentor Graphics, the company which provides the aforementioned toolchain. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake-env
On Thu, Jul 11, 2013 at 9:25 AM, Trevor Woerner wrote: > Has anyone tried using the bitbake-env utility lately? > > On master I get: > $ bitbake-env > Traceback (most recent call last): > File "/home/trevor/local/bin/bitbake-env", line 275, in > main(sys.argv[1:]) > File "/home/trevor/local/bin/bitbake-env", line 248, in main > tinfoil = Tinfoil(output=sys.stderr) > File "/home/trevor/local/bin/bitbake-env", line 172, in __init__ > self.config = bb.tinfoil.TinfoilConfig(parse_only=True) > AttributeError: 'module' object has no attribute 'TinfoilConfig' > > but on dylan everything is okay. > bitbake has had some changes recently. Try using the 'show' subcommand of https://github.com/kergoth/bb instead. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sstate-cache hit/miss
On Wed, Jul 3, 2013 at 8:54 PM, Trevor Woerner wrote: > Is there a simple way to determine how well (or not) the sstate-cache > is being hit during a build? > It's not ideal, but we're using http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/classes/buildstats-summary.bbclass at the moment, which displays, at the end of a build, the number of do_populate_sysroot tasks run vs do_populate_sysroot_setscene, as an indicator of what % of recipes were built from scratch. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] External-Sourcery-Toolchain Related Issue
On Thu, May 23, 2013 at 12:39 AM, Rohit2 Jindal
wrote:
> I want to install my existing Toolchain to Yocto Sysroot bypassing default
> yocto toolchain functionality.
>
> ** **
>
> My requirements are
>
> ** **
>
> 1I will download toolchain from my git source ie tar file.
>
> 2I just want to install this toolchain to tmp/sysroot folder in build
> directory skipping compilation step.
>
> ** **
>
> ** **
>
> Steps implemented
>
> ** **
>
> 1 SRC_URI = "file:///home/toolchains_bin.tar"
>
> 2 TCMODE="external-csl"
>
> 3 EXTERNAL_TOOLCHAIN =
> "/home/yocto/poky/build/tmp/work/mips64-poky-linux/external-sourcery-toolchain/GCC-r8/toolchains_bin/mipscross/linux"
>
>
> 4CSL_TARGET_SYS_mips64 = "${TARGET_ARCH}${TARGET_TC_VENDOR}-${TCTYPE}"
>
> 5CSL_TARGET_SYS = "${TARGET_ARCH}${TARGET_TC_VENDOR}-${TCTYPE}"
>
> 6 TARGET_PREFIX = "${CSL_TARGET_SYS_mips64}-"
>
The sourcery toolchain recipe pulls files from a codesourcery / mentor
graphics Sourcery G++ toolchain installed at the EXTERNAL_TOOLCHAIN path.
That SRC_URI will not do anything, and it expects the compiler to be
available at parse time. Basically, the tcmode and recipe for sourcery is
designed for a particular toolchain, not any random one, and is not
structured at this time to allow extraction of a toolchain binary tarball.
You'd have to customize / create your own based on the existing bits, using
them as examples.
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Customize Number of Threads per Task?
On Fri, May 17, 2013 at 1:53 AM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:
> Hi Travis,
>
> On Friday 17 May 2013 00:40:51 Post, Travis wrote:
> > I’ve written a bitbake class that adds a custom task in-between
> do_configure
> > and do_compile, called ‘do_send_to_remote’. Is there any way for Yocto to
> > allow only one instance of this task to run at a time? I know I can set
> > BB_NUMBER_THREADS = 1, but that will slow down everything. Is there a way
> > to do something like: BB_NUMBER_THREADS[do_send_to_remote] = 1?
>
> I don't think we have anything quite like that, but we do have support for
> locking via a "lockfiles" parameter on a task function; e.g. from
> rootfs_rpm.bbclass:
>
> do_rootfs[lockfiles] += "${DEPLOY_DIR_RPM}/rpm.lock"
>
> That should ensure only one instance of the task's code gets to run at a
> time.
>
One could implement this through a custom bitbake scheduler. At one point I
had a scheduler which let you define a task flag to indicate which resource
it predominantly used (cpu, memory, network) and then let you define
per-resource maximum thread counts, but it was extremely naive, and didn't
improve overall performance much :\
--
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] $HOME use in DL_DiR
On Mon, Apr 1, 2013 at 9:31 AM, Rifenbark, Scott M <
scott.m.rifenb...@intel.com> wrote:
> I recently used $HOME as part of a path in the DL_DIR variable in my
> local.conf. This caused bad things to happen during the build. It
> essentially created a "never-ending" directory structure inside my build
> directory and the build failed. I would like place a note in the glossary
> entry for the DL_DIR variable. Can anyone provide some general reasons why
> a user should not use $HOME as part of the DL_DIR path that goes beyond "it
> will break the build"?
$HOME is shell variable syntax, not bitbake. I use ${HOME} safely in my
DL_DIR on a regular basis.
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Autobuilder migration status.
On Mon, Mar 25, 2013 at 2:45 PM, Flanagan, Elizabeth < elizabeth.flana...@intel.com> wrote: > On Thu, Mar 21, 2013 at 8:31 AM, Trevor Woerner > wrote: > > I have looked at the output from a couple builds (nightly-fsl-arm, > > nightly-fsl-ppc, nightly-mips) and had a couple questions. > > > > Running "poky/oe-init-build-env" will produce a > > "build/conf/local.conf", but the nightly builder prefers to puts its > > configurations into "build/conf/auto.conf". Obviously there's nothing > > wrong with this, but I'm wondering why use auto.conf instead of > > local.conf? I'm guessing there's some nugget of information in this > > choice that I'm hoping to discover. > > It's nothing particularly special, except I do it to differentiate an > autogenerated local.conf from the local.conf that is created by > oe-init-build-env. I'm sure there was a different reason for it, but > the commit log never made it over from the o-hand.org svn server so... Yeah, that's basically why auto.conf is supported at all. It was specifically intended to be used for generated content primarily for autobuilders :) -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] BB_DANGLINGAPPENDS_WARNONLY
On Tue, Jan 29, 2013 at 1:58 PM, Rifenbark, Scott M < scott.m.rifenb...@intel.com> wrote: > I can't seem to find any information on this variable other than what was > offered in a bug (https://bugzilla.yoctoproject.org/show_bug.cgi?id=3662) > filed against some stuff in the glossary in general. The information > provided there by Robert P. J. Day says it is handy when layers get out of > sync. > > Can anyone out there offer more information on this variable? Wondering > whether this should be documented in the glossary. > Normally, if bitbake encounters a bbappend whose recipe no longer exists, it treats this condition as fatal. This, as Robert says, often occurs if layers get out of sync. For example, if oe-core bumps a recipe version and the old one no longer exists, but the other layer hasn't updated to the new version yet. It being fatal is a sane default, as it's important to realize when your changes are no longer being applied. The variable you mention changes the behavior to a warning instead. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Bitbake and task offloading onto multiple cloud-based servers
On Fri, Jan 4, 2013 at 2:17 PM, Alex J Lennon wrote: > Where would one start to look in the bitbake code to add this kind of > support in? > See the subclasses of RunQueueExecute in bb.runqueue, this is what executes the tasks. For an idea of how to implement opting in to a different class, see how BB_SCHEDULER is implemented. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Bitbake and task offloading onto multiple cloud-based servers
On Fri, Jan 4, 2013 at 1:56 PM, Alex J Lennon wrote: > Can anybody advise on whether bitbake currently supports offloading of > build tasks onto multiple systems? Perhaps cloud based? > > I'm thinking that it would be more efficient for me if I could bring up > a number of Amazon EC2 servers (or similar) then have bitbake > parallelise the build onto those servers to significantly reduce my > build times? > > I see bitbake supports a level of task parallelisation on a single box. > > Can parallelisation of build onto multiple systems be achieved? > > Is it something that should even be a goal? > It's not supported today. It could be implemented, but nobody has made it a priority and done so. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Specifying different make flags for different tasks.
On Mon, Dec 17, 2012 at 1:36 AM, Alex Gonzalez wrote: > I am using EXTRA_OEMAKE to pass extra flags to make. > > How can I pass different flags for different tasks? > > In this case I am compiling an external kernel module and I need > different make flags for the do_make_scripts and do_compile tasks. If > I set EXTRA_OEMAKE in the recipe, all tasks use the same make flags. > You could use the task- override. E.g.: EXTRA_OEMAKE_append_task-do_compile = " FOO=bar" -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake -c devshell option
On Sun, Dec 9, 2012 at 1:05 PM, Marco wrote: > I was used to work with oe-classic. > When I used oe-classic, often I used the 'devshell' option to try to > compile (make uImage) the kernel with the entire environment set up > correctly. > Now if I do the same procedure with Yocto 8 Danny it does not work. > For example I'm using a default configuration below: > > 1st step > --- > MACHINE="beagleboard" bitbake -c devshell virtual/kernel > > Build Configuration: > BB_VERSION= "1.16.0" > TARGET_ARCH = "arm" > TARGET_OS = "linux-gnueabi" > MACHINE = "beagleboard" > DISTRO= "poky" > DISTRO_VERSION= "1.3" > TUNE_FEATURES = "armv7a vfp neon cortexa8" > TARGET_FPU= "vfp-neon" > meta > meta-yocto > meta-yocto-bsp= "danny:**09031ac2fc0f30ec577ee823fc61ff**0e5d852e21" > > NOTE: Resolving any missing task queue dependencies > NOTE: Preparing runqueue > NOTE: Executing SetScene Tasks > NOTE: Executing RunQueue Tasks > NOTE: Tasks Summary: Attempted 912 tasks of which 912 didn't need to be > rerun and all succeeded. > > > 2nd step just after 1st > > MACHINE="beagleboard" bitbake -c devshell virtual/kernel > > - Devshell starts in a new screen > > $ pwd > ~/yocto-8-danny/poky/build/**tmp/work/beagleboard-poky-** > linux-gnueabi/linux-yocto-3.4.**11+git1+**a201268353c030d9fafe00f2041976** > f7437d9386_1+**449f7f520350700858f21a5554b81c**c8ad23267d-r4.3/linux > > - lauch a kernel build (as I was used to do) > > $ make > scripts/kconfig/conf --silentoldconfig Kconfig > *** > *** Configuration file ".config" not found! > *** > *** Please run some configurator (e.g. "make oldconfig" or > *** "make menuconfig" or "make xconfig"). > *** > make[2]: *** [silentoldconfig] Error 1 > make[1]: *** [silentoldconfig] Error 2 > make: *** No rule to make target `include/config/auto.conf', needed by > `include/config/kernel.**release'. Stop. > > > I would like to find out whether you can still do this and what is the new > way to go > devshell runs with the source tree unpacked and patched. It has never guaranteed that the sources would already be *configured* at that time, either in oe-classic or current. Run a bitbake -c configure virtual/kernel first, or just use -c menuconfig. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bbappending a bbappend
On Sun, Dec 9, 2012 at 9:44 AM, Chris Tapp wrote: > On 9 Dec 2012, at 16:30, Chris Larson wrote: > > On Sun, Dec 9, 2012 at 7:50 AM, Bruce Ashfield < > bruce.ashfi...@windriver.com> wrote: > >> On 12-12-09 5:48 AM, Chris Tapp wrote: >> >>> On 9 Dec 2012, at 04:47, Bruce Ashfield wrote: >>> >>> >>>> >>>> >>>> On Sat, Dec 8, 2012 at 7:54 PM, Chris Tapp >>> <mailto:opensource@keylevel.**com >> wrote: >>>> >>>> On 9 Dec 2012, at 00:11, Chris Larson wrote: >>>> >>>> On Sat, Dec 8, 2012 at 5:07 PM, Chris Tapp >>>>> >>>> <mailto:opensource@keylevel.**com>> >>>>> wrote: >>>>> >>>>> Is it possible to have more than one bbappend applied to a >>>>> recipe? >>>>> >>>>> I'm using meta-cedartrail with my own layer (which is set as >>>>> lower priority). >>>>> >>>>> Meta-cedartrail has a linux-yocto_3.0.bbappend, but I want to >>>>> be able to enable CONFIG_HID_APPLE in my layer so my Apple >>>>> keyboard works (and keep meta-cedartrail 'clean'). Is it >>>>> possible to use another linux-yocto_3.0.bbappend in my layer? >>>>> I've given it a try, but it's not working and I thought it >>>>> would be an idea to see if it __should__ before I try and fix >>>>> it ;-) >>>>> >>>>> >>>>> All bbappends from all layers are applied, in layer priority order. >>>>> >>>> >>>> Thanks, I was hoping that was the case. >>>> >>>> I wonder why this isn't working then - I think I've done it as >>>> shown in the dev manual... >>>> >>>> >>>> Is it something other than the bbappends ? i.e. are you sure you have >>>> all the required >>>> dependencies for CONFIG_HID_APPLE already enabled, or in the same >>>> fragment >>>> you are appending ? >>>> >>> >>> menuconfig shows that the dependencies are ok. I've got a single >>> fragment referenced using a SRC_URI in the bbappend which sets >>> FILESEXTRAPATHS_prepend. The .cfg file just sets: >>> >>> CONFIG_HID_APPLE=y >>> >>> I can't find my .cfg file in the work area, so it seems as if it's not >>> being picked up. >>> >> > I'd suggest putting your .bbappend on a pastebin so we can inspect it. > > > Please see http://pastebin.com/EnesrEN0 > Did you use bitbake -e linux-yocto | grep SRC_URI= to confirm it's listed there? -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bbappending a bbappend
On Sun, Dec 9, 2012 at 7:50 AM, Bruce Ashfield wrote: > On 12-12-09 5:48 AM, Chris Tapp wrote: > >> On 9 Dec 2012, at 04:47, Bruce Ashfield wrote: >> >> >>> >>> >>> On Sat, Dec 8, 2012 at 7:54 PM, Chris Tapp >> <mailto:opensource@keylevel.**com >> wrote: >>> >>> On 9 Dec 2012, at 00:11, Chris Larson wrote: >>> >>> On Sat, Dec 8, 2012 at 5:07 PM, Chris Tapp >>>> >>> <mailto:opensource@keylevel.**com>> >>>> wrote: >>>> >>>> Is it possible to have more than one bbappend applied to a >>>> recipe? >>>> >>>> I'm using meta-cedartrail with my own layer (which is set as >>>> lower priority). >>>> >>>> Meta-cedartrail has a linux-yocto_3.0.bbappend, but I want to >>>> be able to enable CONFIG_HID_APPLE in my layer so my Apple >>>> keyboard works (and keep meta-cedartrail 'clean'). Is it >>>> possible to use another linux-yocto_3.0.bbappend in my layer? >>>> I've given it a try, but it's not working and I thought it >>>> would be an idea to see if it __should__ before I try and fix >>>> it ;-) >>>> >>>> >>>> All bbappends from all layers are applied, in layer priority order. >>>> >>> >>> Thanks, I was hoping that was the case. >>> >>> I wonder why this isn't working then - I think I've done it as >>> shown in the dev manual... >>> >>> >>> Is it something other than the bbappends ? i.e. are you sure you have >>> all the required >>> dependencies for CONFIG_HID_APPLE already enabled, or in the same >>> fragment >>> you are appending ? >>> >> >> menuconfig shows that the dependencies are ok. I've got a single >> fragment referenced using a SRC_URI in the bbappend which sets >> FILESEXTRAPATHS_prepend. The .cfg file just sets: >> >> CONFIG_HID_APPLE=y >> >> I can't find my .cfg file in the work area, so it seems as if it's not >> being picked up. >> > I'd suggest putting your .bbappend on a pastebin so we can inspect it. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bbappending a bbappend
On Sat, Dec 8, 2012 at 5:54 PM, Chris Tapp wrote: > On 9 Dec 2012, at 00:11, Chris Larson wrote: > > On Sat, Dec 8, 2012 at 5:07 PM, Chris Tapp wrote: > >> Is it possible to have more than one bbappend applied to a recipe? >> >> I'm using meta-cedartrail with my own layer (which is set as lower >> priority). >> >> Meta-cedartrail has a linux-yocto_3.0.bbappend, but I want to be able to >> enable CONFIG_HID_APPLE in my layer so my Apple keyboard works (and keep >> meta-cedartrail 'clean'). Is it possible to use another >> linux-yocto_3.0.bbappend in my layer? I've given it a try, but it's not >> working and I thought it would be an idea to see if it __should__ before I >> try and fix it ;-) >> > > All bbappends from all layers are applied, in layer priority order. > > > Thanks, I was hoping that was the case. > > I wonder why this isn't working then - I think I've done it as shown in > the dev manual... > Try making use of bitbake-layers show-appends (iirc) -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bbappending a bbappend
On Sat, Dec 8, 2012 at 5:07 PM, Chris Tapp wrote: > Is it possible to have more than one bbappend applied to a recipe? > > I'm using meta-cedartrail with my own layer (which is set as lower > priority). > > Meta-cedartrail has a linux-yocto_3.0.bbappend, but I want to be able to > enable CONFIG_HID_APPLE in my layer so my Apple keyboard works (and keep > meta-cedartrail 'clean'). Is it possible to use another > linux-yocto_3.0.bbappend in my layer? I've given it a try, but it's not > working and I thought it would be an idea to see if it __should__ before I > try and fix it ;-) > All bbappends from all layers are applied, in layer priority order. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FILESEXTRAPATHS needs to be explained *way* better
On Thu, Dec 6, 2012 at 4:16 PM, Robert P. J. Day wrote: > ok, that's just silly (but that could be the 9% quebec beer > talking). if i'm working with just one layer, then this: > > FILESEXTRAPATHS_prepend := "rday" > > works fine: > > FILESPATH="rday/linux-gnueabi:rday/arm:rday/build-linux:rday/pn-netbase:... > > if that fails with more than one layer, then that is, quite simply, > asinine. > I really don't see why you're failing to grasp such a basic concept as a colon separated variable. Do you think you can add something to PATH without adding a colon? -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FILESEXTRAPATHS needs to be explained *way* better
On Thu, Dec 6, 2012 at 3:49 PM, Gary Thomas wrote:
> On 2012-12-06 15:32, Robert P. J. Day wrote:
>
>> On Thu, 6 Dec 2012, Chris Larson wrote:
>>
>>
>>>
>>> On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day
>>> wrote:
>>> in addition, there is absolutely no need to add a ":" to the
>>> value
>>>as the processing adds that for you, so the many, many examples of
>>>
>>>FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>
>>>is potentially confusing to folks reading the code. (that
>>> trailing
>>>":" doesn't hurt, but it has no value.)
>>>
>>>
>>> This is wrong. You only don't need the leading : if FILESEXTRAPATHS
>>> was empty to begin with, which is only the case if that is the first
>>> and only bbappend adding to it. As soon as you get more than one,
>>> you'll end up with concatenated values and no separator.
>>>
>>
>>i'm confused, not sure what this means. what is the *proper* usage
>> of that variable?
>>
>
> I think Chris means you don't need ":=", you should just use "="
>
No, := is required whenever you use THISDIR in a bbappend, unless you
*really* mean the path to the recipe itself, which is unlikely. THISDIR
evaluates based on FILE, which resolves to the current file being parsed,
at the time it's expanded.
Bottom line, what you are trying to create is something that looks like
> this:
> FILESEXTRAPATHS = "some_path:some_other_path:**even_another_path:"
> so the ":" at the end of the expression should always be there.
Right :)
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FILESEXTRAPATHS needs to be explained *way* better
On Thu, Dec 6, 2012 at 3:32 PM, Robert P. J. Day wrote:
> On Thu, 6 Dec 2012, Chris Larson wrote:
>
> >
> >
> > On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day
> wrote:
> > in addition, there is absolutely no need to add a ":" to the
> value
> > as the processing adds that for you, so the many, many examples of
> >
> > FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> >
> > is potentially confusing to folks reading the code. (that trailing
> > ":" doesn't hurt, but it has no value.)
> >
> >
> > This is wrong. You only don't need the leading : if FILESEXTRAPATHS
> > was empty to begin with, which is only the case if that is the first
> > and only bbappend adding to it. As soon as you get more than one,
> > you'll end up with concatenated values and no separator.
>
> i'm confused, not sure what this means. what is the *proper* usage
> of that variable?
As I'm pretty sure you've already been told in one of the other 2 threads
about this, it's a colon separated list of paths. If you go appending to it
without a separator, you're going to end up with something useless.
layer1/.../foo.bbappend
FILESEXTRAPATHS_prepend = "${THISDIR}/foo"
layer2/.../foo.bbappend
FILESEXTRAPATHS_prepend = "${THISDIR}/bar"
resulting FILESEXTRAPATHS: layer1/.../foo/layer2/.../bar
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FILESEXTRAPATHS needs to be explained *way* better
On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day wrote:
> in addition, there is absolutely no need to add a ":" to the value
> as the processing adds that for you, so the many, many examples of
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> is potentially confusing to folks reading the code. (that trailing
> ":" doesn't hurt, but it has no value.)
>
This is wrong. You only don't need the leading : if FILESEXTRAPATHS was
empty to begin with, which is only the case if that is the first and only
bbappend adding to it. As soon as you get more than one, you'll end up with
concatenated values and no separator.
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] how to write a shell command in local.conf
On Wed, Oct 31, 2012 at 7:52 PM, Liu wrote:
> HOST_ARCH:="${@os.popen('/usr/bin/gcc -dumpmachine | sed -e s\'/-.*//\' \
> -e \'s/sparc.*/sparc/\' \
> -e \'s/arm.*/arm/g\' \
> -e \'s/m68k.*/m68k/\' \
> -e \'s/ppc/powerpc/g\' \
> -e \'s/v850.*/v850/g\' \
> -e \'s/sh[234]/sh/\' \
> -e \'s/mips-.*/mips/\' \
> -e \'s/mipsel-.*/mipsel/\' \
> -e \'s/cris.*/cris/\' \
> -e \'s/i[3-9]86/i386/\'').read()}"
> Then I came up with a problem,I can see the variable HOST_ARCH changed to
> "i386" using "bitbake -e | grep HOST_ARCH",but when I bitbake busybox ,it
> says :
> ERROR: Unable to determine endianness for architecture 'i386| ETA:
> --:--:--
> '
You forgot to strip off the trailing newline. Use read().rstrip(). You
may also want to use bb.process or oe.process rather than os.popen.
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] the use of the files in meta/lib
On Tue, Oct 23, 2012 at 6:39 PM, Liu wrote: > I'm wondering the function of the directory meta/lib.I suspect the > files are imported as modules by .bbclass.Is there any good reference docs > about the python files in the directory ? They can be used by any python anywhere in the metadata. Some of its modules are automatically imported for all to use at any time, some are not. See base.bbclass and the OE_IMPORTS variable to see which are auto-imported. The only docs on them, as far as I know, is the code itself. There isn't a great deal of code, so I'd suggest perusing it directly. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] openssl-native doesn't play nice with sstate (mirrors)?
On Fri, Oct 19, 2012 at 9:03 AM, Jerrod Peach wrote: > In this case, it seemed openssl wanted to find a config to its original > build location, but it wasn't allowed to find it in this case, because that > directory was owned by a different user. Grepping through the binary and > openssl's *.so files, I found a ton of references to the original build > directory. I was finally able to get around this behavior by setting a > couple of environment variables to point to the current directory of the > binary (namely, OPENSSLDIR and OPENSSL_CONF), but is this expected behavior? > Is there some workaround that gets prevents the user of openssl-native from > having to set those environment variables? Or, is this a bug in the way > openssl-native is built? I'd suggest adding a create_wrapper call to the recipe to emit a shell script wrapper which sets those variables, then the standard sstate sed'ing of the sysroot path will occur to the wrapper, and it will always work. We do this in a number of other recipes to work around relocation issues. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.3_M5.rc2 status.
On Wed, Sep 26, 2012 at 11:36 AM, Wolfgang Denk wrote: >> By "better way to deal with these", what would you suggest? I don't see any >> alternative that avoids the BSP components just disappearing for users who >> have existing configurations. > > Well, the comment in "meta-yocto/conf/bblayers.conf.sample" says: > > # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf > # changes incompatibly > > This suggests that such changes are not exactly unusual. But any such > change will cause the build to fail, because the sanity checker uses a > different value. This is wrong. A compatibility break in bblayers.conf is *extremely* rare. > If such a change is allowed and is done intentionally, then it should > be considered "sane", and the sanity checker should not complain. Wrong. The user has to know that they may need to change their bblayers.conf to match the upstream structure. If it didn't complain, they could silently break or encounter unexpected behavior. > The problem (and the longer I think about it the less I hesitate to > call it a plain bug) is that we allow for meta layer specific values > of LAYER_CONF_VERSION, while still assuming a single hard-coded > value in meta/conf/sanity.conf could be used as reference. > > This _cannot_ work. > > But when I'm supposed to overwrite the setting (to match the sanity > checker's expectations) in my local conf/bblayers.conf, then why do we > bother to set a dieferent value in the meta layer in the first place? > And hey, why do we check this value at all if all we can do is always > make it match manually? Not everyone using oe-core (meta) also uses meta-yocto. Only those using the latter were affected by this particular upstream structure change. > I understand the intention, but the current implementation is just > broken, and I don't see a way to fix it. It would probably be better > to remove this test than to leave it as is. Again, that'd leave the user with a bblayers.conf that may no longer do what they intended it to do. Better to fail than potentially build in ways not matching the user's previous expectations. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.3_M5.rc2 status.
On Wed, Sep 26, 2012 at 7:20 AM, Wolfgang Denk wrote: > In message <2428256.OTjtN2nWn5@helios> you wrote: >> >> > Ah, OK. Well, I decided to update meta/conf/sanity.conf to have a >> > matching value of LAYER_CONF_VERSION, so this is solved. >> >> That will work, but normally you would edit conf/bblayers.conf, since >> meta/conf/sanity.conf is part of the metadata. > > Well, what is the rationale for setting LAYER_CONF_VERSION=6 in > meta-yocto/conf/distro/poky.conf, then? > > If meta layer specific values of LAYER_CONF_VERSION are allowed, the > sanity checker needs a better way to deal with these; alternatively, > above setting in meta-yocto/conf/distro/poky.conf is wrong. So either > of these should be fixed. They're both set exactly the way they should be. You're only affected by the bblayers compatibility change if you use poky, as far as I'm aware. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [linux-yocto] 'bitbake linux-yocto' after 'bitbake linux-yocto -c compile -f' does not create image
On Wed, Sep 12, 2012 at 8:06 AM, Rudolf Streif wrote: > bitbake linux-yocto -c compile -f > bitbake linux-yocto > > worked perfectly fine. The tasks after compile were rerun and the new kernel > copied to tmp/deploy/images > > In Edison 7.0.1 this does not seem to work anymore. The tasks do not rerun > and the kernel image is not deployed. I'd suggest using bitbake's new -C argument. Run bitbake -C compile linux-yocto. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] of recipes and packages
On Thu, Aug 23, 2012 at 11:02 AM, Trevor Woerner wrote: > On Thu, Aug 23, 2012 at 3:14 AM, Paul Eggleton > wrote: >> In this >> instance we can change it very easily in the BitBake help text and we should >> do so. > > So should I send in a patch against the Yocto Project's > poky/bitbake/bin/bitbake or try to have it accepted upstream? As I already said once in this thread, bitbake-devel is the correct place for it to go. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] of recipes and packages
On Wed, Aug 22, 2012 at 1:15 PM, Trevor Woerner wrote: > On Wed, Aug 22, 2012 at 3:24 PM, Chris Larson wrote: >> On Wed, Aug 22, 2012 at 12:23 PM, Trevor Woerner wrote: >>> "bitbake -s" doesn't list "net-snmp-dbg net-snmp-doc net-snmp-dev..." >>> it lists "net-snmp". Therefore couldn't the wording of the bitbake >>> help be improved to say: >>> >>> -s, --show-versions show current and preferred versions of all __recipes__ >>> >>> instead of: >> >> >> It could, and should, be changed in that way, yes. > > Do the OE people accept this wording too, or is this a > yocto-project-only thing? In other words, should a potential patch be > sent to OE or here? The change would be to a core component, which is part of OE and which yocto pulls in — bitbake. So it would make no sense to send the patch here. No changes to bitbake are going into poky without going into the main bitbake repository. The bitbake-devel mailing list is the correct place for it. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] of recipes and packages
On Wed, Aug 22, 2012 at 12:23 PM, Trevor Woerner wrote: > On Wed, Aug 22, 2012 at 1:15 PM, Jeff Osier-Mixon wrote: >> In this case, bitbake is looking for the expiration dates on your >> ingredients - the version of the package that each recipe builds. > > But your wording would seem to imply _a_ recipe builds _a_ package. > But a recipe doesn't build a package, a recipe potentially builds lots > of packages. For example the "net-snmp" recipe builds the following > packages: "net-snmp-dbg net-snmp-doc net-snmp-dev net-snmp-staticdev > net-snmp-static net-snmp-libs net-snmp-mibs net-snmp-server > net-snmp-client" > > "bitbake -s" doesn't list "net-snmp-dbg net-snmp-doc net-snmp-dev..." > it lists "net-snmp". Therefore couldn't the wording of the bitbake > help be improved to say: > > -s, --show-versions show current and preferred versions of all __recipes__ > > instead of: It could, and should, be changed in that way, yes. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary
On Tue, Aug 21, 2012 at 12:05 PM, Saxena, Rahul wrote:
> You are right, these are regular files and not symlinks and are ending up in
> usr/lib in packagename-dev package
> However I want them to be in the regular package.
>
> I do have the following statement in my recipe:
>
> FILES_${PN} += "${libdir}/lib*.so"
>
> and nothing in my recipe has statements such as FILES_${PN)-dev = ...
Read oe-core/meta/conf/bitbake.conf.
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Installing Kernel Modules
On Sun, Aug 19, 2012 at 6:53 AM, Seth Bollinger wrote: > I currently have a modules*.tgz in my tmp/images/deploy directory that > contains all of the kernel modules built. What's the yocto way to pull only > the modules I care about into the rootfs image? Every kernel module gets split out into its own binary package. Inspect tmp/deploy/ipk/*/kernel-module-*.ipk, for example, if you're using package_ipk. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] knotty2
On Sat, Aug 18, 2012 at 4:09 AM, Trevor Woerner wrote: > Wow! The new cmdline interface (which I assume is knotty2?) is > _really_ impressive! It was knotty2, yeah, but that functionality was merged into the default UI, so it's just knotty now :) Agreed, Richard did a good job on it. It's a simple change, really, but one with great impact on usability. It makes it much easier to spot real warnings/errors, since you don't have to dig through the spam. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RFC: OE-Core task rework
On Wed, Aug 15, 2012 at 11:01 AM, Mark Hatle wrote: >> if we rename tasks to package groups, and there's a question as to how >> IMAGE_FEATURES scales - should every task be represented in there or only >> a >> select list? Would we be better off not trying to bring any tasks in via >> IMAGE_FEATURES at all and mostly leave that to control post-processing >> (e.g. >> package-management, debug-tweaks, etc.)? > > > I'd certainly prefer that images were limited to selecting software from > task (group) recipes only, and not providing their own. An image should be > able to change the selection based on an "image feature" or similar > configuration, but the underlying tasks/groups, recipes, etc should all be > 'generic' to a given distribution configuration. The package groups which can be added in IMAGE_FEATURES don't have to be (and I'd argue against it anyway) defined in the image. For Mentor, we define them in our distro configuration. That said, what we use them for is basically the same thing the tasks in oe-core/meta-oe already provide, so we're looking to transition away from that method to what upstream is using (tasks, or whatever we end up using at the end of this discussion). -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Over-riding insane LDFLAGS check
On Sun, Aug 12, 2012 at 10:10 AM, Elvis Dowson wrote: > > On Aug 12, 2012, at 8:20 PM, Chris Larson wrote: > >> On Sun, Aug 12, 2012 at 9:17 AM, Elvis Dowson wrote: >>> >>> On Aug 12, 2012, at 8:14 PM, Chris Larson wrote: >>> >>>> On Sun, Aug 12, 2012 at 4:45 AM, Elvis Dowson >>>> wrote: >>>>> Is there anyway I can over-ride the insane LDFLAGS check for >>>>> GNU_HASH? >>>> >>>> Remove it from ERROR_QA and (optionally) add it to WARN_QA instead. If >>>> you're using an external toolchain, see what I did at >>>> https://github.com/MentorEmbedded/meta-sourcery/blob/master/conf/distro/include/tcmode-external-sourcery.inc#L91-98 >>>> for this one. >>> >>> How would I go about hooking, in a single location, so that if I run >>> gcc-4.5, it over-rides it completely, but if I specify gcc-4.6 or 4.7 it >>> doesn't get over-ridden? >> >> Use INSANE_SKIP. Grep the metadata for examples. Specifically, >> INSANE_SKIP_ = "ldflags". > > While I was developing the gcc-4.5 recipe against the current poky master, I > first started adding INSANE_SKIP_ = "ldflags". For a couple of > recipes, adding that didn't work because of the way the name was setup !! I > think it was gnutls. So, I ended up having to temporarily disable the entire > LDFLAGS check, for the gcc-4.5 build. Then you're doing something wrong. Find that and fix it. INSANE_SKIP is the correct mechanism to use in this situation. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Over-riding insane LDFLAGS check
On Sun, Aug 12, 2012 at 9:17 AM, Elvis Dowson wrote: > > On Aug 12, 2012, at 8:14 PM, Chris Larson wrote: > >> On Sun, Aug 12, 2012 at 4:45 AM, Elvis Dowson wrote: >>> Is there anyway I can over-ride the insane LDFLAGS check for >>> GNU_HASH? >> >> Remove it from ERROR_QA and (optionally) add it to WARN_QA instead. If >> you're using an external toolchain, see what I did at >> https://github.com/MentorEmbedded/meta-sourcery/blob/master/conf/distro/include/tcmode-external-sourcery.inc#L91-98 >> for this one. > > How would I go about hooking, in a single location, so that if I run gcc-4.5, > it over-rides it completely, but if I specify gcc-4.6 or 4.7 it doesn't get > over-ridden? Use INSANE_SKIP. Grep the metadata for examples. Specifically, INSANE_SKIP_ = "ldflags". -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Over-riding insane LDFLAGS check
On Sun, Aug 12, 2012 at 4:45 AM, Elvis Dowson wrote: >Is there anyway I can over-ride the insane LDFLAGS check for > GNU_HASH? Remove it from ERROR_QA and (optionally) add it to WARN_QA instead. If you're using an external toolchain, see what I did at https://github.com/MentorEmbedded/meta-sourcery/blob/master/conf/distro/include/tcmode-external-sourcery.inc#L91-98 for this one. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] under what circumstances is BBCLASSEXTEND = "native" required in a recipe?
On Sat, Aug 11, 2012 at 12:30 PM, Robert P. J. Day wrote: > p.s. i'm still wondering if there's a convenient way to identify > utilities on the dev host that are candidates for ASSUME_PROVIDED. > surely a relatively recent version of subversion would be adequate, > but how would one actually *know* that? This gets brought up pretty regularly, and the answer is it's a pain to know when it can be done. Getting a successful build doesn't necessarily mean you can get away with whatever it was you added to ASSUME_PROVIDED, because it just means you didn't try to build something that required X feature that isn't in version Y of the software. Basically you can arrange something like that, but you'd never be supported in your efforts, because it could always break sometime. For what it's worth, I do something like that in most of my builds, and it has only rarely caused any problems. I can show you what I use if you'd like, but again it's buyer^Wbuilder beware :) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] under what circumstances is BBCLASSEXTEND = "native" required in a recipe?
On Sat, Aug 11, 2012 at 11:32 AM, Robert P. J. Day wrote: > On Sat, 11 Aug 2012, Chris Larson wrote: > >> On Sat, Aug 11, 2012 at 10:03 AM, Robert P. J. Day >> wrote: >> > however, the "chrpath" command is not listed in bitbake as part of >> > ASSUME_PROVIDED, and its recipe includes the line >> > >> > BBCLASSEXTEND = "native" >> > >> > that's what's confusing -- if the QS guide demands that the user >> > install "chrpath" manually, what is the subsequent value of its recipe >> > dictating that it be natively buildable? >> >> At a guess, it's possible that not all recipes that needed >> chrpath-native had an explicit dependency on it, or similar. Your >> question is specific to chrpath, not at all general to >> BBCLASSEXTEND. Adding native to bbclassextend means that a -native >> version of the recipe can be built. The question of why certain >> things are expected on the host vs built from that recipe is an >> entirely different one. > > i believe i see your logic. just to clarify, it seems somewhat > redundant to a) *require* the developer to manually install certain > commands on the yocto dev host, and b) simultaneously have a recipe > for that command that allows it to be built natively, in case yocto > needs it. > > does that make sense? i'm assuming the sole reason to support a > -native build in a recipe is for yocto use on the dev host, right? > > rday > > p.s. as a more obvious example, consider "git". it's now > "ASSUME_PROVIDED", and listed in the quick start guide as required on > the dev host, but it also still supports a native build. i'm just > trying to clarify that, in cases like that, supporting the -native > build is no longer necessary. or am i missing something? Supporting it isn't necessary, this is true, but we do want to remove as many hard host dependencies as possible over time, no? Perhaps the bbclassextend only exists to prepare for such a point. Also, having a -native available doesn't *harm* anything. At most it slightly increases ram usage up front when it produces the second variation of the recipe. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] under what circumstances is BBCLASSEXTEND = "native" required in a recipe?
On Sat, Aug 11, 2012 at 10:03 AM, Robert P. J. Day wrote: > however, the "chrpath" command is not listed in bitbake as part of > ASSUME_PROVIDED, and its recipe includes the line > > BBCLASSEXTEND = "native" > > that's what's confusing -- if the QS guide demands that the user > install "chrpath" manually, what is the subsequent value of its recipe > dictating that it be natively buildable? At a guess, it's possible that not all recipes that needed chrpath-native had an explicit dependency on it, or similar. Your question is specific to chrpath, not at all general to BBCLASSEXTEND. Adding native to bbclassextend means that a -native version of the recipe can be built. The question of why certain things are expected on the host vs built from that recipe is an entirely different one. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] external-sourcery-toolchain: ERROR: QA Issue: No GNU_HASH in the elf binary
On Fri, Aug 10, 2012 at 9:37 AM, Elvis Dowson wrote:
> I'm building with the mentor external-sourcery-toolchain.
>
> I get the following error:
>
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipcloak'
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zip'
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipsplit'
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/packages-split/zip/usr/bin/zipnote'
> ERROR: QA run found fatal errors. Please consider fixing them.
> ERROR: Function failed: do_package_qa
> ERROR: Logfile of failure stored in:
> /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/zip-3.0-r1/temp/log.do_package.47453
>
> Adding the following statement to zip.bb doesn't fix the problem, like it
> used to when using the gcc-4.x compilers:
>
> TARGET_CC_ARCH += "${LDFLAGS}"
I have bits that work around this by making the ldflags/gnu_hash check
nonfatal when using this toolchain, but they haven't gone into oe-core
yet. See
https://github.com/MentorEmbedded/meta-sourcery/blob/master/conf/distro/include/tcmode-external-sourcery.inc#L87-94
for details. You should be able to try a build using this layer, or
just grab those bits and put them into your oe-core
tcmode-external-sourcery.inc.
I haven't had time to pursue this meta-sourcery wrt upstream yet, but
I think in the long term it's the best approach for supporting the
sourcery g++ toolchain. I think all we should keep in oe-core is
either a sample/example config, a link to that layer, or a
configuration for a toolchain that doesn't require as much tweaking
(e.g. tuning arguments), such as crosstool-ng. That isn't related to
your issue, but is why I haven't been quite as proactive about pushing
fixes to the tcmode in oe-core recently.
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] external-sourcery-toolchain: ERROR: Function failed: do_install
On Fri, Aug 10, 2012 at 8:59 AM, Elvis Dowson wrote: > I found the solution. I had to specify NO32LIBS = "0", since I'm building on > an Ubuntu 12.04 64-bit machine. > > # Set the toolchain. > TCMODE = "external-csl" > EXTERNAL_TOOLCHAIN = "/tool/mentor/csl-2012.03.71" > NO32LIBS = "0" > CSL_TARGET_SYS_powerpc = "powerpc-mentor-linux-gnu" Yeah, we should probably make the tcmode set that — things get unhappy due to the LD_PRELOAD when it tries to run the 32 bit toolchain binaries without a 32 bit libpseudo around. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Hey where is pythonnative.bbclass
On Thu, Aug 2, 2012 at 5:55 PM, Aditya Gandhi wrote: > I am adding layers from openembedded. Would anyone know here is the > pythonnative.bbclass, some meta-oe depends on it. oe-core. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Help with configuring Yocto with an external toolchain
On Wed, Jul 25, 2012 at 3:20 AM, Sree wrote: > Chris Larson writes: > >> >> On Tue, May 8, 2012 at 2:39 AM, Radha Krishna Srimanthula >> wrote: >> > I have an armv5tej platform for which I need put in place, a toolchain and > a >> > build system. It is in this regard that I need some help: >> > >> > Can Yocto use an external toolchain (we use CodeSourcery)? If so, how do I >> > configure Yocto to use the external toolchain? I went through the > developers >> > and user manuals of Yocto - am not too sure how to go about doing this. Can >> > you please help me with this? >> >> TCMODE = "external-csl" >> EXTERNAL_TOOLCHAIN = "/path/to/sourcery/toolchain" > > > Hi > > I have added TCMODE?= "external-csl" in local.conf & EXTERNAL_TOOLCHAIN > = "/path/to/sourcery/toolchain"(pre-built tool chain) in tcmode-external- > csl.inc i get an error when i try to build. > > ERROR: Execution of event handler 'csl_version_handler' failed > Traceback (most recent call last): > File "csl_version_handler(e)", line 12, in csl_version_handler > (e=) > File "csl-versions.inc", line 4, in csl_get_gdb_version > (d=) > NameError: global name 'CmdError' is not defined You're using old metadata which had a bug. Go to line 4 of csl-versions.inc and change CmdError to bb.process.CmdError. I assume this is a release branch? -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Solved] Re: Error: PATH contains '.' or '', which will break the build, please remove this.
On Wed, Jul 18, 2012 at 6:57 AM, Burton, Ross wrote: > On 18 July 2012 14:46, Chris Larson wrote: >> On Wed, Jul 18, 2012 at 6:37 AM, Burton, Ross wrote: >>> On 18 July 2012 13:13, Burton, Ross wrote: >>>> I'm working on a patch to display the parsed PATH so you'll see the >>>> trailing empty element in that case. >>> >>> How's this? >> >> It's still slightly hard to spot there. I wonder if something like >> this would be easier for the user? >> >> ERROR: Invalid PATH entry at character N: /usr/bin:/bin: > > That would be easier for the user, but harder to implement. :) It'd be something like https://gist.github.com/3136618, no doubt. But the problem is the assumption of the length of the prefix, that is, assumption of the final formatting to the user, which isn't ideal. What we should do, I think, is teach the UI log formatter to indent subsequent lines based on its own prefix, so that "foo\nbar" would show up like this: ERROR: foo bar Rather than: ERROR: foo bar -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Solved] Re: Error: PATH contains '.' or '', which will break the build, please remove this.
On Wed, Jul 18, 2012 at 6:37 AM, Burton, Ross wrote: > On 18 July 2012 13:13, Burton, Ross wrote: >> I'm working on a patch to display the parsed PATH so you'll see the >> trailing empty element in that case. > > How's this? It's still slightly hard to spot there. I wonder if something like this would be easier for the user? ERROR: Invalid PATH entry at character N: /usr/bin:/bin: ^ In other words, formatted like a syntax error. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sysroot / external toolchain
On Fri, Jul 13, 2012 at 2:05 PM, Dallas Clement
wrote:
> Thanks Chris. I was close, just missing the actual copying part from
> the do_install() as observed. ;^)
>
> I got quite a bit further. Am running into issues like this now:
>
> ERROR: QA Issue: No GNU_HASH in the elf binary:
> '/development/dallasc/yocto/poky/build/tmp/work/armv5te-poky-linux-gnueabi/external-marvell-armada-sdk-5.0-64k-toolchain-1.0-r0/packages-split/external-marvell-armada-sdk-5.0-64k-toolchain/usr/bin/gdbserver'
> ERROR: QA Issue: non debug package contains .debug directory:
> external-marvell-armada-sdk-5.0-64k-toolchain path
> /work/armv5te-poky-linux-gnueabi/external-marvell-armada-sdk-5.0-64k-toolchain-1.0-r0/packages-split/external-marvell-armada-sdk-5.0-64k-toolchain/usr/libexec/getconf/.debug/POSIX_V6_ILP32_OFFBIG
INSANE_SKIP_${PN} += "ldflags"
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] sysroot / external toolchain
> I'm using an external toolchain for my project. What is the proper
> way to include my external toolchain libc files in the sysroot?
Use an external toolchain recipe which actually installs the files
from the external sysroot into ${D}, the way the known working
external sourcery toolchain recipe does.
> Currently I have
>
> TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_HOST}"
>
> and
>
> EXTERNAL_TOOLCHAIN_SYSROOT_CMD = "${TARGET_PREFIX}gcc
> ${TARGET_CC_ARCH} -print-sysroot"
> EXTERNAL_TOOLCHAIN_SYSROOT ??= "${@exttc_run(d,
> EXTERNAL_TOOLCHAIN_SYSROOT_CMD)}"
The tcmode sets these already, there's no need to set them explicitly,
just copy the external-sourcery tcmode to your own and set TCMODE
appropriately.
> which resolves to
> /opt/armada-sdk-5.0-64k/armv7-marvell-linux-gnueabi-softfp/arm-marvell-linux-gnueabi/libc/
>
> I also have a recipe for my external toolchain which includes the following:
>
> do_install() {
> # Use optimized files if available
> sysroot="${EXTERNAL_TOOLCHAIN_SYSROOT}"
> }
If this is all you have in do_install, it's no wonder you have no
files. do_install has to actually install the files from t he sysroot.
Copy what's in external-sourcery-toolchain, as that actually works.
> The EXTERNAL_TOOLCHAIN_SYSROOT doesn't seem to have any effect. My
> libc header files are not visible during compilation. It looks like I
> may have to copy them to the staging dir or setup some symlinks. Is
> this the right approach?
No.
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] external toolchain
On Thu, Jul 12, 2012 at 12:20 PM, Dallas Clement wrote: > Should I be modifying this external-sourcery-toolchain recipe to point > to my toolchain sysroot area? Just not sure what all needs to be done > to use my own toolchain. This recipe is intended for use with the sourcery g++ toolchain. It's not at all surprising that it might fail with one from a different vendor. Modify the recipe as appropriate. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/1] ia32-base.inc: also take -dev package of emgd
On Thu, Jul 12, 2012 at 2:35 AM, wrote: > From: Nitin A Kamble > > emgd-driver-bin recipe provides emgd-driver-bin, emgd-driver-bin-dev > & emgd-driver-bin-dbg packages. For emgd driver to work it also need > library files from emgd-driver-bin-dev package. This change makes sure > this -dev package is also added for emgd driver. This seems questionable. If the driver requires those libraries, they should probably be moved out of -dev, no? -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to use PRINC
On Mon, Jul 2, 2012 at 9:00 AM, Markus Hubig wrote:
> PRINC := "${@int(PRINC) + 2}"
This is the correct method to use in a bbappend. Start with 1,
obviously, and bump it each time the bbappend changes.
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] default variables in a python task/function
On Wed, Jun 20, 2012 at 8:46 AM, Joshua Immanuel wrote:
> Hello,
>
> Considering the following code snippet variants of a recipe which does
> the same job, I would like to clarify certain doubts regarding this.
>
> python __anonymous () {
> pn_split = d.getVar('PN', True).split('-')
> ...
> }
>
> python __anonymous () {
> import bb
> pn_split = bb.data.getVar('PN', d, True).split('-')
> ...
> }
>
> In some .bbclass, 'bb' library is used without importing it. I find that
> the 'd' variable is an instance of DataSmart class in the bitbake
> library. Will this 'bb' and 'd' variables be available to all python
> tasks and functions?
'bb' and 'os' are always imported, automatically, by bitbake itself,
and as such are available in all python contexts. 'd' is available in
python tasks and anonymous python functions and in inline python
snippets, but *not* in event handlers. event handlers get their event
passed as 'e'.
> I also find that in global python functions such as 'get_imagecmds'
> defined in image_types.bbclass 'd' is got as a parameter. Can someone
> explain when the 'd' will be initialized? Will the instance of DataSmart
> (i.e the variable 'd') in bbclass differ from that of the recipe which
> inherited that class? In bitbake manual, example of global python
> functions are shown as accepting 'bb' and 'd' variables as its
> parameters. Can someone explain the right way of doing this.
Unlike 'bb' and 'os', 'd' is not available in def'd python functions,
only in tasks and anonymous functions and in inline python snippets.
As such, it needs to be passed in by the caller.
E.g.
def foo(d):
# do something with d
FOO = "${@foo(d)}"
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] checking out branches: tracking vs. tags
On Thu, May 24, 2012 at 8:42 AM, jfabernathy wrote: > On 05/24/2012 11:21 AM, Chris Larson wrote: >> >> On Thu, May 24, 2012 at 7:55 AM, jfabernathy >> wrote: >>> >>> the Development Manual Appendix A >>> >>> (http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#dev-manual-bsp-appendix), >>> I see the statement: >>> >>> $ git checkout denzil-7.0 -b denzil >>> >>> >>> What I think this does is create me a local branch that is fixed to what >>> was >>> committed when the denzil-7.0 tag was created and it will remain that way >>> and will not track the denzil branch as it gets updated. Right >>> >>> Now if I want to track the denzil branch as changes are committed, I >>> think I >>> do the following. >>> >>> $ git checkout origin/denzil -b denzil >>> >>> >>> Now I can do git pull commands to get the updates that are committed. >>> Right?? >> >> Your arguments are backwards. See git help checkout. > > I looked at git help and man git, but it is still unclear because if I do > the first one where I checkout using the tag, I cannot git pull at all; I > get an error, about not enough information to merge. However, if I use the > name of the branch I can now do git pull when changes are committed to > denzil. That's why I thought I understood it. But who knows. You're right, my mistake. Those commands are fine, and your understanding is largely correct. I highly recommend reading Pro Git for further information. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] checking out branches: tracking vs. tags
On Thu, May 24, 2012 at 7:55 AM, jfabernathy wrote: > the Development Manual Appendix A > (http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#dev-manual-bsp-appendix), > I see the statement: > > $ git checkout denzil-7.0 -b denzil > > > What I think this does is create me a local branch that is fixed to what was > committed when the denzil-7.0 tag was created and it will remain that way > and will not track the denzil branch as it gets updated. Right > > Now if I want to track the denzil branch as changes are committed, I think I > do the following. > > $ git checkout origin/denzil -b denzil > > > Now I can do git pull commands to get the updates that are committed. > Right?? Your arguments are backwards. See git help checkout. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Help with configuring Yocto with an external toolchain
On Tue, May 8, 2012 at 2:39 AM, Radha Krishna Srimanthula wrote: > I have an armv5tej platform for which I need put in place, a toolchain and a > build system. It is in this regard that I need some help: > > Can Yocto use an external toolchain (we use CodeSourcery)? If so, how do I > configure Yocto to use the external toolchain? I went through the developers > and user manuals of Yocto - am not too sure how to go about doing this. Can > you please help me with this? TCMODE = "external-csl" EXTERNAL_TOOLCHAIN = "/path/to/sourcery/toolchain" -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Is it not necessary to sudo dpkg-reconfigure dash with Poky 1.2 on Ubuntu 12.04
On Wed, May 2, 2012 at 8:18 AM, Osier-mixon, Jeffrey wrote: > Good catch. I'm still installing 12.04 and can't check at the moment, > but there is an easy way to tell: > > file /bin/sh > > If it points to bash you should be fine, if it points to dash then > you'll need to reconfigure. Please let me know the results and I'll > make sure it gets documented either way. >From discussion on IRC, folks have said /bin/sh being bash is no longer required. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using meta repositories from OpenEmbedded and Yocto projects
On Wed, May 2, 2012 at 7:46 AM, Elvis Dowson wrote: > Can I re-use the meta-openembedded git repositories from > openembedded.org and steve sakoman's meta-sakoman repositories (contains > support for the Gumstix Overo board), and check it out inside a checkout of > the yocto poky git repository, to take advantage of the latest yocto and > openembedded recipes and build it for the Gumstix Overo board? > > for example: > > poky > meta-openembedded (from git://git.openembedded.org/meta-openembedded) > meta-openembedded-contrib (from git://git.openembedded.org/meta-openembedded-contrib) > meta-sakoman.git (from git://www.sakoman.com/git/meta-sakoman) > > I've used OpenEmbedded before, and this is my first time with Yocto, and I > see a bunch of meta-* repositories, and was wondering if including them > inside the main poky folder was the way to go, to add additional support > from various sources. Where the layers are doesn't matter. Put them wherever you want them, just ensure you add their paths to build/conf/bblayers.conf's BBLAYERS variable. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project 1.2 Release Status
On Wed, Apr 18, 2012 at 10:02 AM, Richard Purdie wrote: > On Wed, 2012-04-18 at 09:22 -0700, Chris Larson wrote: >> On Wed, Apr 18, 2012 at 8:20 AM, Richard Purdie >> wrote: >> > On Wed, 2012-04-18 at 16:53 +0200, Martin Jansa wrote: >> >> On Wed, Apr 18, 2012 at 03:47:47PM +0100, Richard Purdie wrote: >> >> > I thought I'd update everyone with the current 1.2 status. >> >> > >> >> > I'm going to branch master for release at this point. We've fixed a lot >> >> > of issues, I'm hoping the -rc4 build will be a good one. There are signs >> >> > there are some more minor issues around and bugs do keep getting opened. >> >> > These are still being investigated so we'll continue to let that happen. >> >> > Once we have a QA report for -rc4, we'll be in a better position to make >> >> > a call on how things are looking. >> >> >> >> Does it mean that after creating branch, master will be open for >> >> postponed patches from ML and master-next or do you want to keep master >> >> as close to release branch as possible for some time (e.g. for those >> >> 1.2.1 fixes)? >> > >> > I have hoped people would work more on the stabilisation and testing but >> > I don't think I'll be able to hold off the pressure to start master >> > rolling again at some point relatively soon. >> >> Just because people have things to push or are pushing things which >> aren't bugfixes doesn't mean their time is being taken up by anything >> but stabilization right now. Your statement implies that everything >> being pushed is being currently worked on, which is incorrect. I'm >> sure Mentor isn't the only company with a backlog of already complete >> local changes to get upstream.. > > So you're saying Mentor has been working on stabilization and has a > queue of bugfixes which they've not shared? No, I never said they were just bugfixes. If they were low impact bugfixes, they'd have a shot at making it into the release, especially if they're critical, no? > This doesn't help us much with the quality of this release :/ At least > the next one might benefit I guess assuming you can resolve that backlog > problem... Imagining that every company is going to never have changes that are not yet upstream is a pipe dream. There's often a delay due to time constraints and scheduling. Welcome to the real world. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project 1.2 Release Status
On Wed, Apr 18, 2012 at 10:06 AM, Chris Larson wrote: > On Wed, Apr 18, 2012 at 10:02 AM, Richard Purdie > wrote: >> On Wed, 2012-04-18 at 09:22 -0700, Chris Larson wrote: >>> On Wed, Apr 18, 2012 at 8:20 AM, Richard Purdie >>> wrote: >>> > On Wed, 2012-04-18 at 16:53 +0200, Martin Jansa wrote: >>> >> On Wed, Apr 18, 2012 at 03:47:47PM +0100, Richard Purdie wrote: >>> >> > I thought I'd update everyone with the current 1.2 status. >>> >> > >>> >> > I'm going to branch master for release at this point. We've fixed a lot >>> >> > of issues, I'm hoping the -rc4 build will be a good one. There are >>> >> > signs >>> >> > there are some more minor issues around and bugs do keep getting >>> >> > opened. >>> >> > These are still being investigated so we'll continue to let that >>> >> > happen. >>> >> > Once we have a QA report for -rc4, we'll be in a better position to >>> >> > make >>> >> > a call on how things are looking. >>> >> >>> >> Does it mean that after creating branch, master will be open for >>> >> postponed patches from ML and master-next or do you want to keep master >>> >> as close to release branch as possible for some time (e.g. for those >>> >> 1.2.1 fixes)? >>> > >>> > I have hoped people would work more on the stabilisation and testing but >>> > I don't think I'll be able to hold off the pressure to start master >>> > rolling again at some point relatively soon. >>> >>> Just because people have things to push or are pushing things which >>> aren't bugfixes doesn't mean their time is being taken up by anything >>> but stabilization right now. Your statement implies that everything >>> being pushed is being currently worked on, which is incorrect. I'm >>> sure Mentor isn't the only company with a backlog of already complete >>> local changes to get upstream.. >> >> So you're saying Mentor has been working on stabilization and has a >> queue of bugfixes which they've not shared? > > No, I never said they were just bugfixes. If they were low impact > bugfixes, they'd have a shot at making it into the release, especially > if they're critical, no? Further, again you're ignoring previous work. Whether we've been working on stabilization right now is irrelevent given we have previous work to push. Mentor has been using OE for its products for years, to expect that a very small team which has to focus on customer issues is going to catch up on all of that effort in a short period of time is unreasonable. We've been working against our backlog for months, and will continue to do so until we're caught up. The frozen tree just slows that down even more. If you want folks like us working more closely with upstream, then you have to realize that folks are going to have changes to push which aren't bugfixes (or aren't critical), and contrary to your implication, does not imply that folks are ignoring the stabilization efffort. Previous work needs to go up, and isn't occupying current development effort. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Yocto Project 1.2 Release Status
On Wed, Apr 18, 2012 at 8:20 AM, Richard Purdie wrote: > On Wed, 2012-04-18 at 16:53 +0200, Martin Jansa wrote: >> On Wed, Apr 18, 2012 at 03:47:47PM +0100, Richard Purdie wrote: >> > I thought I'd update everyone with the current 1.2 status. >> > >> > I'm going to branch master for release at this point. We've fixed a lot >> > of issues, I'm hoping the -rc4 build will be a good one. There are signs >> > there are some more minor issues around and bugs do keep getting opened. >> > These are still being investigated so we'll continue to let that happen. >> > Once we have a QA report for -rc4, we'll be in a better position to make >> > a call on how things are looking. >> >> Does it mean that after creating branch, master will be open for >> postponed patches from ML and master-next or do you want to keep master >> as close to release branch as possible for some time (e.g. for those >> 1.2.1 fixes)? > > I have hoped people would work more on the stabilisation and testing but > I don't think I'll be able to hold off the pressure to start master > rolling again at some point relatively soon. Just because people have things to push or are pushing things which aren't bugfixes doesn't mean their time is being taken up by anything but stabilization right now. Your statement implies that everything being pushed is being currently worked on, which is incorrect. I'm sure Mentor isn't the only company with a backlog of already complete local changes to get upstream.. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] package requirements for CentOS
On Wed, Apr 11, 2012 at 8:43 AM, McClintock Matthew-B29882 wrote: > On Tue, Apr 10, 2012 at 5:13 PM, Rifenbark, Scott M > wrote: >> I have recently added the CentOS distribution to the YP QS. The list now >> includes Ubuntu, Fedora, openSUSE, and CentOS. Further down in the manual >> there are sections detailing the package requirements for Ubuntu, Fedora, >> and openSUSE. I should address CentOS. Here is the link to the sections >> currently there. Does anyone know the package requirements for CentOS? >> >> >> >> http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#packages > > We have some idea. The biggest difference looks to be chrpath is not > available on CentOS/RHEL 5.x distro's by default. I thought the same > could be said of python2.6 so I'm not sure at the moment how we handle > that. (This is for edison so it should still be applicable) We handle python 2.6 by adding the fedora EL yum repository and installing python2.6 from there (incidentally, other useful things like git are in that repo). -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problem about print in fetching
2012/4/8 caterwaul :
> I want to print out all the URI_SRC I use during the build. And I have
> tried 3 methods in 2 places as follow. But all of these can not print out
> the src path. Did I make some mistakes? Could anyone help me on this? Thank
> you.
>
> PLACE ONE in poky-edison-6.0.1/bitbake/lib/bb/fetch2/__init__.py
> class Fetch(object):
> def __init__(self, urls, d, cache = True):
> ..
> for url in urls:
> if url not in self.ud:
> print('%s' % url) # code I added
> self.ud[url] = FetchData(url, d)
> ..
>
> PLACE TWO in poky-edison-6.0.1/meta/classes/base.bbclass
> python base_do_fetch() {
>
> src_uri = (bb.data.getVar('SRC_URI', d, True) or "").split()
> if len(src_uri) == 0:
> return
> print('%s' % src_url) # code I added
> bb.note('%s' % src_url) # code I added
> }
Both of these will result in messages going to the log file for the
task, but not the console output. By default, bitbake only shows
warnings, errors, and critical messages to the console / bitbake's UI.
Use bb.warn() or bb.error() for printf-style debugging.
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Where does this object "d" come from?
2012/4/7 caterwaul : > I'm just start to investigate how bitbake works and need your help about a > question. Thank you in advance. > > The object "d" in the pasted paragraph is passed down through the following > Python scripts. But where does the object "d" come from? and where can I > find the its definition? It's a representation of the metadata. In that context, the recipe metadata. See bb.data.data_smart in the bitbake python module for the class definition. -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
