[yocto] CONF_VERSION and LCONF_VERSION details
Could someone explain how these work and what the permissible values are? The documentation is sadly lacking in details beyond that they are incremented when a file changes incompatibly. Specifically, what counts as "incompatible"? The contents of the file (i.e. the templates have been updated so the generated file in build/conf needs to be replaced), or the format of the files? Also, is TEMPLATECONF considered at all? In my case, we have our own templates and thus set TEMPLATECONF before sourcing oe-init-build-env. But running bitbake seems to compare the LCONF_VERSION from build/conf (for example) against the template in poky/meta-poky/conf rather than the ones in our layer. Is this because we still have DISTRO set to "poky" or will it always do that? I had updated our templates, bumped the version numbers, and then ran oe-init-build-env (actually our own wrapper) in the expectation that it would updated the files under build/conf from the updated templates. Instead it did nothing, and I got errors when I ran bitbake and it found the values differed, Is it that the values must always match those in meta-poky, even if you have your own distro (i.e. DISTRO set to something else)? Should TEMPLATECONF be set in our custom local.conf.sample? Thanks Keith Derrick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Alternative to _git.bb convention for unstable versions?
Thanks Martin. I was trying to avoid everyone in my org having to add anything manually to their local.conf (we will be using the _git version) – and dealing with the “help me” emails whenever they forgot. I was thinking that you would want one or the other, but I suppose if there’s a way to screw up, users will find it ☹ Eventually, we’ll switch our build to a custom DISTRO and the problem will go away. Just wish there was somewhere else the PREFERRED_VERSION statements could go. From: Martin Jansa Date: Friday, September 13, 2019 at 8:35 AM To: "Keith Derrick/LGEUS Advanced Platform(keith.derr...@lge.com)" Cc: "yocto@yoctoproject.org" Subject: Re: [yocto] Alternative to _git.bb convention for unstable versions? You can easily add .inc file which will set all the PREFERRED_VERSIONs for all components you need and then the users will just add an "require" of this .inc files to their local.conf. "somepackage-unstable.bb<http://somepackage-unstable.bb>" or "somepackage-devel.bb<http://somepackage-devel.bb>" this will make it 2 different components - not 2 different versions of the same component - which makes this much more complicated, you'll need PREFERRED_PROVIDERs for every dependency and in the end you will need to make sure that whole build is using the same set of providers, because if A depends on somepackage-unstable B depends on A and somepackage-devel then building B will fail in prepare-recipe-sysrooot, because A will pull somepackage-unstable which will probably conflict with somepackage-devel by providing the same files (in just different version). You can see how openssl10 and openssl "worked" if you build didn't use the same one for all the recipes. Cheers, On Fri, Sep 13, 2019 at 5:27 PM keith.derrick mailto:keith.derr...@lge.com>> wrote: I am currently creating a new layer (which will eventually be made generally available). I need to provide both a versioned recipe, and an "unstable" one. Currently I have somepackage_1.0.bb<http://somepackage_1.0.bb> and somepackage_git.bb<http://somepackage_git.bb> which are working fine. However, using the "_git" approach (with DEFAULT_PREFERENCE = "-1") requires the use of PREFERRED_VERSION in either local.conf or a distro.conf. I've tried putting it in the image files, and that doesn't work. If you are not creating your own DISTRO, and instead just adding the layer to a straight poky/meta build, you seem to be pretty much stuck with adding 3 PREFERRED_VERSION statements (target, -native, and nativesdk- variants) to local.conf. I'd rather not require that of users of the layer. I'm considering instead using either "somepackage-unstable.bb<http://somepackage-unstable.bb>" or "somepackage-devel.bb<http://somepackage-devel.bb>" instead of "sompackage_git.bb<http://sompackage_git.bb>". This allows a simple selection of either RDEPENDS = "somepackage" or RDEPENDS = "somepackage-devel" to add the desired one to an image. However, neither "-devel" or "-unstable" have the right feel for the suffix. If, for example, you are picking up an older commit (between versions say) it might well be completely stable. Does the community have a naming convention for this type of recipe? Failing that, is there somewhere else in the met-data the PREFERRED_VERSION statement can go other than a configuration file? Thanks Keith Derrick -- ___ yocto mailing list yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Alternative to _git.bb convention for unstable versions?
I am currently creating a new layer (which will eventually be made generally available). I need to provide both a versioned recipe, and an "unstable" one. Currently I have somepackage_1.0.bb and somepackage_git.bb which are working fine. However, using the "_git" approach (with DEFAULT_PREFERENCE = "-1") requires the use of PREFERRED_VERSION in either local.conf or a distro.conf. I've tried putting it in the image files, and that doesn't work. If you are not creating your own DISTRO, and instead just adding the layer to a straight poky/meta build, you seem to be pretty much stuck with adding 3 PREFERRED_VERSION statements (target, -native, and nativesdk- variants) to local.conf. I'd rather not require that of users of the layer. I'm considering instead using either "somepackage-unstable.bb" or "somepackage-devel.bb" instead of "sompackage_git.bb". This allows a simple selection of either RDEPENDS = "somepackage" or RDEPENDS = "somepackage-devel" to add the desired one to an image. However, neither "-devel" or "-unstable" have the right feel for the suffix. If, for example, you are picking up an older commit (between versions say) it might well be completely stable. Does the community have a naming convention for this type of recipe? Failing that, is there somewhere else in the met-data the PREFERRED_VERSION statement can go other than a configuration file? Thanks Keith Derrick -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dealing with line endings
Thanks Martin, that fixed it nicely. From: Martin Jansa Sent: Tuesday, June 25, 2019 12:30 AM To: Keith Derrick/LGEUS Advanced Platform(keith.derr...@lge.com) Cc: yocto@yoctoproject.org Subject: Re: [yocto] Dealing with line endings Hi Keith, you can use dos2unix.bbclass: http://git.openembedded.org/openembedded-core/tree/meta/classes/dos2unix.bbclass to convert them before do_patch. Cheers, On Tue, Jun 25, 2019 at 4:57 AM keith.derrick mailto:keith.derr...@lge.com>> wrote: I am using an upstream repo with a mix of line endings. In my recipe, I'm applying a patch with normalized line endings, as our meta layer repo has a .gitattributes with "text=auto" set. The patch is failing due to "different line endings". Can the git fetcher be configured to normalize line endings on unpack? I tried setting core.autocrlf in my global .gitconfig, but the fetcher/unpacker seems to ignore it. Thanks Keith -- ___ yocto mailing list yocto@yoctoproject.org<mailto:yocto@yoctoproject.org> https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Dealing with line endings
I am using an upstream repo with a mix of line endings. In my recipe, I'm applying a patch with normalized line endings, as our meta layer repo has a .gitattributes with "text=auto" set. The patch is failing due to "different line endings". Can the git fetcher be configured to normalize line endings on unpack? I tried setting core.autocrlf in my global .gitconfig, but the fetcher/unpacker seems to ignore it. Thanks Keith -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
