Re: [yocto] Changing IMAGE_NAME [yocto krogoth]
On Wed, Apr 10, 2019 at 2:49 AM Mauro Ziliani wrote:
> Hi all.
>
> I need to change the default IMAGE_NAME of my image recipe.
>
> I make my image recipe as mysystem-image_1.0.bb and I'd like to produce
> and image (tar) with the name
>
> mysystem-image-1.0-.tar
>
>
Isn’t time stamp part of the standard image you get out of build ?
>
> So I setup
>
> IMAGE_NAME := "{IMAGE_BASENAME}-${PV}-${DATETIME}"
>
>
> I made some compilation of mysystem with the default IMAGE_NAME.
>
> Than I update the value of IMAGE_NAME.
>
>
> Now when I rebuild the image bitbke tell me
>
> ERROR: When reparsing mysystem-image_1.0.do_roots, the basehash value
> change from to
>
> If i restore the IMAGE_NAME to the default value this message disappear
>
>
> How can I change the IMAGE_NAME as I need and avoi this message?
>
>
> Best regards,
>
> MZ
>
>
> --
> ___
> 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] Stripping debug symbols
Build should strip it automatically what does your build recipe look like
On Thu, Apr 11, 2019 at 1:37 AM Mauro Ziliani wrote:
> Hi all.
>
> I worked on my project woth Krogoth, gcc 5.3.0, on imx6dlsabresd board.
>
> My application is build with cmake 3.4.3, shipped with BSP.
>
>
> I'd like to strip debug symbols from the final binary, but if I prepend
> the strip parameter in CMAKE_{C,CXX}_FLAGS_RELEASE in my CMakeLists.txt,
> bitbake give me errors.
>
>
> What is the right path to follow to strip final binary?
>
> With debug info the binary is 109MB, without 5MB
>
>
> Best regards,
>
> Mauro
>
> --
> ___
> 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] [meta-yocto-bsp][PATCH v2] beaglebone-yocto: Update u-boot config to match u-boot 19.04
[YOCTO #13145]
This was announced at 2019.01:
https://www.mail-archive.com/u-boot@lists.denx.de/msg305424.html
Basically, am335x_boneblack is just a special subset of am335x_evm config,
created and owned by BeagleBoard.org community. Since it was not migrated to
use CONFIG_BLK in time for 2019.04 release.
Signed-off-by: Alistair Francis
Acked-by: Denys Dmytriyenko
---
meta-yocto-bsp/conf/machine/beaglebone-yocto.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
index 70d3cfe..bc18ee8 100644
--- a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
+++ b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
@@ -32,7 +32,7 @@ KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
SPL_BINARY = "MLO"
UBOOT_SUFFIX = "img"
-UBOOT_MACHINE = "am335x_boneblack_config"
+UBOOT_MACHINE = "am335x_evm_defconfig"
UBOOT_ENTRYPOINT = "0x80008000"
UBOOT_LOADADDRESS = "0x80008000"
--
2.21.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-yocto-bsp][PATCH] beaglebone-yocto: Update u-boot config to match u-boot 19.04
Signed-off-by: Alistair Francis
---
meta-yocto-bsp/conf/machine/beaglebone-yocto.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
index 70d3cfe..bc18ee8 100644
--- a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
+++ b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
@@ -32,7 +32,7 @@ KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
SPL_BINARY = "MLO"
UBOOT_SUFFIX = "img"
-UBOOT_MACHINE = "am335x_boneblack_config"
+UBOOT_MACHINE = "am335x_evm_defconfig"
UBOOT_ENTRYPOINT = "0x80008000"
UBOOT_LOADADDRESS = "0x80008000"
--
2.21.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] problem with ruby
I've try that and doesn't change anything... I think the problem is from the gem zlib who is not build / take by Yocto so it can't be use. When i try to use it with a simple ruby program i can't find zlib in the environment of the devshell. De : Khem Raj Envoyé : mardi 9 avril 2019 20:22:47 À : Clement CHERBEIX Cc : Yocto Project Objet : Re: [yocto] problem with ruby probably it has to be added to linker flags explicitly. On Tue, Apr 9, 2019 at 12:00 AM Clement CHERBEIX wrote: > > It's done but I keep the same problem, I've add zlib in the PACKAGECONFIG too > without any result... > > > > > De : Khem Raj > Envoyé : lundi 8 avril 2019 20:04 > À : Clement CHERBEIX > Cc : Yocto Project > Objet : Re: [yocto] problem with ruby > > On Mon, Apr 8, 2019 at 9:44 AM Clément Cherbeix > wrote: > > > > Hello all, > > > > I’m trying to add the MIB mechanics in my yocto project, for that I use > > dadi (ruby depenedent) but I get an error when bitbake try to compile : > > > > DEBUG: Executing shell function do_compile > > > > ERROR: Loading command: build (LoadError) > > > > cannot load such file -- zlib > > > > ERROR: While executing gem ... (NoMethodError) > > > > undefined method `invoke_with_build_args' for nil:NilClass > > > > WARNING: > > /home/modem/tkh/build/tmp/work/x86_64-linux/libxml-ruby-native/2.8.0-r0/temp/run.do_compile.567:1 > > exit 1 from 'LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" gem build $gem' > > > > > > > > I have tried to build the gem in an environment outside of Yocto and it was > > correct but when I try to do it in Yocto, I get my error. > > Did someone have an idea on what to do ? > > what is the recommended way of building ruby via gem in yocto ? > > > > > > It seems that it is using ruby-native but does not have zlib-native > and it cant find this library. Can you add zlib to DEPENDS in ruby > recipe and see if that helps. > > > > > Here is my build environment : > > > > BB_VERSION = "1.40.0" > > > > BUILD_SYS= "x86_64-linux" > > > > NATIVELSBSTRING = "universal" > > > > TARGET_SYS = "x86_64-poky-linux" > > > > DISTRO = "poky" > > > > DISTRO_VERSION = "2.6.1" > > > > TUNE_FEATURES= "m64 corei7" > > > > > > > > Thanks in advance ! > > > > > > > > Clément C. > > > > -- > > ___ > > 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] problem with ruby
It's done but I keep the same problem, I've add zlib in the PACKAGECONFIG too without any result... De : Khem Raj Envoyé : lundi 8 avril 2019 20:04 À : Clement CHERBEIX Cc : Yocto Project Objet : Re: [yocto] problem with ruby On Mon, Apr 8, 2019 at 9:44 AM Clément Cherbeix wrote: > > Hello all, > > I’m trying to add the MIB mechanics in my yocto project, for that I use dadi > (ruby depenedent) but I get an error when bitbake try to compile : > > DEBUG: Executing shell function do_compile > > ERROR: Loading command: build (LoadError) > > cannot load such file -- zlib > > ERROR: While executing gem ... (NoMethodError) > > undefined method `invoke_with_build_args' for nil:NilClass > > WARNING: > /home/modem/tkh/build/tmp/work/x86_64-linux/libxml-ruby-native/2.8.0-r0/temp/run.do_compile.567:1 > exit 1 from 'LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" gem build $gem' > > > > I have tried to build the gem in an environment outside of Yocto and it was > correct but when I try to do it in Yocto, I get my error. > Did someone have an idea on what to do ? > what is the recommended way of building ruby via gem in yocto ? > > It seems that it is using ruby-native but does not have zlib-native and it cant find this library. Can you add zlib to DEPENDS in ruby recipe and see if that helps. > > Here is my build environment : > > BB_VERSION = "1.40.0" > > BUILD_SYS= "x86_64-linux" > > NATIVELSBSTRING = "universal" > > TARGET_SYS = "x86_64-poky-linux" > > DISTRO = "poky" > > DISTRO_VERSION = "2.6.1" > > TUNE_FEATURES= "m64 corei7" > > > > Thanks in advance ! > > > > Clément C. > > -- > ___ > 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] Installation help
There is nothing wrong with my network network! For now the issue is resolved. Thanks any way. On 2019-04-08 1:10 p.m., Burton, Ross wrote: The better fix is to fix your network. If you need a proxy, set it in local.conf. Ross On Mon, 8 Apr 2019 at 18:09, Nataliya Korovkina wrote: Hello Karshi, I had the same message. I added: CONNECTIVITY_CHECK_URIS="" in conf/local.conf as a QUICK FIX. I hope someone has better solution, please? Thanks, Nataliya On Mon, Apr 8, 2019 at 12:43 PM Karshi Hasanov wrote: Hi all, I have followed the https://www.yoctoproject.org/docs/2.6.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html when issue the "bitbake core-image-minimal" I am keep getting this error: ERROR: OE-core's config sanity checker detected a potential misconfiguration. Either fix the cause of this error or at your own risk disable the checker (see sanity.conf). Following is the list of potential problems / advisories: Fetcher failure for URL: 'https://www.example.com/'. URL https://www.example.com/ doesn't work. Please ensure your host's network is configured correctly, or set BB_NO_NETWORK = "1" to disable network access if all required sources are on local disk. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- Nataliya Korovkina -- ___ 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] Read-only filesystems: Move directory to RW directory and symlink back
On Tuesday, March 26, 2019 9:54 PM, Timothy Froehlich wrote:
> Is there a recommended way of doing this? Right now I have a
> ROOTFS_POSTPROCESS_CMD
> that moves the directories and symlinks them back, but I'm not sure if I'm
> doing it exactly right or if there's something built-in.
> The function just does a bunch of this:
> install -d ${D}/${persist_dir}
> mv ${D}/${ORIG} ${D}/${persist_dir}/${LINKNAME}
> ln -sr ${D}/${persist_dir}/${LINKNAME} ${D}/${ORIG}
I am also working on read-only rootfs now. Unfortunately it looks like that
Yocto does not provide ready solution for symlinking. I use similar approach to
yours.
If you accept bind mounts or overlayfs, you may have a look at
meta/recipes-core/volatile-binds/volatile-binds.bb
Best regards,
Lukasz Zemla
***
The information in this email is confidential and intended solely for the
individual or entity to whom it is addressed. If you have received this email
in error please notify the sender by return e-mail, delete this email, and
refrain from any disclosure or action based on the information.
***
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Openembedded-architecture] [OE-core] Eclipse support dropped with immediate effect
On Thu, Apr 11, 2019 at 9:29 AM Scott Rifenbark wrote: > Richard and Armin, > > I am going to start pulling Eclipse from the docs today. The changes > won't make the frozen rc build but the website docs will reflect reality. > Thank you, Scott. > > Scott > > On Thu, Apr 11, 2019 at 12:20 AM > wrote: > >> On Thu, 2019-04-11 at 08:42 +0530, akuster808 wrote: >> > >> > On 4/10/19 3:11 PM, richard.pur...@linuxfoundation.org wrote: >> > > On Wed, 2019-04-10 at 05:56 +0530, akuster808 wrote: >> > > > On 4/9/19 8:52 PM, Richard Purdie wrote: >> > > > > I'm sorry to have to say this but the project is terminating >> > > > > its >> > > > > official eclipse plugin support with immediate effect. >> > > > Does this affect the stable branches as well? >> > > Yes, I think we'll just be removing the target from the autobuilder >> > > entirely. >> > >> > Have we every removed a feature from a release? Do we need to doc >> > this ? >> >> Its not so much remove as not release. No, we haven't and yes, we do >> need to document it in the release notes. >> >> Cheers, >> >> Richard >> >> ___ >> Openembedded-architecture mailing list >> openembedded-architect...@lists.openembedded.org >> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture >> > ___ > Openembedded-architecture mailing list > openembedded-architect...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-yocto-bsp][PATCH] beaglebone-yocto: Update u-boot config to match u-boot 19.04
On Thu, Apr 11, 2019 at 05:27:25PM +, Alistair Francis wrote:
> Signed-off-by: Alistair Francis
Acked-by: Denys Dmytriyenko
[YOCTO #13145]
This was announced at 2019.01:
https://www.mail-archive.com/u-boot@lists.denx.de/msg305424.html
Basically, am335x_boneblack is just a special subset of am335x_evm config,
created and owned by BeagleBoard.org community. Since it was not migrated to
use CONFIG_BLK in time for 2019.04 release, I was going to do the same - just
switch it over to am335x_evm config, which supports all BeagleBone variants
just fine.
> ---
> meta-yocto-bsp/conf/machine/beaglebone-yocto.conf | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> index 70d3cfe..bc18ee8 100644
> --- a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> +++ b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> @@ -32,7 +32,7 @@ KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
>
> SPL_BINARY = "MLO"
> UBOOT_SUFFIX = "img"
> -UBOOT_MACHINE = "am335x_boneblack_config"
> +UBOOT_MACHINE = "am335x_evm_defconfig"
> UBOOT_ENTRYPOINT = "0x80008000"
> UBOOT_LOADADDRESS = "0x80008000"
>
> --
> 2.21.0
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Openembedded-architecture] [OE-core] Eclipse support dropped with immediate effect
Richard and Armin, I am going to start pulling Eclipse from the docs today. The changes won't make the frozen rc build but the website docs will reflect reality. Scott On Thu, Apr 11, 2019 at 12:20 AM wrote: > On Thu, 2019-04-11 at 08:42 +0530, akuster808 wrote: > > > > On 4/10/19 3:11 PM, richard.pur...@linuxfoundation.org wrote: > > > On Wed, 2019-04-10 at 05:56 +0530, akuster808 wrote: > > > > On 4/9/19 8:52 PM, Richard Purdie wrote: > > > > > I'm sorry to have to say this but the project is terminating > > > > > its > > > > > official eclipse plugin support with immediate effect. > > > > Does this affect the stable branches as well? > > > Yes, I think we'll just be removing the target from the autobuilder > > > entirely. > > > > Have we every removed a feature from a release? Do we need to doc > > this ? > > Its not so much remove as not release. No, we haven't and yes, we do > need to document it in the release notes. > > Cheers, > > Richard > > ___ > Openembedded-architecture mailing list > openembedded-architect...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [EXTERNAL] Re: Yocto Project support for Numeric/Scientific Python
Mike Looijmans Wrote: > Just attempting to revive this dead horse again... > > Anyone made any proress here? > > Since cross-compiling turned out to be really really painful, I tried if > compiling on the board would be an option. No such luck, apparently > the Fortran compiler isn't being crosscompiled either. I had to do the following in my last attempt (working with the Sumo release branch). Add the following to IMAGE_INSTALL: gfortran gfortran-symlinks libgfortran-dev AND add the following to local.conf FORTRAN_forcevariable = ",fortran" The latter is to adjust the build of gcc to include Fortran support. In prior Yocto releases I did not have to use the _forcevariable construct, but I don't recall why I used that form for Sumo. Notice to recipient: This email is meant for only the intended recipient of the transmission, and may be a communication privileged by law, subject to export control restrictions or that otherwise contains proprietary information. If you receive this email by mistake, please notify us immediately by replying to this message and then destroy it and do not review, disclose, copy or distribute it. Thank you in advance for your cooperation. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Listing files/packages a packagegroup creates
(ctrl+enter, sorry :/) Anyways, the same (oe-pkgdata-util) approach doesn't work for identifying what files a packagegroup installs. ``` oe-pkgdata-util list-pkg-files packagegroup-core-ssh-openssh packagegroup-core-ssh-openssh: ``` A workaround seems to be finding the packagegroup source and identifying all the packages in there and looking for each separately. Looking if someone has a cleaner way. Be Well, Alan On Thu, Apr 11, 2019 at 3:59 PM Alan Martinovic wrote: > > Hi, > when searching for the files a package creates I find it very > practical to use `oe-pkgdata-util`. i.e. > > oe-pkgdata-util list-pkg-files busybox > > However the same method doesn't work when applied to > packagegroups. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Listing files/packages a packagegroup creates
Hi, when searching for the files a package creates I find it very practical to use `oe-pkgdata-util`. i.e. oe-pkgdata-util list-pkg-files busybox However the same method doesn't work when applied to packagegroups. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Project support for Numeric/Scientific Python
Just attempting to revive this dead horse again... Anyone made any proress here? Since cross-compiling turned out to be really really painful, I tried if compiling on the board would be an option. No such luck, apparently the Fortran compiler isn't being crosscompiled either. On 26-01-19 20:01, Philip Balister wrote: > Sounds like we need a layer for packages that needs fortran enabled and > collect out work there. > > Philip > > On 01/24/2019 05:31 AM, Mike Looijmans wrote: >> +1 >> >> Got lapack to compile, but no such luck with any "blas" package (like >> openblas). And that's a requirement for octave, which was what I was aiming >> at. >> >> I'll share some recipes, tomorrow or so (today is stuffed with other work). >> >> >> On 23-01-19 22:39, Philip Balister wrote: >>> I care :) >>> >>> On 01/23/2019 04:28 PM, Randy MacLeod wrote: On 1/23/19 2:54 PM, Smith, Virgil (US) wrote: > Is there a current or relatively recent recipe for SciPy and related > libraries? People have worked on it at least once before but found some problems with blas and atlas: https://lists.yoctoproject.org/pipermail/yocto/2018-March/thread.html#40348 I'd say that there is interest. I CCed Peter who started one of the threads and BCCed 5 other people who seemed to be interested since I didn't want to drag them all into the thread. > > Further and more importantly, is having a maintainer for (recipes for) > those libraries a priority for the active members of the Project? > (i.e. does interest rise above the general welcoming of participants > to periodically asking “Hey has anyone put out a call to fill this > slot?” if/when the slot is vacant). It's always nice to have a maintainer but community members sometimes keep recipes up to date even if they aren't direct users. > > BTW: If this is the wrong list for this query, please let me know. It a reasonable list for general discussion. If you get to a point where patches are being submitted, it should probably go to another list such as: > > Why? We are trying to gauge community interest before making long > term plans. > > We would like to know if this horse is at all likely to have > healthcare before betting on it (without sacrificing other patients to > obtain the proper veterinary degree and keep up practice to treat it > ourselves). heh. Thanks! ../Randy > > NOTE: I see from the RRS emails that Derek Straka is currently > maintaining the python-numpy recipe. THANK YOU! > > > > > Notice to recipient: This email is meant for only the intended > recipient of the transmission, and may be a communication privileged > by law, subject to export control restrictions or that otherwise > contains proprietary information. If you receive this email by > mistake, please notify us immediately by replying to this message and > then destroy it and do not review, disclose, copy or distribute it. > Thank you in advance for your cooperation. > >> -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Changing IMAGE_NAME [yocto krogoth]
Thanks
I'll try your suggestion
Il 11/04/19 13:12, Alexander Kanavin ha scritto:
> You need to use vardepsexclude (read in the bitbake manual how to).
>
> Generally I am not a fan of putting timestamps into anything
> yocto-built, it's prone to issues like this, breaks reproducibility,
> and also subverts sstate if not managed carefully. I'd almost suggest
> you build the image with a default name, and then rename it after the
> fact when deploying to some artefact storage.
>
> Alex
>
> On Thu, 11 Apr 2019 at 11:30, Mauro Ziliani wrote:
>> Thanks
>>
>> It was a typing error.
>>
>> In my recipe I set the value as you told me.
>>
>> But the ERROR keep on show
>>
>>
>> Il 10/04/19 11:59, mikko.rap...@bmw.de ha scritto:
>>> On Wed, Apr 10, 2019 at 11:47:42AM +0200, Mauro Ziliani wrote:
Hi all.
I need to change the default IMAGE_NAME of my image recipe.
I make my image recipe as mysystem-image_1.0.bb and I'd like to produce
and image (tar) with the name
mysystem-image-1.0-.tar
So I setup
IMAGE_NAME := "{IMAGE_BASENAME}-${PV}-${DATETIME}"
>>> Should be:
>>>
>>> IMAGE_NAME := "${IMAGE_BASENAME}-${PV}-${DATETIME}"
>>>
>>> note the added $. I guess that's the bit which confuses bitbake. Been
>>> there, done that
>>> too :)
>>>
>>> Hope this helps,
>>>
>>> -Mikko
>> --
>> ___
>> 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] Changing IMAGE_NAME [yocto krogoth]
You need to use vardepsexclude (read in the bitbake manual how to).
Generally I am not a fan of putting timestamps into anything
yocto-built, it's prone to issues like this, breaks reproducibility,
and also subverts sstate if not managed carefully. I'd almost suggest
you build the image with a default name, and then rename it after the
fact when deploying to some artefact storage.
Alex
On Thu, 11 Apr 2019 at 11:30, Mauro Ziliani wrote:
>
> Thanks
>
> It was a typing error.
>
> In my recipe I set the value as you told me.
>
> But the ERROR keep on show
>
>
> Il 10/04/19 11:59, mikko.rap...@bmw.de ha scritto:
> > On Wed, Apr 10, 2019 at 11:47:42AM +0200, Mauro Ziliani wrote:
> >> Hi all.
> >>
> >> I need to change the default IMAGE_NAME of my image recipe.
> >>
> >> I make my image recipe as mysystem-image_1.0.bb and I'd like to produce
> >> and image (tar) with the name
> >>
> >> mysystem-image-1.0-.tar
> >>
> >>
> >> So I setup
> >>
> >> IMAGE_NAME := "{IMAGE_BASENAME}-${PV}-${DATETIME}"
> > Should be:
> >
> > IMAGE_NAME := "${IMAGE_BASENAME}-${PV}-${DATETIME}"
> >
> > note the added $. I guess that's the bit which confuses bitbake. Been
> > there, done that
> > too :)
> >
> > Hope this helps,
> >
> > -Mikko
> --
> ___
> 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] Changing IMAGE_NAME [yocto krogoth]
Thanks
It was a typing error.
In my recipe I set the value as you told me.
But the ERROR keep on show
Il 10/04/19 11:59, mikko.rap...@bmw.de ha scritto:
> On Wed, Apr 10, 2019 at 11:47:42AM +0200, Mauro Ziliani wrote:
>> Hi all.
>>
>> I need to change the default IMAGE_NAME of my image recipe.
>>
>> I make my image recipe as mysystem-image_1.0.bb and I'd like to produce
>> and image (tar) with the name
>>
>> mysystem-image-1.0-.tar
>>
>>
>> So I setup
>>
>> IMAGE_NAME := "{IMAGE_BASENAME}-${PV}-${DATETIME}"
> Should be:
>
> IMAGE_NAME := "${IMAGE_BASENAME}-${PV}-${DATETIME}"
>
> note the added $. I guess that's the bit which confuses bitbake. Been there,
> done that
> too :)
>
> Hope this helps,
>
> -Mikko
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Stripping debug symbols
Hi all.
I worked on my project woth Krogoth, gcc 5.3.0, on imx6dlsabresd board.
My application is build with cmake 3.4.3, shipped with BSP.
I'd like to strip debug symbols from the final binary, but if I prepend
the strip parameter in CMAKE_{C,CXX}_FLAGS_RELEASE in my CMakeLists.txt,
bitbake give me errors.
What is the right path to follow to strip final binary?
With debug info the binary is 109MB, without 5MB
Best regards,
Mauro
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-selinux][PULL] refpolicy: update to 2.20190201 and git HEAD policies (2019-04-10 10:57:14 -0400)
Hi Joe,
Thank you for working on the refpolicy upgrade.
I have a quick test with your patch. Here are the results:
Machine: qemux86-64
Image: core-image-selinux
Init manager: systemd
Boot command: runqemu qemux86-64 kvm nographic bootparams="selinux=1
enforcing=X" qemuparams="-m 1024"
1. All refpolicy type of git version can be built without problems.
2. With parameter selinux=1 & enforcing=0
The qemu can boot up and login for all refpolicy types.
3. With parameter selinux=1 & enforcing=1
Some of services failed to startup when booting. But this issue also
exist on old refpolicy version (2.20170204)
4. refpolicy stable version (2.20190201)
I got an do_fetch error with refpolicy stable version.
Seems the SRC_URI is not correct. It should be
"https://github.com/SELinuxProject/refpolicy/releases/download/RELEASE_2_20190201/refpolicy-${PV}.tar.bz2;
Regards,
Yi
在 2019/4/10 下午11:53, Joe MacDonald 写道:
This is a huge, long-overdue update the refpolicy. I apologise for it
blocking the other outstanding meta-selinux patches, but I've been
trying to limit the scope of changes while this happens. Now that this
is cleared off the slate, I'll be gathering up the other meta-selinux
patches from the list. I'll send out a follow-up on those as they're
merged and another when I think I'm done, so if I've missed your patch,
that'll be the time to ping me about it.
As for this, here's what I've done.
- manually reviewed all patches that had been present in
repolicy-* for both the old stable (2.20170204) and git
versions
- forked the SELinuxPolicy/refpolicy repo and applied all
still-relevant patches to the RELEASE_2.20190201 branch
- restructured the patches so that all patches that should
reasonably apply to all variants (mcs, mls, minimum, standard
and targeted) were in a common branch and only the ones that
are specific to each variant would be in their own recipe
- restructure the patches so that systemd and sysvinit patches
were not applied to the same tree
- created a parallel set of branches for each of these against
current git HEAD
The results of this can be examined here:
https://github.com/joeythesaint/refpolicy
Then each of these were exported and put in the appropriate SRC_URIs so
the branch structure is more-or-less preserved.
My goals with this approach were the following:
- make it easier to keep refpolicy up to date, particularly for
anyone wanting to use the git variants
- make it easier to determine how your preferred version of
refpolicy on Yocto differs from upstream refpolicy
- limit the above differences to the minimum to achieve the goal
of a functional Yocto system
- eventually move us away from release tarballs entirely
That last point is why I'm preserving the refpolicy fork above. I'd
like to keep going with this and so future refpolicy patches will first
be put in that repo then exported and applied to the SRC_URIs. If you
have such a patch and want to send me a PR against the branch you think
it belongs on from github directly, that'd be awesome, but the old
method of patches to the mailing list will work fine too, just know that
this is the way I'm going to try to manage this for the foreseeable
future. Ultimately, if this proves to work well, I would like to move
the refpolicy fork off github and house it on git.yoctoproject.org
beside meta-selinux, but the workflow needs to be properly validated
first.
One additional point, I intend to take another pass at revising this
stuff, ideally moving the huge number of common patches out as well.
There's still some that aren't necessary for base yocto but are for
additional layers. That's fine for us to have, but I'd like to get
those moved to optional layer directories so we're making the best use
of that functionality we can. If you have suggestions on which pieces
already present are good candidates, let me know. Similarly, if you've
got additional policy patches you want to see included, feel free to
send them along, we can easily move them to optional locations inside
meta-selinux.
Finally, please everyone test this and provide feedback on anything that
doesn't work or looks strange. This is easily the biggest change we've
had in meta-selinux in years and I expect there's still some wrinkles to
be ironed out. And I really appreciate everyone's patience while we got
to this point and hope it's not too much more pain before we put a
ribbon on this and call it done.
I'll give this until at least the weekend before merging it to master,
pending comments or an overwhelming "please just do it" from the
community.
Thanks.
---
The following changes since commit a6a3cadb1ef3203a123d8f5f9df27832f55b2ce3:
Backport patches from upstream to fix build with musl (2019-03-25 09:43:53
+0100)
are available in the Git
Re: [yocto] [OE-core] Eclipse support dropped with immediate effect
On Thu, 2019-04-11 at 08:42 +0530, akuster808 wrote: > > On 4/10/19 3:11 PM, richard.pur...@linuxfoundation.org wrote: > > On Wed, 2019-04-10 at 05:56 +0530, akuster808 wrote: > > > On 4/9/19 8:52 PM, Richard Purdie wrote: > > > > I'm sorry to have to say this but the project is terminating > > > > its > > > > official eclipse plugin support with immediate effect. > > > Does this affect the stable branches as well? > > Yes, I think we'll just be removing the target from the autobuilder > > entirely. > > Have we every removed a feature from a release? Do we need to doc > this ? Its not so much remove as not release. No, we haven't and yes, we do need to document it in the release notes. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
