Re: [yocto] RDEPENDS in a containerized world
On Fri, Jul 26, 2019 at 10:36 AM Aaron Cohen wrote: > > I'm not sure if this is the proper venue, but I'll send it here hoping for > any insight. > > I'm developing a containerized system. Ideally the host will be somewhat > minimal, and most of the functionality of the system will run inside docker > containers. > > I have most of this working to some extent now, but am beginning to run into > an issue. > > How do I handle runtime dependencies that I "know" are provided by the host? > > For example, I have one particular application that requires gpsd at runtime. > > I know that gpsd is installed on the host, so would prefer that it not be > installed again in the docker container for this application. > > Do I have to edit the recipe for the application and remove the > RDEPENDS="gpsd" line, or is there some more clever way that I can specify > that the RDEPENDS has been fulfilled for the container that is being built? > The build-system is constructing a platform image and therefore it thinks as if it will run on bare-metal, rdeps are for ensuring that it does not have those dependencies missing. In your case the images is contained so you have to teach that to the build system. Maybe via a bbappend remove the runtime dependency and lower the QA guards to ignore it for given recipe. > Thanks, > Aaron > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] PREMIRROR
You are very welcome. Enjoy working with YP. :rjs On 7/25/19 4:48 PM, Russell Peterson wrote: > Just tried the externalsrc feature. Works perfectly. Exactly what I > was looking for. Thanks so much, Rudolf! > > --Russ > > > On Thu, Jul 25, 2019 at 4:59 PM Rudolf J Streif > mailto:rudolf.str...@ibeeto.com>> wrote: > > Inlining below. > > On 7/25/19 8:14 AM, Russell Peterson wrote: >> I think I have a somewhat better understanding of what is going on. >> >> First off, I was confused by the fact that the original error >> message I saw from do_unpack referenced the file (URL) at >> DL_DIR/git2/original_github_url. What I didn't understand at the >> time was that while that file existed,/it was actually a link/ to >> DL_DIR/git2/local_url. So, do_unpack wasn't looking at the wrong >> bare repository as I thought. It was unhappy because it didn't >> see the git commit in the local repo that it was looking for. I >> use AUTOREV for SRCREV. Apparently, even with PREMIRROR set and >> matched, bitbake will still fetch the git HEAD commit hash from >> the original URL in the recipe. The local git repo doesn't >> contain that commit. When I sync the local git repo to the >> github repo things work as expected. > Correct. If the source repo or the correct commit cannot be found > from the PREMIRROR, bitbake will use SRC_URI from the recipe. You > can block that behavior by setting BB_NO_NETWORK = "1" in which > case bitbake will not be able to connect to any remote server. > However, that does not help if your PREMIRROR is a network server. > In this case use BB_ALLOWED_HOSTS to allow access to only the > servers you want. >> >> Here is my problem. What I am ultimately trying to do here is >> have 2 git repos. 1 public, 1 private. For internal development >> we use the private git repo (a local gerrit server). Just before >> we ship we update the public github repo. The recipe always >> points to the github (public) repo so we don't need to mess with >> that before a release. This way we can do nightly builds (I'm >> just talking nightly builds done by Jenkins... not developers >> using eSDK and devtool) and test. Customers using yocto will be >> given a recipe that points to github and, importantly, those >> customers that do NOT use yocto simply fetch the project from >> github and manually build it in their own environment with their >> own tools. >> > That is a common problem. I do this all the time. To do this add > to your conf/local.conf file: > > INHERIT += "externalsrc" > EXTERNALSRC_pn-myrecipe = "/path/to/source/tree" > > Alternatively, you could use a bbappend file for you recipe in a > development layer, myrecipe.bbappend: > > inherit externalsrc > EXTERNALSRC = "/path/to/source/tree" > > Now, that is exactly what devtool does for you but you can of > course do it manually. > > :rjs > > > >> I can't be the only one doing this. Is there a best practices >> here (private vs. public repo)? >> >> --Russ >> >> >> On Wed, Jul 24, 2019 at 3:55 PM Rudolf J Streif >> mailto:rudolf.str...@ibeeto.com>> wrote: >> >> Russell, >> >> That is exactly what devtool and the externalsrc class do. >> PREMIRROR is the wrong approach for that. >> >> :rjs >> >> On 7/24/19 12:53 PM, Russell Peterson wrote: >>> Hi, Rudolf. >>> >>> I apologize for not being clear. The idea here is that my >>> recipe points to github while, for my local development >>> environment, I set a premirror to match a specific github >>> repository and translate it to a local directory. That >>> works. The fetch matches the PREMIRROR and places a copy of >>> the LOCAL git repo in my DL_DIR. The problem is, the >>> do_unpack task is looking for the git repo in the DL_DIR >>> (git2/etc...)... but it's looking for the git repo from >>> github, not my local repo that the fetch task just put in >>> DL_DIR. >>> >>> There are numerous reasons I'm doing this including the fact >>> that I cannot put a reference to my local repo in the bb >>> file since I ship that recipe to my customers and a local >>> pathname is meaningless to them. I prefer to simply modify >>> my local.conf with a PREMIRROR value that has a specific >>> regular expression that matches this particular github repo >>> (and hence does NOT effect all recipes). This is why I >>> wanted to use the PREMIRROR function. Unfortunately, it >>> does not appear to work or at least not work as I expected. >>> >>> --Russ >>> >>> >>> >>> >>> On Wed, Jul 24, 2019 at 2:57 PM Rudolf J Streif >>> mailto:rudolf.str...@ibeeto.com>> >>> wrote: >>> >>> Hi
[yocto-announce] [meta-intel] [ANNOUNCEMENT] meta-intel 11.1 layer for yocto project "warrior" 2.7.1 is now available
Hello all, We are pleased to announce the meta-intel 11.1 layer for the Yocto Project 2.7.1 "warrior" release is now available for download. Vineela Tummalapalli, Intel Corporation -- 11.1-warrior-2.7.1 Errata --- Release Name: meta-intel-11.1-warrior-2.7.1 Branch: warrior Tag: 11.1-warrior-2.7.1 Hash: f17dfeee1da8749fc4eec6892bc7578864c3664f md5: 23ff4d56f5d10c026b01b30d3a9af3da Download Locations: http://downloads.yoctoproject.org/releases/yocto/yocto-2.7.1/meta-intel-11.1-warrior-2.7.1.tar.bz2 http://mirrors.kernel.org/yocto/yocto/yocto-2.7.1/meta-intel-11.1-warrior-2.7.1.tar.bz2 -- Features/Enhancements -- lms: add recipe for lms 1921.0.0.0 metee: add new recipe for version 2.1.0 ace: add recipe for 6.5.3 version Updates/Upgrades linux-intel-rt/4.14: update to v4.14.126 linux-intel-rt/4.14: update to v4.14.115 linux-intel/4.14: update to v4.14.127 linux-intel_4.14: update to v4.14.123 linux-intel-rt/4.19: update to v4.19.37 ixgbevf: upgrade 4.5.3 -> 4.6.1 ixgbe: upgrade 5.5.5 -> 5.6.1 linux-intel/4.19: update to v4.19.55 intel-microcode: upgrade 20190514a -> 20190618 linux-intel/4.19: update to v4.19.50 intel-microcode: upgrade to 20190514a linux-intel_4.19: update to v4.19.40 -- Known Issues -- linux-yocto-rt 4.19 fails to build (Bug Id: 13442) --- Security Fixes --- For Intel processor-specific security information please visit https://software.intel.com/en-us/side-channel-security-support Method information on Intel's Security Center site: https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088=en-fr Intel Security Center: https://security-center.intel.com/default.aspx --- Fixes --- linux-intel-dev: remove branch name from SRC_URI (Bug Id: 13414) -- ___ yocto-announce mailing list yocto-announce@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto-announce
[yocto] RDEPENDS in a containerized world
I'm not sure if this is the proper venue, but I'll send it here hoping for any insight. I'm developing a containerized system. Ideally the host will be somewhat minimal, and most of the functionality of the system will run inside docker containers. I have most of this working to some extent now, but am beginning to run into an issue. How do I handle runtime dependencies that I "know" are provided by the host? For example, I have one particular application that requires gpsd at runtime. I know that gpsd is installed on the host, so would prefer that it not be installed again in the docker container for this application. Do I have to edit the recipe for the application and remove the RDEPENDS="gpsd" line, or is there some more clever way that I can specify that the RDEPENDS has been fulfilled for the container that is being built? Thanks, Aaron -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Integration of Conan Package Manager into the Yocto Project
Pulling down things from the network in do_install() is not the best option. Is reproducibility and integrity of such downloads guaranteed? What about the component licensing, where is that checked (against upstream changes)? Also, yocto's download caching and mirroring facility is side-stepped entirely. The typical 'Yocto way' would be to write a specific conan fetcher for bitbake, so that you can specify SRC_URI = "conan://..." in recipes: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2?h=master-next Generally, if someone is doing system integration with Yocto and has access to the source code, they might just write actual component recipes for building from source, as the presented workflow with building via SDK and artifactory binary uploads is awkward, and all benefits that happen when yocto is able to build directly from source code are lost. Regards, Alex On Fri, 26 Jul 2019 at 14:39, Dani Manzaneque wrote: > Hi! > > We have developed an integration with Yocto for the open-source Conan > C/C++ package manager. > This integration includes the ability to cross-build packages with a > Yocto SDK Toolchain and later deploy them in the Yocto build. > > We have created a blog post with a brief introduction to the Yocto > Project and the announcement of the integration: > https://blog.conan.io/2019/07/26/Conan-Yocto-integration.html > > And a detailed section in our documentation with the configuration for > the meta-conan layer and the Bitbake recipes for the packages: > https://docs.conan.io/en/latest/integrations/cross_platform/yocto.html > > Feedback is welcomed. Thanks a lot! > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Integration of Conan Package Manager into the Yocto Project
Hi! We have developed an integration with Yocto for the open-source Conan C/C++ package manager. This integration includes the ability to cross-build packages with a Yocto SDK Toolchain and later deploy them in the Yocto build. We have created a blog post with a brief introduction to the Yocto Project and the announcement of the integration: https://blog.conan.io/2019/07/26/Conan-Yocto-integration.html And a detailed section in our documentation with the configuration for the meta-conan layer and the Bitbake recipes for the packages: https://docs.conan.io/en/latest/integrations/cross_platform/yocto.html Feedback is welcomed. Thanks a lot! -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] how to cross-compile
Hi, I need to add some debug statements in nanddump and cross compile it for DRA71X board in yocto. Can u guide me with the steps, please? Regards, Harish. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Shared area conflict
Hello, When I try to bitbake core-image-minimal it is giving up with the following error: ERROR: mesa-gl-2_18.1.9-r0 do_packagedata: The recipe mesa-gl is trying to install files into a shared area when those files already exist. Those files and their manifest location are: /home/me/Yocto/BeagleBoneBlack/tmp/pkgdata/beaglebone/runtime/libgbm (matched in manifest-beaglebone-libgbm.packagedata) /home/me/Yocto/BeagleBoneBlack/tmp/pkgdata/beaglebone/runtime/libgbm-dev (matched in manifest-beaglebone-libgbm.packagedata) Please verify which recipe should provide the above files. I’ve tried one of the suggestions that it gives in the rather verbose message that follows and nuked the “tmp” directory and rebuilt but with no further success. My local.conf contains: PREFERRED_PROVIDER_libgbm = “libgbm” PREFERRED_PROVIDER_libgbm-dev = "libgbm-dev” How do I get it to stop complaining? -Andy.-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
