Re: [yocto] Installation help
Den 2019-04-08 kl. 20:58, skrev Nataliya Korovkina: "example.com <http://example.com>" is not working. If someone needs to check their connection this way, please use CONNECTIVITY_CHECK_URIS="https://www.yoctoproject.org; I am pretty sure that my Linksys router defines example.com in its hosts files :-( BR Ulf N On Mon, Apr 8, 2019 at 2:50 PM Burton, Ross <mailto:ross.bur...@intel.com>> wrote: There must be if example.com <http://example.com> can't be downloaded from... On Mon, 8 Apr 2019 at 19:49, Karshi Hasanov mailto:karshi.hasa...@gmail.com>> wrote: > > 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 > > mailto:malus.brandyw...@gmail.com>> 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 mailto:karshi.hasa...@gmail.com>> 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 <mailto:yocto@yoctoproject.org> > >>> https://lists.yoctoproject.org/listinfo/yocto > >> > >> > >> -- > >> > >> > >> Nataliya Korovkina > >> > >> -- > >> ___ > >> yocto mailing list > >> yocto@yoctoproject.org <mailto:yocto@yoctoproject.org> > >> https://lists.yoctoproject.org/listinfo/yocto -- Nataliya Korovkina -- Best Regards Ulf Samuelsson -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Multiple MACHINEs and DISTROs: When to use own build dir, SSTATE_DIR, DL_DIR ?
Den 2019-05-09 kl. 11:56, skrev Burton, Ross: On Thu, 9 May 2019 at 10:47, Fabian Knapp <mailto:kn...@ambibox.de>> wrote: we have multiple MACHINEs and DISTROs and Im wondering for which combinations I have to setup a dedicated build dir, SSTATE_DIR and DL_DIR. Information in the form of: Each (change of) MACHINE needs its dedicated SSTATE_DIR and build dir but can share DL_DIR. You can always share DL_DIR and SSTATE_DIR. Ross When you have the same machine, and the recipes have variants which are DISTRO dependent the SSTATE_DIR can be messed up We never digged deep enough to find the cause, but when we separated the SSTATE to only have one DISTRO in the same SSTATE, the problem disappeared. -- Best Regards Ulf Samuelsson -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] kernel module override
> 17 feb. 2019 kl. 14:57 skrev Russell Peterson : > > Hello, > > I have what I would think is an unusual requirement regarding a kernel module > and could use some advice. > > I have a kernel module that has been heavily modified... to the point where > we have a separate recipe for it and treat it as an out-of-tree module. This > works by not setting the kernel config file to build that module and our meta > layer builds and installs the module. No problem... works fine for us. > > The problem is that we now want to enable another module that relies on the > module we build out of tree. The issue is that the check config sees we have > not enabled our out of tree module and thus the sanitized config does not > contain this module that we want to enable. If we enable the modified module > in the config file there is, of course, a package conflict. > > I have tried using "virtual/mymodule" preferred provider but that fails since > it seems to have a recipe "granularity" and we still need virtual/kernel. I > have also messed around with KERNEL_MODULE_PACKAGE_PREFIX and > KERNEL_MODULES_RDEPENDS_BLACKLIST but I get the sense I'm trying to put a > square peg in a round hole. > > I do realize this is an unusual situation and the question "why don't you > just patch the existing driver in the kernel?" is obvious. We do have our > reasons that I won't go into. > > Is there any obvious way we can simply "eclipse" an existing kernel module > with an out-of-tree module? Is there a way I could add a config fragment > that doesn't get validated/sanitized, for example? > > Regards, > > Russell > > Rename your out of tree module to something else. Patch the module that you want to replace so it does not do anything. Enable it and build it. You can also remove the dependency by patching the Kconfig files. Ulf Samuelsson > > -- > ___ > 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] Managing multiple builds
Den 2019-02-14 kl. 10:00, skrev Alexander Kanavin:
On Thu, 14 Feb 2019 at 01:35, Timothy Froehlich wrote:
Hi, I've been struggling a bit with this question. I want to use Yocto to build two+
products with separate dev/prod images for each (dev including debug-tweaks, etc.). I've
ruled out separate image recipes because my dev builds need ENABLE_UART on my RaspberryPi
and that needs to be set at the conf level (I've got it set conditionally in my base dist
conf). Multiconfig looked promising, but I'm not happy about how long the parsing takes
to start a build. "--postread" looked nice, but I've barely seen it mentioned
so I'm worried that it's not well supported.
Which recipes use the ENABLE_UART setting? You might want to write two
variants of those, and include them into images accordingly.
Alex
Some guys I know solved the problem a little bit differently, and they
did not mind to share.
I created a meta-layer with that and some other ideas.
* https://github.com/emagii/meta-map-sheriffco
An example recipe is:
==
SUMMARY = ""
DESCRIPTION = ""
inherit license-mit
SRC_URI = " \
file://class/class-recipe.c \
file://class/Makefile \
"
EXTRA_OEMAKE_class-development = 'CFLAGS="${CFLAGS} -DDEVELOPMENT"'
EXTRA_OEMAKE_class-production = 'CFLAGS="${CFLAGS} -DPRODUCTION"'
EXTRA_OEMAKE_class-release = 'CFLAGS="${CFLAGS} -DRELEASE"'
do_install-class-development () {
install -d ${D}${bindir}
install -m 0755 class ${D}${bindir}/development
}
do_install-class-production () {
install -d ${D}${bindir}
install -m 0755 class ${D}${bindir}/production
}
do_install-class-release () {
install -d ${D}${bindir}
install -m 0755 class ${D}${bindir}/release
}
BBCLASSEXTEND = "development production release"
==
You now have the same recipe which builds four package variants.
,
-development,
-production,
-release,
The base package is not included in any image.
In the development image, you install the -development and so on.
==
Three bbclasses are used, one for each special package.
Here is the development.bbclass
==
# Class for use in BBCLASSEXTEND to make it easier to have a single
recipe that
# build and generate packages separately for development and normal images.
#
# Usage:
# BBCLASSEXTEND = "development"
CLASSOVERRIDE .= ":class-development"
python development_virtclass_handler () {
# Do nothing if this is inherited, as it's for BBCLASSEXTEND
if "development" not in (d.getVar('BBCLASSEXTEND') or ""):
bb.error("Don't inherit development, use BBCLASSEXTEND")
return
# Restore BPN
bpn = d.getVar('BPN')
newbpn = bpn.replace('-development', '')
d.setVar('BPN', newbpn)
# Use default FILESPATH searching for patches and files
filespath = d.getVar('FILESPATH')
newfilespath = filespath.replace('-development', '')
d.setVar('FILESPATH', newfilespath)
}
addhandler development_virtclass_handler
development_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
==
--
Best Regards
Ulf Samuelsson
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Make one directory writeable
You can use overlayfs for this. You mount the overlayfs on top of your rootfs and then it appear like you have a writeable file system. In reality all the new stuff is written to another (writeable) file system. If you dismount the overlayfs, the rootfs reverts back to its original state. If you again mount the overlayfs, you get your modifications back. Best Regards, Ulf Samuelsson +46 722 427 437 > 13 feb. 2019 kl. 08:21 skrev Bhupendra Singh > : > > Hello > I have built core-image-minimal with read only rootfs then now I want to > make one directory (like /mnt) writable. > Is it possible to make one directory writeable in read only rootfs if yes > ,please tell me how can I do same. > > Bhupendra Singh > > -- > ___ > 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] How to use same user in two recipes?
Den 2017-10-10 kl. 23:30, skrev Fabien Lahoudere:
Hi
I want to use the same user in two different recipe.
I create the user in recipe A.bb and it works fine.
Now I want to use the same user in B.bb so I add DEPENDS = "A" thinking that
sysroot will be
populated with A.bb users.
But when I bitbake the recipe, user is not found.
I conclude that I have to use USERADD_* in each recipe, right?
What happen if I use different USERADD_PARAM_${PN} in each recipe?
I also try to use EXTRA_USERS_PARAMS but without success?
Is there a way to populate sysroot with users?
Thanks
Don't You need to RDEPEND on A?
--
Best Regards
Ulf Samuelsson
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Proper Use of KERNEL_MODULE_AUTOLOAD variable
Maybe it would be good to have a working example in the tree.
Best Regards,
Ulf Samuelsson
> 6 feb. 2019 kl. 02:22 skrev Khem Raj :
>
>
>
>> On Sat, Feb 2, 2019 at 7:17 PM Ken Sloat
>> wrote:
>> On Sat, Feb 2, 2019 at 10:03 PM Bruce Ashfield
>> wrote:
>> >
>> > On 2019-02-02 9:59 p.m., Ken Sloat wrote:
>> > > Hello,
>> > >
>> > > I have an out of tree kernel module which I want autoloaded at startup
>> > > on my system. Looking at the Yocto project manual, I see that one way
>> > > I can do this is to add the module name to the KERNEL_MODULE_AUTOLOAD
>> > > variable within my custom module recipe.
>> > >
>> > > What I have found is that the module-split class is indeed generating
>> > > the "/etc/modules-load.d/mymodule.conf" file, however this file is not
>> > > actually being installed. To be more precise it is appearing in the
>> > > "package" directory (i.e.
>> > > tmp/work/**/mymodule/package/etc/modules-load.d/mymodule.conf) but not
>> > > within the "image" directory (nor in my final rootfs).
>> > >
>> > > Is there something I'm missing in the usage of KERNEL_MODULE_AUTOLOAD?
>> > > Is the intention for this variable I add extra steps to manually
>> > > install this file in my recipe? FYI I'm using Morty.
>> >
>> > Can you provide your recipe ? It would make suggestions easier. For
>> > example, my first question is: Is the module being installed to your
>> > image via IMAGE_INSTALL, or some other similar variable ?
>> >
>> > Bruce
>> >
>> > >
>> > > Thanks,
>> > > Ken Sloat
>> > >
>> >
>>
>> Hi Bruce,
>>
>> Thanks for your quick reply. Yes the module is being installed via
>> image_install. Module is installed but generated conf file is not. See
>> recipe below:
>>
>> require mymodule.inc
>>
>> inherit module kernel-module-split
>>
>> DEPENDS = "virtual/kernel"
>>
>> EXTRA_OEMAKE_append = " \
>> KERNELDIR=${STAGING_KERNEL_DIR} \
>> "
>>
>> MAKE_TARGETS = "module"
>>
>> MODULE_NAME = "mymodule"
>>
>> PKG_${PN} = "kernel-module-${MODULE_NAME}"
>>
>> module_do_install() {
>> install -d ${D}/lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME}
>> install -m 0644 ${MODULE_NAME}.ko \
>>
>> ${D}/lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME}/${MODULE_NAME}.ko
>> }
>>
>> FILES_${PN} = " \
>> /lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME} \
>> "
>
> Your recipe is overwriting common stuff which otherwise should be provided by
> module bbclass
> I would suggest that you append to the variables instead of over writing them
> above and try to reuse
> The primitives from bbclass as much as you can for best results
>>
>>
>> KERNEL_MODULE_AUTOLOAD += "${MODULE_NAME}"
>> --
>> ___
>> 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Proper Use of KERNEL_MODULE_AUTOLOAD variable
> 3 feb. 2019 kl. 20:09 skrev Ken Sloat :
>
>> On Sun, Feb 3, 2019 at 12:51 AM Ulf Samuelsson wrote:
>>
>>> Den 2019-02-03 kl. 04:16, skrev Ken Sloat:
>>> On Sat, Feb 2, 2019 at 10:03 PM Bruce Ashfield
>>> wrote:
>>>>
>>>>> On 2019-02-02 9:59 p.m., Ken Sloat wrote:
>>>>> Hello,
>>>>>
>>>>> I have an out of tree kernel module which I want autoloaded at startup
>>>>> on my system. Looking at the Yocto project manual, I see that one way
>>>>> I can do this is to add the module name to the KERNEL_MODULE_AUTOLOAD
>>>>> variable within my custom module recipe.
>>>>>
>>>>> What I have found is that the module-split class is indeed generating
>>>>> the "/etc/modules-load.d/mymodule.conf" file, however this file is not
>>>>> actually being installed. To be more precise it is appearing in the
>>>>> "package" directory (i.e.
>>>>> tmp/work/**/mymodule/package/etc/modules-load.d/mymodule.conf) but not
>>>>> within the "image" directory (nor in my final rootfs).
>>>>>
>>>>> Is there something I'm missing in the usage of KERNEL_MODULE_AUTOLOAD?
>>>>> Is the intention for this variable I add extra steps to manually
>>>>> install this file in my recipe? FYI I'm using Morty.
>>>>
>>>> Can you provide your recipe ? It would make suggestions easier. For
>>>> example, my first question is: Is the module being installed to your
>>>> image via IMAGE_INSTALL, or some other similar variable ?
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>> Thanks,
>>>>> Ken Sloat
>>>>>
>>>>
>>>
>>> Hi Bruce,
>>>
>>> Thanks for your quick reply. Yes the module is being installed via
>>> image_install. Module is installed but generated conf file is not. See
>>> recipe below:
>>>
>>> require mymodule.inc
>>>
>>> inherit module kernel-module-split
>>>
>>> DEPENDS = "virtual/kernel"
>>>
>>> EXTRA_OEMAKE_append = " \
>>> KERNELDIR=${STAGING_KERNEL_DIR} \
>>> "
>>>
>>> MAKE_TARGETS = "module"
>>>
>>> MODULE_NAME = "mymodule"
>>>
>>> PKG_${PN} = "kernel-module-${MODULE_NAME}"
>>>
>>> module_do_install() {
>>> install -d ${D}/lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME}
>>> install -m 0644 ${MODULE_NAME}.ko \
>>>
>>> ${D}/lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME}/${MODULE_NAME}.ko
>>> }
>>>
>>> FILES_${PN} = " \
>>> /lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME} \
>>> "
>>>
>>> KERNEL_MODULE_AUTOLOAD += "${MODULE_NAME}"
>>>
>>
>> One would think that the file should be added automatically,
>> but this might be required, - or a workaround...
>>
>> FILES_${PN} = " \
>> /lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME} \
>> ${sysconfdir}/modules-load.d/${MODULE_NAME}.conf \
>> "
>>
>>
>> --
>> Best Regards
>> Ulf Samuelsson
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
> Hi Ulf,
>
> Yes it seems that this indeed allows it to end up in the final image.
>
> Not sure why it doesn't work without as I see the kernel-module-split
> class seems to have statements to do this automatically:
>
>files = d.getVar('FILES_%s' % pkg, True)
>files = "%s /etc/modules-load.d/%s.conf
> /etc/modprobe.d/%s.conf" % (files, basename, basename)
>d.setVar('FILES_%s' % pkg, files)
>
> Maybe there's some type of name mismatch or something in my case?
>
> Thanks,
> Ken Sloat
I would log those statements when building.
Either pkg, or basename has a different value, than what is expected.
Best Regards,
Ulf Samuelsson
+46 722 427 437
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Proper Use of KERNEL_MODULE_AUTOLOAD variable
Den 2019-02-03 kl. 04:16, skrev Ken Sloat:
On Sat, Feb 2, 2019 at 10:03 PM Bruce Ashfield
wrote:
On 2019-02-02 9:59 p.m., Ken Sloat wrote:
Hello,
I have an out of tree kernel module which I want autoloaded at startup
on my system. Looking at the Yocto project manual, I see that one way
I can do this is to add the module name to the KERNEL_MODULE_AUTOLOAD
variable within my custom module recipe.
What I have found is that the module-split class is indeed generating
the "/etc/modules-load.d/mymodule.conf" file, however this file is not
actually being installed. To be more precise it is appearing in the
"package" directory (i.e.
tmp/work/**/mymodule/package/etc/modules-load.d/mymodule.conf) but not
within the "image" directory (nor in my final rootfs).
Is there something I'm missing in the usage of KERNEL_MODULE_AUTOLOAD?
Is the intention for this variable I add extra steps to manually
install this file in my recipe? FYI I'm using Morty.
Can you provide your recipe ? It would make suggestions easier. For
example, my first question is: Is the module being installed to your
image via IMAGE_INSTALL, or some other similar variable ?
Bruce
Thanks,
Ken Sloat
Hi Bruce,
Thanks for your quick reply. Yes the module is being installed via
image_install. Module is installed but generated conf file is not. See
recipe below:
require mymodule.inc
inherit module kernel-module-split
DEPENDS = "virtual/kernel"
EXTRA_OEMAKE_append = " \
KERNELDIR=${STAGING_KERNEL_DIR} \
"
MAKE_TARGETS = "module"
MODULE_NAME = "mymodule"
PKG_${PN} = "kernel-module-${MODULE_NAME}"
module_do_install() {
install -d ${D}/lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME}
install -m 0644 ${MODULE_NAME}.ko \
${D}/lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME}/${MODULE_NAME}.ko
}
FILES_${PN} = " \
/lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME} \
"
KERNEL_MODULE_AUTOLOAD += "${MODULE_NAME}"
One would think that the file should be added automatically,
but this might be required, - or a workaround...
FILES_${PN} = " \
/lib/modules/${KERNEL_VERSION}/kernel/${MODULE_NAME} \
${sysconfdir}/modules-load.d/${MODULE_NAME}.conf \
"
--
Best Regards
Ulf Samuelsson
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] adding task before a task T but after all other tasks that T depends on?
Is there a way to express this? Assume three classes X,Y,Z, each adding a task. X: addtask x after S before T Y: addtask y after S before T Z: addtask w after S before T Images might inherit one of the classes X,Y,Z. Thus x, y, or z might run, but only one of them, and which depends on the image I build. How do I add a task z, which runs after any of x,y,z, but before T? The list of possible tasks might be extended in the future, so I really would want to specify: ”addtask w after T[depends] before T” or similar. Best Regards, Ulf Samuelsson -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] bb.build.addtask: add simple check for circular dependency
> 18 jan. 2019 kl. 16:56 skrev Alexander Kanavin : > > > >>> On 18 Jan 2019, at 16.34, Burton, Ross wrote: >>> >>> On Fri, 18 Jan 2019 at 15:08, Ulf Samuelsson wrote: >>> We could insert a check if the KNOWN_TASKS is valid in a verification test. >>> When building core-image-minimal, the task order within core-image-minimal >>> is analyzed, (dependencies on all other recipes is filtered away). >>> Then you find out if there are tasks added, missing, and/or in the wrong >>> order. >> >> What about people who add new tasks? Do they now need to go and >> extend KNOWN_TASKS correctly too? > > I might be missing something, but isn’t the right moment to detect loops when > the task graph is fully formed? Then just run generic DFS on it, not a > difficult or heavy algorithm. > > Alex The problem in our system was that the build crashed before that. Best Regards, Ulf Samuelsson -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] bb.build.addtask: add simple check for circular dependency
> 18 jan. 2019 kl. 15:40 skrev Richard Purdie > : > > On Fri, 2019-01-18 at 15:16 +0100, Ulf Samuelsson wrote: >>> 18 jan. 2019 kl. 12:29 skrev Richard Purdie < >>> richard.pur...@linuxfoundation.org>: >>> >>>> On Fri, 2019-01-18 at 05:30 +0100, Ulf Samuelsson wrote: >>>> So if KNOWN_TASKS is defined in a configuration file in oe-core, >>>> it >>>> would be OK? >>>> It needs to be extended to check for KNOWN_TASKS == None of >>>> course. >>> >>> No, this is too fragile. We then have to maintain two different >>> lists >>> of tasks. If we did that we may as well just remove the generic >>> tasks >>> mechanism and hardcode the tasks list in the metadata. >>> >> Why do we need two lists? > > If we change one of these "generic" tasks, we then need to remember to > also update KNOWN_TASKS. The same information is being encoded in two > places. > > Maintaining the same information in two different places means one of > those places inevitably ends up out of date. We could insert a check if the KNOWN_TASKS is valid in a verification test. When building core-image-minimal, the task order within core-image-minimal is analyzed, (dependencies on all other recipes is filtered away). Then you find out if there are tasks added, missing, and/or in the wrong order. Best Regards, Ulf Samuelsson > >> We need to know in what order the generic tasks are executed, that is >> all. >> >> Then we need to see if an addtask is violating that order. >> If the ”after” or ”before” is not a generic task, the check cannot >> catch that. >> >> If the user decides to not use the generic tasks, and create new ones >> with the same name, as the generic tasks, but rearranges the order, >> there will be a problem, but I do not see any other problems. >> >> Please enlighten me! > > This has the problem that the code will find some subset of the bugs > but not all of them. We'll then get users reporting that the tests > failed and asking for the checks to be improved. > > So no, we are not doing this, sorry. > > Cheers, > > Richard > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] bb.build.addtask: add simple check for circular dependency
> 18 jan. 2019 kl. 12:29 skrev Richard Purdie > : > >> On Fri, 2019-01-18 at 05:30 +0100, Ulf Samuelsson wrote: >> So if KNOWN_TASKS is defined in a configuration file in oe-core, it >> would be OK? >> It needs to be extended to check for KNOWN_TASKS == None of course. > > No, this is too fragile. We then have to maintain two different lists > of tasks. If we did that we may as well just remove the generic tasks > mechanism and hardcode the tasks list in the metadata. > Why do we need two lists? We need to know in what order the generic tasks are executed, that is all. Then we need to see if an addtask is violating that order. If the ”after” or ”before” is not a generic task, the check cannot catch that. If the user decides to not use the generic tasks, and create new ones with the same name, as the generic tasks, but rearranges the order, there will be a problem, but I do not see any other problems. Please enlighten me! > As I mentioned, we need to come up with something which detects the > task loops generically. > > Cheers, > > Richard > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] bb.build.addtask: add simple check for circular dependency
So if KNOWN_TASKS is defined in a configuration file in oe-core, it would be OK? It needs to be extended to check for KNOWN_TASKS == None of course. Best Regards, Ulf Samuelsson +46 722 427 437 > 18 jan. 2019 kl. 00:17 skrev Burton, Ross : > > On Thu, 17 Jan 2019 at 22:50, Ulf Samuelsson wrote: >>> We really can't hardcode a list of tasks like this in bitbake :( >>> >>> The list is also incorrect (at a quick look its packagedata and >>> populate_sysroot is missing). >> >> I would say it may be incomplete, but it is only wrong, if they are in the >> wrong order. > > Richard's point was that those task names are oe-core specific. > Bitbake doesn't know or care about the specific names. > > Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] bb.build.addtask: add simple check for circular dependency
> 17 jan. 2019 kl. 22:05 skrev Richard Purdie
> :
>
>> On Thu, 2019-01-17 at 19:15 +0100, Ulf Samuelsson wrote:
>> From 864e49bedbdab480c5ada9588ce8f980f23919dd Mon Sep 17 00:00:00
>> 2001
>> From: Ulf Samuelsson
>> Date: Thu, 17 Jan 2019 19:07:17 +0100
>> Subject: [PATCH] bb.build.addtask: add simple check for circular
>> dependency
>
> We really can't hardcode a list of tasks like this in bitbake :(
>
> The list is also incorrect (at a quick look its packagedata and
> populate_sysroot is missing).
I would say it may be incomplete, but it is only wrong, if they are in the
wrong order.
>
> We'll need to come up with a better algorithm than this. From
> experience with circular task dependencies within bitbake's runqueue,
> this is a hard problem though.
It is an attempt to do a reasonable effort.
It will not handle a lot of user tasks which depends on each other for sure...
Is it better to have no detection, than a detection which works on the most
common cases?
I will not have the time to look into a clean cover all cases algorithm,
unfortunately.
Best Regards,
Ulf Samuelsson
>
> Cheers,
>
> Richard
>
>> Signed-off-by: Ulf Samuelsson
>> ---
>> bitbake/lib/bb/build.py | 48
>>
>> 1 file changed, 48 insertions(+)
>>
>> diff --git a/bitbake/lib/bb/build.py b/bitbake/lib/bb/build.py
>> index 3e2a94e..887ced1 100644
>> --- a/bitbake/lib/bb/build.py
>> +++ b/bitbake/lib/bb/build.py
>> @@ -43,6 +43,25 @@ logger = logging.getLogger('BitBake.Build')
>>
>> __mtime_cache = {}
>>
>> +KNOWN_TASKS = {
>> +'do_fetch' : 1 ,
>> +'do_unpack' : 2 ,
>> +'do_patch' : 3 ,
>> +'do_configure' : 4 ,
>> +'do_compile' : 5 ,
>> +'do_install' : 6 ,
>> +'do_package' : 7 ,
>> +'do_package_data' :8 ,
>> +'do_rootfs' : 9 ,
>> +'do_image_qa' : 10 ,
>> +'do_image' : 11 ,
>> +'do_image_tar' : 12 ,
>> +'do_image_ubifs' :12 ,
>> +'do_image_jffs2' :12 ,
>> +'do_image_complete' : 13 ,
>> +'do_build' : 14
>> +}
>> +
>> def cached_mtime_noerror(f):
>> if f not in __mtime_cache:
>> try:
>> @@ -820,7 +839,34 @@ def add_tasks(tasklist, d):
>> # don't assume holding a reference
>> d.setVar('_task_deps', task_deps)
>>
>> +def circular(after, before):
>> +if after == None:
>> +return False
>> +if before == None:
>> +return False
>> +for a in after.split():
>> +if a in KNOWN_TASKS:
>> +for b in before.split():
>> +if a == b:
>> +return True
>> +if b in KNOWN_TASKS:
>> +if KNOWN_TASKS[b] < KNOWN_TASKS[a]:
>> +return True
>> +else:
>> +# tasks OK
>> +pass
>> +else:
>> +# b is unknown
>> +pass
>> +else:
>> +# a is unknown
>> +pass
>> +
>> def addtask(task, before, after, d):
>> +if circular(after, before):
>> +logger.error("addtask: %s cannot be after %s and before %s"
>> %
>> (task, after, before))
>> +raise
>> +
>> if task[:3] != "do_":
>> task = "do_" + task
>>
>> @@ -909,3 +955,5 @@ def tasksbetween(task_start, task_end, d):
>> chain.pop()
>> follow_chain(task_start, task_end)
>> return outtasks
>> +
>> +
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] bb.build.addtask: add simple check for circular dependency
From 864e49bedbdab480c5ada9588ce8f980f23919dd Mon Sep 17 00:00:00 2001
From: Ulf Samuelsson
Date: Thu, 17 Jan 2019 19:07:17 +0100
Subject: [PATCH] bb.build.addtask: add simple check for circular dependency
Signed-off-by: Ulf Samuelsson
---
bitbake/lib/bb/build.py | 48
1 file changed, 48 insertions(+)
diff --git a/bitbake/lib/bb/build.py b/bitbake/lib/bb/build.py
index 3e2a94e..887ced1 100644
--- a/bitbake/lib/bb/build.py
+++ b/bitbake/lib/bb/build.py
@@ -43,6 +43,25 @@ logger = logging.getLogger('BitBake.Build')
__mtime_cache = {}
+KNOWN_TASKS = {
+'do_fetch' : 1 ,
+'do_unpack' : 2 ,
+'do_patch' : 3 ,
+'do_configure' : 4 ,
+'do_compile' : 5 ,
+'do_install' : 6 ,
+'do_package' : 7 ,
+'do_package_data' :8 ,
+'do_rootfs' : 9 ,
+'do_image_qa' : 10 ,
+'do_image' : 11 ,
+'do_image_tar' : 12 ,
+'do_image_ubifs' :12 ,
+'do_image_jffs2' :12 ,
+'do_image_complete' : 13 ,
+'do_build' : 14
+}
+
def cached_mtime_noerror(f):
if f not in __mtime_cache:
try:
@@ -820,7 +839,34 @@ def add_tasks(tasklist, d):
# don't assume holding a reference
d.setVar('_task_deps', task_deps)
+def circular(after, before):
+if after == None:
+return False
+if before == None:
+return False
+for a in after.split():
+if a in KNOWN_TASKS:
+for b in before.split():
+if a == b:
+return True
+if b in KNOWN_TASKS:
+if KNOWN_TASKS[b] < KNOWN_TASKS[a]:
+return True
+else:
+# tasks OK
+pass
+else:
+# b is unknown
+pass
+else:
+# a is unknown
+pass
+
def addtask(task, before, after, d):
+if circular(after, before):
+logger.error("addtask: %s cannot be after %s and before %s" %
(task, after, before))
+raise
+
if task[:3] != "do_":
task = "do_" + task
@@ -909,3 +955,5 @@ def tasksbetween(task_start, task_end, d):
chain.pop()
follow_chain(task_start, task_end)
return outtasks
+
+
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbake: DataSmart.expandWithRefs causing exception when handed "${@...}"
Den 2019-01-15 kl. 14:38, skrev Richard Purdie:
On Sun, 2019-01-13 at 22:53 +0100, Ulf Samuelsson wrote:
I am trying to add a new image class "SWU" in "sumo" for a "software
update image".
As a result:
do_sdk_depends[depends] = '${@get_ext_sdk_depends(d)} meta-extsdk-
toolchain:do_populate_sysroot'
When data_smart.py works on this, it will call
DataSmart.expandWithRefs(self, s, varname)
s= '${@get_ext_sdk_depends(d)} meta-extsdk-
toolchain:do_populate_sysroot'
varname = 'do_sdk_depends[depends]'
I will get an exception in this statement:
while s.find('${') != -1:
olds = s
try:
s = __expand_var_regexp__.sub(varparse.var_sub, s)
The definition of __expand_var_regexp__ is:
__expand_var_regexp__ = re.compile(r"\${[^{}@\n\t :]+}")
That is, it is looking for the string "${}"
but may not contains anything in [{}@\n\t :]
since the "variable" in "s" is actually a call to
get_ext_sdk_depends,
and thus contains a '@' character it is not matched.
The build aborts with an exception.
I am not sure, if '${@get_ext_sdk_depends(d)}' should be expanded
before
DataSmart,expandWithRefs, or if expandWithRefs needs to be extended
to handle the case where the variable is a "call".
This is blocking us from upgrading from pyro to sumo.
Any ideas on a solution?
Can you firstly say what the error is you're seeing. Your attempt to
understand it is good but I'm not sure which error you see?
Secondly, is there a way someone else could reproduce this bug?
The fragment you quote looks correct. If you have variable and function
names conflicting that would be a problem though as they're all in the
same namespace. I'm unclear whether that is a problem here or not
though based on the available information.
Cheers,
Richard
I found the problem.
The "image_swu.bbclass" in the customer contained a statement:
"addtask do_packageswu after do_image_complete before do_image_qa"
The dependencies of the image recipe is:
do_fetch
do_prepare_recipe_sysroot:do_fetch
do_unpack:do_fetch
do_patch: do_unpack
do_populate_lic: do_patch
do_configure: do_patch
do_compile: do_configure
do_install: do_compile
do_package: do_install
do_package_data: do_package
do_rootfs:do_package_data \
do_prepare_recipe_sysroot \
do_populate_lic
1do_image_qa: do_rootfs
do_image: do_image_qa do_rootfs
do_image_tar: do_image
2do_image_complete:do_image_tar do_image
do_build do_image_complete \
do_package_data \
do_populate_lic
The addtask statement want something which is after (2) but before (1)
and bitbake responds by creating a circular dependency.
When I changed this to:
"addtask do_packageswu after do_image_ubifs before do_image_complete"
the build works.
(the swu image will work on a previously created file system, which
happens to be ubifs in this case)
I think a simple good improvement would be to have an addtask
check if this would create a circular dependency.
KNOWN_TASKS = [ 'do_fetch', 'do_unpack', ... , 'do_build' ]
# Some tasks which has a fuzzy order like do_prepare_recipe_sysroot
# may have to be omitted.
TASK_ORDER['do_fetch'] = 1
...
TASK_ORDER['do_build'] =
def circular(before, after)
if not before in KNOWN_TASKS
return false
if not after in KNOWN_TASKS:
return false
before_prio = TASK_ORDER[before]
after_prio = TASK_ORDER[after]
return after_prio > before_prio
This would at least catch the more common tasks, and would be quick,
since the particular recipe would not have to be parsed.
Where could such code be added (not used to hacking bitbake)?
A better implementation would of course analyze the specific recipe
before accepting the addtask statement.
--
Best Regards
Ulf Samuelsson
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] bitbake: DataSmart.expandWithRefs causing exception when handed "${@...}"
I am trying to add a new image class "SWU" in "sumo" for a "software
update image".
As a result:
do_sdk_depends[depends] = '${@get_ext_sdk_depends(d)}
meta-extsdk-toolchain:do_populate_sysroot'
When data_smart.py works on this, it will call
DataSmart.expandWithRefs(self, s, varname)
s= '${@get_ext_sdk_depends(d)}
meta-extsdk-toolchain:do_populate_sysroot'
varname = 'do_sdk_depends[depends]'
I will get an exception in this statement:
while s.find('${') != -1:
olds = s
try:
s = __expand_var_regexp__.sub(varparse.var_sub, s)
The definition of __expand_var_regexp__ is:
__expand_var_regexp__ = re.compile(r"\${[^{}@\n\t :]+}")
That is, it is looking for the string "${}"
but may not contains anything in [{}@\n\t :]
since the "variable" in "s" is actually a call to get_ext_sdk_depends,
and thus contains a '@' character it is not matched.
The build aborts with an exception.
I am not sure, if '${@get_ext_sdk_depends(d)}' should be expanded before
DataSmart,expandWithRefs, or if expandWithRefs needs to be extended
to handle the case where the variable is a "call".
This is blocking us from upgrading from pyro to sumo.
Any ideas on a solution?
BR
Ulf Samuelsson
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Keeping and modifying Source code in Yocto
externalsrc.bbclass? In my current project we have a simplified version in a ”component.bbclass”. It relies on a variable COMPONENT_DIR defined in our local.conf. A recipe located in ”recipe-//_$PV.bb” doing inherit component will find its source code in $COMPONENT_DIR/, making the recipe simpler than that of the externalsrc bbclass. No need for SRC_URI statements. We check out meta layers and the components using repo so the components are always located in $COMPONENTS_DIR. Been thinking of upstreaming this, but I am unsure about the interest. Best Regards, Ulf Samuelsson > 6 juli 2018 kl. 17:27 skrev Tim Hammer : > > >> On Fri, Jul 6, 2018 at 11:20 AM, Simon Chamlian >> wrote: > >> Hi, >> >> Is there a way to keep the source code of a package to be able to modify it >> and then compile? >> >> For example, with LTIB ( Linux Target Image Builder ), it was possible with >> a command to extract the source code from a package, make modifications and >> then re-compile? >> > > I suggest you take a look at the devtool: > https://www.yoctoproject.org/software-item/devtool/ > > https://wiki.yoctoproject.org/wiki/TipsAndTricks/Patching_the_source_for_a_recipe > > >> Thanks, >> S >> >> >> >> >> >> >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto >> > > > > -- > > .Tim > -- > ___ > 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] How handle files needing updates in read-only filesystem
Thanks, is it more efficient than symlinking? Best Regards, Ulf Samuelsson > 13 juni 2018 kl. 15:20 skrev Anders Darander : > > * Ulf Samuelsson [180612 22:01]: > >> We want most of /etc to be read-only for security reasons, >> and the overlayfs will make the whole of /etc writeable. > >> I tried mount —bind /etc/timezone /persistent/etc/timezone, and it >> complained that they were not directories. Bind mounting /etc again >> will make all of /etc writeable. > > Try to use: mount —o bind /etc/timezone /persistent/etc/timezone > > I'm using that heavily, either manually or by the volatile-binds recipe. > It works perfectly fine with files. > >> Symlinking to /persistent is fine, so the question is what an >> acceptable method is to have a simple way of ensuring that a certain >> file is converted to that symlink. > > This is normally done by a manual inspection / addition of bbappend > file. > > Cheers, > Anders > -- > Anders Darander, Senior System Architect > ChargeStorm AB / eStorm AB -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image specific configuration files
In my current project they have defined bbclass files to allow variants of
recipes.
The recipe would then contain do_install_append_XYZ’s for each class.
BBCLASSEXTEND = ”production rnd retail”
would ensure you would get nginx-production, nginx-rnd, nginx-retail ipks.
This way you have one recipe generating three variants in the same build.
Don’t have the source in front of me so I can’t share the bbclass (right now
at least)
Best Regards,
Ulf Samuelsson
+46 722 427 437
> 1 juni 2018 kl. 12:40 skrev Alan Martinovic :
>
> Yes, much better phrasing:
>
> > A single bitbake invocation always builds a single distro for a specific
> > target machine
>
> Thanks
>
>> On Fri, Jun 1, 2018 at 12:18 PM, Alexander Kanavin
>> wrote:
>> If a build is 'a single bitbake invocation', then yes - it builds for a
>> single distro and for a specific target machine, but it can build multiple
>> recipes (which includes multiple images, as images are defined with recipes).
>>
>> Alex
>>
>>
>> 2018-06-01 13:07 GMT+03:00 Alan Martinovic :
>>> Hey Alexander,
>>> you seem to have a good understanding on the concepts.
>>> Would you say that:
>>>
>>> > A build always builds a single distro
>>>
>>> is somewhat of a rule?
>>>
>>>
>>>
>>>
>>>> On Fri, Jun 1, 2018 at 11:24 AM, Alexander Kanavin
>>>> wrote:
>>>> I have to say defining multiple distros and then tweaking recipes
>>>> according to those definitions is not a good practice, as recipes should
>>>> generally only access DISTRO_FEATURES and otherwise be distro-agnostic.
>>>> The above iptables scenario should be handled with different image
>>>> recipes, which pull in (via packages) or create different configurations.
>>>>
>>>> Alex
>>>>
>>>> 2018-06-01 12:04 GMT+03:00 Iván Castell :
>>>>> I can provide more details. My custom layer has these files related with
>>>>> distro:
>>>>>
>>>>> my_layer/conf/distro/include/common.conf
>>>>> my_layer/conf/distro/develop.conf
>>>>> my_layer/conf/distro/production.conf
>>>>> my_layer/conf/distro/integration.conf
>>>>>
>>>>> As an example of the previous files,
>>>>> my_layer/conf/distro/include/develop.conf has this content:
>>>>>
>>>>> require conf/distro/include/common.conf
>>>>> DISTRO = "my-distro-development"
>>>>> DISTRO_NAME = "OS Development"
>>>>> DISTRO_STAGE = "development"
>>>>> # And here more customizations as setting root password, PRSERV_HOST,
>>>>> or PACKAGE_FEED_URIS
>>>>>
>>>>> In common.conf I define all features common to all my distros
>>>>> (PACKAGE_CLASSES and so on)
>>>>>
>>>>> I have custom iptables rules, then I have different files for that rules:
>>>>>
>>>>> my/layer/recipes-extended/iptables/files/iptables.rules.development
>>>>> my/layer/recipes-extended/iptables/files/iptables.rules.production
>>>>> my/layer/recipes-extended/iptables/files/iptables.rules.integration
>>>>>
>>>>> I use a bbappend recipe for iptables, modifiying do_install_append task
>>>>> like this:
>>>>>
>>>>> install -m 0600 ${WORKDIR}/iptables.rules.${DISTRO_STAGE}
>>>>> ${D}/etc/iptables/iptables.rules
>>>>>
>>>>> I use a single image recipe to define all packages installed in my final
>>>>> image (all of them have the same set if packages, but with different
>>>>> customizations)
>>>>>
>>>>> Finally, I wrote a setup-build-env.sh script in my custom layer to
>>>>> configure the build easily. That script creates
>>>>> build-${DISTRO_STAGE}/conf/bblayers.conf and
>>>>> build-${DISTRO_STAGE}/conf/local.conf files with the proper setup,
>>>>> setting MACHINE, DISTRO and DL_DIR (shared by all distros) properly.
>>>>>
>>>>> Hope this helps!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2018-06-01 10:21 GMT+02:00 Alan Martinovic :
>>>>>> Hey,
>>>>>> would really like to see your example.
&g
Re: [yocto] Adding kernel module to yocto core-image-base
There is an example in meta-skeleton/recipes-kernel
Best Regards,
Ulf Samuelsson
> 12 juni 2018 kl. 09:33 skrev Iván Castell :
>
> Hello.
>
> First you need to reconfigure your kernel configuration (ncurses must be
> properly installed in your host PC):
>
> $ bitbake -c menuconfig virtual/kernel
>
> After you need to generate a fragment.cfg (containing a diff betweeen your
> default and your recently customized kernel config):
>
> $ bitbake -c diffconfig virtual/kernel
>
> Thak will generate the fragment.cfg fine into your ${WORKDIR}
>
> Then you need to create a bbappend in your own BSP layer extending the
> content of your working kernel recipe. Something similar to this:
>
> $ cat your-custom-bsp-layer/recipes-kernel/linux/linux-kernel_%.bbappend
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> SUMMARY = "Linux kernel customization for your board"
> LINUX_VERSION = "x.y.z"
>
> inherit kernel
>
> SRC_URI += " \
> file://fragment.cfg \
> "
>
> Just replace x.y.z by your specific kernel version. The fragment.cfg file
> must be available inside your own kernel recipe, in a directory named ${PN}
> (as indicated by FILESEXTRAPATHS_prepend):
>
> $ ls your-custom-bsp-layer/recipes-kernel/linux/linux-kernel
> fragment.cfg
>
> Then you already can build your new kernel:
>
> $ bitbake virtual/kernel
>
> Hope this helps!
>
> --
> ___
> 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] Issue when integrating different bsp-layers on a single bblayers.conf
Maybe something similar to this in local.conf
BBMASK .= "${@base_conditional('MACHINE', '',
'','|meta-rockchip/recipes-*', d)}"
(did not test)
If there are multiple machines in the meta-rockchip layer, you have to look for
a unique variable which is true only if a machine in the meta-rockchip layer is
used.
Best Regards,
Ulf Samuelsson
> 7 juni 2018 kl. 16:39 skrev Iván Castell :
>
> Hello forum.
>
> I am trying to integrate several BSP-layers for different platforms on a
> single Yocto repository to build a Linux Yocto-based distro for all those
> platforms easily.
>
> The idea is maintaining a single bblayers.conf with all the layers available,
> set PLATFORM and DISTRO on local.conf, call bitbake and get the final
> image for that platform.
>
> When setting the "build" directory with a bblayers.conf customized for a
> single platform, each platform builds the image recipe properly.
>
> However, when I have integrated all bsp-layers in a single bblayers.conf, the
> compilation of some platforms has been broken.
>
> The specific problem is this: one bsp layer (meta-rockchip +
> meta-rockchip-extra) defines a recipes-graphics/mesa/mesa_%.bbappend with
> this content inside:
>
> PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/egl
> virtual/libwayland-egl"
>
> That alters gstreamer recipe on the poky layer, getting this error when
> building for a meta-intel platform:
>
> ERROR: Nothing PROVIDES 'virtual/egl' (but
> /data/yocto/yocto/sources/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.2.bb,
>
> /data/yocto/yocto/sources/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.12.2.bb
> DEPENDS on or otherwise requires it)
>
> My questions:
>
> - Is a good practice to define a custom bblayers.conf depending on the
> choosen PLATFORM?
> - Is there some any other way to disable a BSP-layer completely when
> building for a different one?
> - Can you suggest a fix to solve this issue?
>
> Thanks a lot in advance! :)
>
> Kind regards.
> -- Ivan
>
>
> --
> ___
> 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] Image specific configuration files
You can create three separate recipes that generate three different nginx configurations and include one if them in each image recipe. Best Regards, Ulf Samuelsson > 1 juni 2018 kl. 07:46 skrev Damien LEFEVRE : > > Hi, > > For the same MACHINE I create the following images: > - myimage-production > - myimage-rnd > - myimage-retail > > The production one has production assisted tools for flashing peripheral HW, > testing vital HW components, writing some serial numbers, etc. > > The rnd one has more packages than the retail one just to help rnd work and > debugging in device, but none of the rnd image extra packages. > > The retail one has the final product image. > > I'm using web and FTP servers. I would like for the rnd version of the image > to have a different nginx configuration to set the root directory to a > development folder, or set an alias. > > Furthermore, I'll have different variant of the device where only the device > SW changes but the platform is identical. So I'll end up with > - myimage2-production > - myimage2-rnd > - myimage2-retail > > I know how to make MACHINE based configuration. How could I do this in my > nginx.bbappend based on image name? > > Thanks, > -Damien > -- > ___ > 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] Issue when integrating different bsp-layers on a single bblayers.conf
You can BBMASK away that bbappend when you are not building the rockchip machine. Best Regards, Ulf Samuelsson > 7 juni 2018 kl. 16:39 skrev Iván Castell : > > Hello forum. > > I am trying to integrate several BSP-layers for different platforms on a > single Yocto repository to build a Linux Yocto-based distro for all those > platforms easily. > > The idea is maintaining a single bblayers.conf with all the layers available, > set PLATFORM and DISTRO on local.conf, call bitbake and get the final > image for that platform. > > When setting the "build" directory with a bblayers.conf customized for a > single platform, each platform builds the image recipe properly. > > However, when I have integrated all bsp-layers in a single bblayers.conf, the > compilation of some platforms has been broken. > > The specific problem is this: one bsp layer (meta-rockchip + > meta-rockchip-extra) defines a recipes-graphics/mesa/mesa_%.bbappend with > this content inside: > > PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/egl > virtual/libwayland-egl" > > That alters gstreamer recipe on the poky layer, getting this error when > building for a meta-intel platform: > > ERROR: Nothing PROVIDES 'virtual/egl' (but > /data/yocto/yocto/sources/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.12.2.bb, > > /data/yocto/yocto/sources/poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.12.2.bb > DEPENDS on or otherwise requires it) > > My questions: > > - Is a good practice to define a custom bblayers.conf depending on the > choosen PLATFORM? > - Is there some any other way to disable a BSP-layer completely when > building for a different one? > - Can you suggest a fix to solve this issue? > > Thanks a lot in advance! :) > > Kind regards. > -- Ivan > > > -- > ___ > 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] How handle files needing updates in read-only filesystem
Thanks,
We want most of /etc to be read-only for security reasons,
and the overlayfs will make the whole of /etc writeable.
I tried mount —bind /etc/timezone /persistent/etc/timezone, and it complained
that they were not directories. Bind mounting /etc again will make all of /etc
writeable.
Symlinking to /persistent is fine, so the question is what an acceptable method
is to have a simple way of ensuring that a certain file is converted to that
symlink.
Best Regards,
Ulf Samuelsson
+46 722 427 437
10 juni 2018 kl. 01:36 skrev Peter Kjellerstedt :
>> -Original Message-
>> From: yocto-boun...@yoctoproject.org [mailto:yocto-
>> boun...@yoctoproject.org] On Behalf Of Ulf Samuelsson
>> Sent: den 9 juni 2018 11:51
>> To: yocto@yoctoproject.org
>> Subject: [yocto] How handle files needing updates in read-only
>> filesystem
>>
>> We have a rootfs which is read-only.
>> For files that needs to be updated, like "/etc/localtime"
>> we will create a symbolic link to a partition (/persistent) which
>> is retained between rootfs image updates.
>>
>> /etc/localtime -> /persistent/etc/localtime
>>
>> The original recipe will generate the real /etc/localtime of course.
>>
>> To support the file beeing updated, the following needs to be done in a
>> rootfs postprocess.
>>
>> mv /etc/localtime /update/etc/localtime
>> ln -sf /persistent/etc/localtime /etc/localtime
>> install -m 0644 /update/etc/localtime /persistent/etc/localtime
>> chown : /persistent/etc/localtime
>>
>> The last two commands needs to be executed on the running system,
>> since /persistent is not part of the rootfs.
>>
>> To ensure that the file can be updated is an ad-hoc activity for each
>> affected file. It would be better if there was a class where you
>> declare
>> a file to be writeable, and then a post process
>> would move the file to /update (or similar) and create a symbolic link
>>
>> SETTINGS ?= "/persistent"
>> =
>> inherit writeable
>>
>> WRITEABLE = "/etc/localtime"
>> =
>>
>> This would generate the first two commands for each listed file.
>>
>> mv /etc/localtime /update/etc/localtime
>> ln -sf ${SETTINGS}/etc/localtime /etc/localtime
>>
>> The file would also be added to a file indicating that it may need
>> to be copied to the ${SETTINGS}
>>
>> Is it a good solution to modify "populate_volatiles.sh"
>> to support a second file parameter for the f (file) command
>> in the /etc/default/volatiles file?
>>
>> Today the file create command looks like:
>> f
>>
>> An idea would be to have the following syntax:
>> f
>>
>> If is a valid filepath, then copy this file to
>> If is not a valid filepath, create using "touch"
>>
>> This would break any build which has a "funny" volatiles file.
>> Otherwise a script called populate_persistent.sh could be
>> created with such an extension.
>>
>> Comments?
>>
>> BR
>> Ulf Samuelsson
>
> Since a lot of files in /etc typically need to be writable, one way to
> handle this is by using an overlayfs for /etc. That is what we do and
> it works very well.
>
> An alternative, more along your suggestion, is to use bind mounts. The
> advantage of using a bind mount instead of a symbolic link is that it
> will look as a normal file.
>
> You should look into the volatile-binds recipe and the VOLATILE_BINDS
> variable. It is used to handle directories that need to be writable.
> It will create systemd service files that copies the non-volatile
> directory to the volatile directory (if it does not already exists),
> and the bind mounts it back.
>
> I am not sure volatile-binds works out-of-the-box for files, but I
> believe it does. If not, it should not be too hard to modify it so
> that it can handle files as well.
>
> //Peter
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fwd: image-mklibs.bbclass fails
I am currently upgrading a morty based rootfs to rocko, and today I found that
the morty based poky layer had a patch which they sent upstream over one year
ago.
Author Peter Liu
This is similar to what You suggested, and the fix works also in rocko.
We will decide tomorrow how to proceed.
Best Regards,
Ulf
> 29 maj 2018 kl. 21:43 skrev Khem Raj :
>
>> On Mon, May 28, 2018 at 2:10 AM, Ulf Samuelsson wrote:
>> Checked out poky
>> git checkout -b rocko origin/rocko
>> export MACHINE=beaglebone
>> . ./oe-init-build-env
>>
>> Added to local.conf:
>> MKLIBS_OPTIMIZED_IMAGES_append = " core-image-minimal"
>>
>> Result:
>>
>> /core-image-minimal/1.0-r0/temp/run.mklibs_optimize_image.13363: line
>> 133: i586-poky-linux-readelf: command not found
>> ...
>> Exception: Cannot find
>> lib/home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/lib/ld-linux.so.2
>> WARNING:
>> /home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/run.mklibs_optimize_image.13363:1
>> exit 1 from 'mklibs -v --ldlib ${dynamic_loader} --libdir lib --sysroot
>> /home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot
>> --gcc-options
>> "--sysroot=/home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot"
>> --root
>> /home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs
>> --target `echo i586-poky-linux- | sed 's/-$//' ` -d
>> /home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/mklibs/dest
>> `cat
>> /home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/mklibs/executables.list`'
>> ...
>>
>> Looks like image-mklibs.bbclass has not been tested since the move to a
>> local sysroot happened.
>
> It seems class should be adding a dependency on
> virtual/${TARGET_PREFIX}binutils-cross
> if that fixes the problem, please send the patch if not file a bug
> since there might be more to it.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Generating license/manifest for a specific layer?
I have been working on a release-notes bbclass which will for each recipe included in am image extract stuff like package name, license info, cve info, SUMMARY, DESCRIPTION etc. and generate LaTex files. repo diffmanifests is used to extract the difference between a previous manifest and the current manifest. Each patch committed has a JIRA ticket number, and a LaTex file is generated with a symbolic link to our JIRA server. Everything is collected by a separate project, and once the LaTex files are complete, I only have to do make -release-notes.pdf. Once it is merged locally, I am considering upstreaming. Best Regards, Ulf Samuelsson > 11 juni 2018 kl. 15:46 skrev Michael Habibi : > > Our use case is to capture the license files, manifest (package/version), and > download information only for packages we modify/add. We use our own layer to > modify/add packages, everything coming from standard Yocto layers are > untouched. > > Is there a way to generate this information on a layer-by-layer basis, > instead of a full manifest that includes all standard, unmodified packages? > -- > ___ > 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] How handle files needing updates in read-only filesystem
We have a rootfs which is read-only.
For files that needs to be updated, like "/etc/localtime"
we will create a symbolic link to a partition (/persistent) which
is retained between rootfs image updates.
/etc/localtime -> /persistent/etc/localtime
The original recipe will generate the real /etc/localtime of course.
To support the file beeing updated, the following needs to be done in a
rootfs postprocess.
mv /etc/localtime /update/etc/localtime
ln -sf /persistent/etc/localtime /etc/localtime
install -m 0644 /update/etc/localtime /persistent/etc/localtime
chown : /persistent/etc/localtime
The last two commands needs to be executed on the running system,
since /persistent is not part of the rootfs.
To ensure that the file can be updated is an ad-hoc activity for each
affected file. It would be better if there was a class where you declare
a file to be writeable, and then a post process
would move the file to /update (or similar) and create a symbolic link
SETTINGS ?= "/persistent"
=
inherit writeable
WRITEABLE = "/etc/localtime"
=
This would generate the first two commands for each listed file.
mv /etc/localtime /update/etc/localtime
ln -sf ${SETTINGS}/etc/localtime /etc/localtime
The file would also be added to a file indicating that it may need
to be copied to the ${SETTINGS}
Is it a good solution to modify "populate_volatiles.sh"
to support a second file parameter for the f (file) command
in the /etc/default/volatiles file?
Today the file create command looks like:
f
An idea would be to have the following syntax:
f
If is a valid filepath, then copy this file to
If is not a valid filepath, create using "touch"
This would break any build which has a "funny" volatiles file.
Otherwise a script called populate_persistent.sh could be
created with such an extension.
Comments?
BR
Ulf Samuelsson
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Image specific configuration files
Here is the idea developed at Atlas Copco.
Not my code, but I thought it useful for this problem
define three bbclasses.
production.bbclass, rnd.bbclass, release.bbclass containing:
==
# Class for use in BBCLASSEXTEND to make it easier to have a single recipe that
# build and generate packages separately for release and normal images.
#
# Usage:
# BBCLASSEXTEND = "release"
CLASSOVERRIDE .= ":class-release"
python release_virtclass_handler () {
# Do nothing if this is inherited, as it's for BBCLASSEXTEND
if "release" not in (d.getVar('BBCLASSEXTEND') or ""):
bb.error("Don't inherit release, use BBCLASSEXTEND")
return
# Restore BPN
bpn = d.getVar('BPN')
newbpn = bpn.replace('-release', '')
d.setVar('BPN', newbpn)
# Use default FILESPATH searching for patches and files
filespath = d.getVar('FILESPATH', True)
newfilespath = filespath.replace('-release', '')
d.setVar('FILESPATH', newfilespath)
}
addhandler release_virtclass_handler
release_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
==
In a bbappend you use the classes:
==
SRC_URI_append_class-production = " \
file://rcS.production \
"
SRC_URI_append_class-rnd = " \
file://rcS.rnd \
"
SRC_URI_append_class-release = " \
file://rcS.release \
"
do_install_append_class-production () {
install -m 755 ${WORKDIR}/rcS.production ${D}${sysconfdir}/init.d/rcS
}
do_install_append_class-rnd () {
install -m 755 ${WORKDIR}/rcS.rnd ${D}${sysconfdir}/init.d/rcS
}
do_install_append_class-release () {
install -m 755 ${WORKDIR}/rcS.release ${D}${sysconfdir}/init.d/rcS
}
BBCLASSEXTEND = "production rnd release"
==
In your production image you add
IMAGE_INSTALL_append = "busybox-production"
Do something similar for the other two.
BR
Ulf Samuelsson
Från: yocto-boun...@yoctoproject.org för
Damien LEFEVRE
Skickat: den 1 juni 2018 13:17:53
Till: Iván Castell
Kopia: Yocto discussion list
Ämne: Re: [yocto] Image specific configuration files
Thanks a lot everyone, this is very helpful =)
On Fri, Jun 1, 2018 at 2:14 PM, Iván Castell
mailto:icast...@nayarsystems.com>> wrote:
2018-06-01 11:24 GMT+02:00 Alexander Kanavin
mailto:alex.kana...@gmail.com>>:
I have to say defining multiple distros and then tweaking recipes according to
those definitions is not a good practice, as recipes should generally only
access DISTRO_FEATURES and otherwise be distro-agnostic. The above iptables
scenario should be handled with different image recipes, which pull in (via
packages) or create different configurations.
That has sense. We will refactorize our Yocto repo as suggested. Always very
helpfull with all your comments Mr Alexander. Thank you very much! :)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Fwd: image-mklibs.bbclass fails
Checked out poky
git checkout -b rocko origin/rocko
export MACHINE=beaglebone
. ./oe-init-build-env
Added to local.conf:
MKLIBS_OPTIMIZED_IMAGES_append = " core-image-minimal"
Result:
/core-image-minimal/1.0-r0/temp/run.mklibs_optimize_image.13363: line 133: i586-poky-linux-readelf: command not found
...
Exception: Cannot find lib/home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/lib/ld-linux.so.2
WARNING: /home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/run.mklibs_optimize_image.13363:1 exit 1 from 'mklibs -v --ldlib ${dynamic_loader} --libdir lib --sysroot /home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot
--gcc-options "--sysroot=/home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot" --root /home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs --target `echo i586-poky-linux-
| sed 's/-$//' ` -d /home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/mklibs/dest `cat /home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/mklibs/executables.list`'
...
Looks like image-mklibs.bbclass has not been tested since the move to a local sysroot happened.
BR
Ulf Samuelsson
Parsing recipes: 100% |#| Time: 0:00:25
Parsing of 820 .bb files complete (0 cached, 820 parsed). 1279 targets, 44 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "1.36.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING = "ubuntu-16.04"
TARGET_SYS = "i586-poky-linux"
MACHINE = "qemux86"
DISTRO = "poky"
DISTRO_VERSION = "2.4.3"
TUNE_FEATURES= "m32 i586"
TARGET_FPU = ""
meta
meta-poky
meta-yocto-bsp = "rocko:7e7ee662f5dea4d090293045f7498093322802cc"
NOTE: Fetching uninative binary shim from http://downloads.yoctoproject.org/releases/uninative/1.9/x86_64-nativesdk-libc.tar.bz2;sha256sum=c26622a1f27dbf5b25de986b11584b5c5b2f322d9eb367f705a744f58a5561ec
Initialising tasks: 100% |##| Time: 0:00:03
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: cryptodev-linux-native-1.9-r0 do_fetch: Checksum mismatch for local file /home/ulf/projects/poky-bb/poky/build/downloads/cryptodev-linux-1.9.tar.gz
Cleaning and trying again.
WARNING: cryptodev-linux-native-1.9-r0 do_fetch: Renaming /home/ulf/projects/poky-bb/poky/build/downloads/cryptodev-linux-1.9.tar.gz to /home/ulf/projects/poky-bb/poky/build/downloads/cryptodev-linux-1.9.tar.gz_bad-checksum_5ed12cda871532668dd7edcb843645e0
WARNING: cryptodev-linux-native-1.9-r0 do_fetch: Checksum failure encountered with download of http://nwl.cc/pub/cryptodev-linux/cryptodev-linux-1.9.tar.gz - will attempt other sources if available
WARNING: popt-native-1.16-r3 do_fetch: Failed to fetch URL http://rpm5.org/files/popt/popt-1.16.tar.gz, attempting MIRRORS if available
Currently 7 running tasks (298 of 2470) 12% | |
Currently 8 running tasks (298 of 2470) 12% | |
WARNING: shadow-4.2.1-r0 do_fetch: Failed to fetch URL http://pkg-shadow.alioth.debian.org/releases/shadow-4.2.1.tar.xz, attempting MIRRORS if available
WARNING: libpng-native-1.6.31-r0 do_fetch: Failed to fetch URL http://downloads.sourceforge.net/project/libpng/libpng16/1.6.31/libpng-1.6.31.tar.xz, attempting MIRRORS if available
WARNING: libffi-native-3.2.1-r0 do_fetch: Failed to fetch URL ftp://sourceware.org/pub/libffi/libffi-3.2.1.tar.gz, attempting MIRRORS if available
WARNING: alsa-lib-native-1.1.4.1-r0 do_fetch: Failed to fetch URL ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.1.4.1.tar.bz2, attempting MIRRORS if available
WARNING: coreutils-8.27-r0 do_fetch: Failed to fetch URL http://distfiles.gentoo.org/distfiles/coreutils-8.27-man.tar.xz;name=manpages, attempting MIRRORS if available
ERROR: core-image-minimal-1.0-r0 do_image: Function failed: mklibs_optimize_image (log file is located at /home/ulf/projects/poky-bb/poky/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_image.13363)
ERROR: Logfile of failure stored in: /hom
[yocto] How to add a module to python-native
Need some advice on how to extend python-native with a python-2.7 module. I am planning to upload the result of cve-check to our JIRA server. I wrote a python application which reads the CVE manifest, downloads the contents of a JIRA project and if a CVE issue is not present in the database, it will create new issues. The python application is using the python-restkit module, which has all the functionality I need, so I can call
[yocto] [PATCH] hostname.sh: remove warning for bashism
The use of the environment variable HOSTNAME, triggers the checkbashisms script, so change HOSTNAME to LOCALHOST Signed-off-by: Ulf Samuelsson <u...@emagii.com> --- meta/recipes-core/initscripts/initscripts-1.0/hostname.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-core/initscripts/initscripts-1.0/hostname.sh b/meta/recipes-core/initscripts/initscripts-1.0/hostname.sh index 95287cc..f4ba2b8 100755 --- a/meta/recipes-core/initscripts/initscripts-1.0/hostname.sh +++ b/meta/recipes-core/initscripts/initscripts-1.0/hostname.sh @@ -7,7 +7,7 @@ # Default-Stop: # Short-Description: Set hostname based on /etc/hostname ### END INIT INFO -HOSTNAME=$(/bin/hostname) +LOCALHOST=$(/bin/hostname) hostname -b -F /etc/hostname 2> /dev/null if [ $? -eq 0 ]; then @@ -17,6 +17,6 @@ fi # Busybox hostname doesn't support -b so we need implement it on our own if [ -f /etc/hostname ];then hostname `cat /etc/hostname` -elif [ -z "$HOSTNAME" -o "$HOSTNAME" = "(none)" -o ! -z "`echo $HOSTNAME | sed -n '/^[0-9]*\.[0-9].*/p'`" ] ; then +elif [ -z "$LOCALHOST" -o "$LOCALHOST" = "(none)" -o ! -z "`echo $LOCALHOST | sed -n '/^[0-9]*\.[0-9].*/p'`" ] ; then hostname localhost fi -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] hostname.sh: remove warning for bashism
The use of the environment variable HOSTNAME, triggers the checkbashisms script, so change HOSTNAME to LOCALHOST Signed-off-by: Ulf Samuelsson <u...@emagii.com> --- meta/recipes-core/initscripts/initscripts-1.0/hostname.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-core/initscripts/initscripts-1.0/hostname.sh b/meta/recipes-core/initscripts/initscripts-1.0/hostname.sh index 95287cc..f4ba2b8 100755 --- a/meta/recipes-core/initscripts/initscripts-1.0/hostname.sh +++ b/meta/recipes-core/initscripts/initscripts-1.0/hostname.sh @@ -7,7 +7,7 @@ # Default-Stop: # Short-Description: Set hostname based on /etc/hostname ### END INIT INFO -HOSTNAME=$(/bin/hostname) +LOCALHOST=$(/bin/hostname) hostname -b -F /etc/hostname 2> /dev/null if [ $? -eq 0 ]; then @@ -17,6 +17,6 @@ fi # Busybox hostname doesn't support -b so we need implement it on our own if [ -f /etc/hostname ];then hostname `cat /etc/hostname` -elif [ -z "$HOSTNAME" -o "$HOSTNAME" = "(none)" -o ! -z "`echo $HOSTNAME | sed -n '/^[0-9]*\.[0-9].*/p'`" ] ; then +elif [ -z "$LOCALHOST" -o "$LOCALHOST" = "(none)" -o ! -z "`echo $LOCALHOST | sed -n '/^[0-9]*\.[0-9].*/p'`" ] ; then hostname localhost fi -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] busybox->coreutils: How replace single Busybox program with same from coreutils
On 2017-11-11 07:59, Ulf Samuelsson wrote:
Adding a third party package to the rootfs, and some of their scripts
will break due to the busybox version of certain applications
do not support all the switches.
Rather that rewriting those scripts (forcing me to maintain them)
I would like to replace the busybox version of selected applications
with the coreutils version.
I would like to avoid adding other coreutils applications to the rootfs,
since their is a requirement for a small rootfs.
The core functionality is to be in a cramfs, so deleting files
postinstall is not working.
One application is "od" or octal dump.
My first try was a bbappend with
ALTERNATIVE_PRIORITY[od] = "100"
Since the busybox version has priority "50", the coreutils version
should be choosen, but the rootfs still choose the busybox version.
I then added "coreutils" to my image.
This, I expected would add all the applications in the coreutils
package so I set
ALTERNATIVE_PRIORITY[] = "5"
for all applications supported by busybox,
and
ALTERNATIVE_PRIORITY[] = "0"
for all applications not supported by busybox (and not needed by me)
in the (vain) hope that this would result in the application not beeing
included in the rootfs.
The result was that the rootfs now included the coreutils
version of the desired application.
Unfortunately this also resulted in all applications with priority "0"
being included in the rootfs as well.
Have not tried with any other value but a quick inspection of the python
code led me to believe that there is no value which will make
===
SUGGESTION:
I think it would be a good addition to the class, if you could specify a
priority which excluded the application from the rootfs.
"0", "-1" or "No" would be good values
===
Other alternatives I am thinking of is to add to the
coreutils_%.bbappend file.
FILES_${PN}- = " ${bindir}/"
or maybe
FILES_${PN}- = " ${bindir}/.coreutils"
Have not tested this yet, but this I guess may result in the application
beeing present in two packages.
Is the following valid?
FILES_${PN} = " ${bindir}"
FILES_${PN}-od = " ${bindir}/od.${BPN}"
Will it create two packages, each with their own "od", or will
the second statement override the first so that "od" is only
present in the coreutils-od package?
===
I could always create a do_install_append and install the applications
as something else
do_install_append () {
install -m 0755 /od ${D}/usr/local/bin/od
}
FILES_${PN}-od = " /usr/local/bin/od"
===
Fully replacing the do_install is yet another alternative.
Since the coreutils
===
Checking the meta/recipes-core/coreutils/coreutils_8.27.bb
it might be as easy as replacing the bindir_progs variable
only listing those applications I want.
bindir_progs = "od install mktemp"
ALTERNATIVE_${PN} = "od install mktemp"
===
Any other ideas?
This "bbappend" appears to give the right result in "coreutils",
but I am interested to know if there is a better method.
ALTERNATIVE_PRIORITY[od]= "100"
ALTERNATIVE_PRIORITY[install] = "100"
ALTERNATIVE_PRIORITY[mktemp]= "100"
# For all other busybox applications
ALTERNATIVE_PRIORITY[] = "5"
# For all other applications
ALTERNATIVE_PRIORITY[] = "0"
bindir_progs= " od install"
bindir_noprogs = " \
arch expand runcon test \
b2sum expr nice seq timeout \
base32 factor nl sha1sum tr \
base64.coreutils fmt nohup sha224sum truncate \
basename fold nproc sha256sum tsort \
chcon groups numfmt sha384sum tty \
cksum head sha512sum unexpand \
comm hostid paste shred uniq \
csplit id pathchk shuf unlink \
cut pinky sort uptime \
df.coreutils join pr split users \
dir lbracket.coreutils printenv stdbuf vdir \
dircolors link printf sum wc \
dirname logname ptx tac who \
du md5sum readlink tail whoami \
env mkfifo realpath tee yes \
"
do_install_append() {
for f in ${bindir_noprogs} ; do
rm -f ${D}${bindir}/$f
done
}
ALTERNATIVE_${PN} = " ${bindir_progs} mktemp "
Is overriding busybox with the "real" application documented somewhere?
If not, maybe it should be.
Overriding coreutils with busybox is easily found when googling.
Best Regards
Ulf Samuelsson
Best Regards
Ulf Samuelsson
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] busybox->coreutils: How replace single Busybox program with same from coreutils
Adding a third party package to the rootfs, and some of their scripts
will break due to the busybox version of certain applications
do not support all the switches.
Rather that rewriting those scripts (forcing me to maintain them)
I would like to replace the busybox version of selected applications
with the coreutils version.
I would like to avoid adding other coreutils applications to the rootfs,
since their is a requirement for a small rootfs.
The core functionality is to be in a cramfs, so deleting files
postinstall is not working.
One application is "od" or octal dump.
My first try was a bbappend with
ALTERNATIVE_PRIORITY[od]= "100"
Since the busybox version has priority "50", the coreutils version
should be choosen, but the rootfs still choose the busybox version.
I then added "coreutils" to my image.
This, I expected would add all the applications in the coreutils
package so I set
ALTERNATIVE_PRIORITY[] = "5"
for all applications supported by busybox,
and
ALTERNATIVE_PRIORITY[] = "0"
for all applications not supported by busybox (and not needed by me)
in the (vain) hope that this would result in the application not beeing
included in the rootfs.
The result was that the rootfs now included the coreutils
version of the desired application.
Unfortunately this also resulted in all applications with priority "0"
being included in the rootfs as well.
Have not tried with any other value but a quick inspection of the python
code led me to believe that there is no value which will make
===
SUGGESTION:
I think it would be a good addition to the class, if you could specify a
priority which excluded the application from the rootfs.
"0", "-1" or "No" would be good values
===
Other alternatives I am thinking of is to add to the
coreutils_%.bbappend file.
FILES_${PN}- = " ${bindir}/"
or maybe
FILES_${PN}- = " ${bindir}/.coreutils"
Have not tested this yet, but this I guess may result in the application
beeing present in two packages.
Is the following valid?
FILES_${PN} = " ${bindir}"
FILES_${PN}-od = " ${bindir}/od.${BPN}"
Will it create two packages, each with their own "od", or will
the second statement override the first so that "od" is only
present in the coreutils-od package?
===
I could always create a do_install_append and install the applications
as something else
do_install_append () {
install -m 0755 /od${D}/usr/local/bin/od
}
FILES_${PN}-od = " /usr/local/bin/od"
===
Fully replacing the do_install is yet another alternative.
Since the coreutils
===
Checking the meta/recipes-core/coreutils/coreutils_8.27.bb
it might be as easy as replacing the bindir_progs variable
only listing those applications I want.
bindir_progs = "od install mktemp"
ALTERNATIVE_${PN} = "od install mktemp"
===
Any other ideas?
Is overriding busybox with the "real" application documented somewhere?
If not, maybe it should be.
Overriding coreutils with busybox is easily found when googling.
Best Regards
Ulf Samuelsson
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] poky using native pkg_resources module
Den 2017-09-30 kl. 21:32, skrev Alejandro Hernandez: Hey Ulf, Yes, the problem is that the bmap-tools script is trying to be executed by python3 (HOST) but it should be executed by the native python3 we just built, so fixing the shebang on the script should do it, please file the bug and email me the bug number so I can take care of it. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12148 BR Ulf Alejandro | aehs29 On 09/30/2017 01:31 PM, Ulf Samuelsson wrote: Den 2017-09-29 kl. 20:18, skrev Alejandro Hernandez: Hey Ulf, On 09/29/2017 04:05 AM, Ulf Samuelsson wrote: It looks like the pkg_resource module is using the native installation I cloned poky early september, and could complete a build. When I clone poky today, the build fails. As part of "do_image_wic" from image_types_wic.bbclass A python program in 'bmap-tools-native' is executing "from pkg_resources import load_entry_point" grep'ing for pkg_resources in bmap-tools-native reveals: bmaptool: from pkg_resources import load_entry_point easy3_install: from pkg_resources import load_entry_point easy_install-3.5: from pkg_resources import load_entry_point = pkg_resources.py is not available inside poky at the moment. It is (or used to be) part of python-setuptools. Correct, it was and still is part of setuptools On Ubuntu, it is present in: "http://archive.ubuntu.com/ubuntu/pool/main/p/python-setuptools/python-setuptools_3.3.orig.tar.gz; and used in Ubuntu 14.04 and 16.04 to generate the "python3-pkg-resource" package. When python-setuptools is generated by Yocto, it is partly a class, but the python-setuptools-native recipe downloads "https://files.pythonhosted.org/packages/source/s/setuptools/setuptools-26.2.7.zip; This should be setuptools-36.2.7 btw which does not contain "pkg_resources.py" Its not partly a class, it uses a class to install the package along with distutils. = When bmaptool imports pkg_resources, it will not find anything in the yocto build, but will find the native "/usr/lib/python3/dist-packages/pkg_resources.py" from This requires bmap-tools == 3.4, but the native bmap-tools in Ubuntu-14.04 is 2.5, and in Ubuntu-16.04 it is 3.2 so the build fails. Maybe Ubuntu-17.04 supports bmap-tools 3.4 and it will build there, but using the native pkg_resource is of course not a good idea? There is something wrong with your build although I am not sure what it is, pkg_resources is still part of python(3)-setuptools, in fact you can check that in several ways if you do a devshell on python3-setuptools-native you can see the extracted package contains the pkg_resources folder (so it is still part of the package) > I do: "bitbake -c devshell python3-setuptools-native" A terminal windows opens in "tmp/work/x86_64-linux/python3-setuptools-native/36.2.7-r0/setuptools-36.2.7" ls bootstrap.py easy_install.py PKG-INFO setuptools build launcher.c pkg_resources setuptools.egg-info CHANGES.rst LICENSE pytest.ini tests conftest.py MANIFEST.in README.rst tox.ini dist msvc-build-launcher.cmd setup.cfg docs pavement.py setup.py so the "pkg_resources" folder is present. cd pkg_resources ; ls -l -rw-r--r-- 1 ulf ulf 12211 Aug 2 00:40 api_tests.txt drwxrwxr-x 3 ulf ulf 4096 Sep 30 17:35 extern -rw-r--r-- 1 ulf ulf 104650 Aug 2 00:40 __init__.py -rw-r--r-- 1 ulf ulf 600 Aug 2 00:40 py31compat.py drwxrwxr-x 2 ulf ulf 4096 Sep 30 17:35 __pycache__ drwxrwxr-x 2 ulf ulf 4096 Sep 30 17:35 tests drwxrwxr-x 4 ulf ulf 4096 Sep 30 17:35 _vendor so there is NO "pkg_resource.py" file inside. The statement that fails is "from pkg_resources import load_entry_point" "load_entry_point" is defined in pkg_resources/__init__.py Somewhere, something decides that "/usr/lib/python3/dist-packages/pkg_resources.py" is what we want. I have a fresh install of Ubuntu-16.04. This has received the latest package updates. I have also installed a set of packages I usually install on a machine. Not much more. environment lack anything python related. In one test, I git cloned a fresh copy of "poky". No layers added.' Insignificant changes to "local.conf", only changed some directory location Building the beaglebone, and problem occurs. If I build from poky "8b4f16a9cbbaf521461f699b7264fac2ac872581" from Mon Sep 4 11:39:24, I have no problem. Best Regards Ulf Samuelsson then if you do a devshell after do_install, you can check the image directory and find the setuptools.egg file, which is what python-native uses later, if you unzip that egg file, you can see that pkg_resources is there, so it was in fact packaged on Yocto
Re: [yocto] poky using native pkg_resources module
Den 2017-09-29 kl. 20:18, skrev Alejandro Hernandez: Hey Ulf, On 09/29/2017 04:05 AM, Ulf Samuelsson wrote: It looks like the pkg_resource module is using the native installation I cloned poky early september, and could complete a build. When I clone poky today, the build fails. As part of "do_image_wic" from image_types_wic.bbclass A python program in 'bmap-tools-native' is executing "from pkg_resources import load_entry_point" grep'ing for pkg_resources in bmap-tools-native reveals: bmaptool: from pkg_resources import load_entry_point easy3_install: from pkg_resources import load_entry_point easy_install-3.5: from pkg_resources import load_entry_point = pkg_resources.py is not available inside poky at the moment. It is (or used to be) part of python-setuptools. Correct, it was and still is part of setuptools On Ubuntu, it is present in: "http://archive.ubuntu.com/ubuntu/pool/main/p/python-setuptools/python-setuptools_3.3.orig.tar.gz; and used in Ubuntu 14.04 and 16.04 to generate the "python3-pkg-resource" package. When python-setuptools is generated by Yocto, it is partly a class, but the python-setuptools-native recipe downloads "https://files.pythonhosted.org/packages/source/s/setuptools/setuptools-26.2.7.zip; This should be setuptools-36.2.7 btw which does not contain "pkg_resources.py" Its not partly a class, it uses a class to install the package along with distutils. = When bmaptool imports pkg_resources, it will not find anything in the yocto build, but will find the native "/usr/lib/python3/dist-packages/pkg_resources.py" from This requires bmap-tools == 3.4, but the native bmap-tools in Ubuntu-14.04 is 2.5, and in Ubuntu-16.04 it is 3.2 so the build fails. Maybe Ubuntu-17.04 supports bmap-tools 3.4 and it will build there, but using the native pkg_resource is of course not a good idea? There is something wrong with your build although I am not sure what it is, pkg_resources is still part of python(3)-setuptools, in fact you can check that in several ways if you do a devshell on python3-setuptools-native you can see the extracted package contains the pkg_resources folder (so it is still part of the package) > I do: "bitbake -c devshell python3-setuptools-native" A terminal windows opens in "tmp/work/x86_64-linux/python3-setuptools-native/36.2.7-r0/setuptools-36.2.7" ls bootstrap.py easy_install.py PKG-INFO setuptools build launcher.c pkg_resources setuptools.egg-info CHANGES.rst LICENSE pytest.ini tests conftest.py MANIFEST.in README.rst tox.ini dist msvc-build-launcher.cmd setup.cfg docs pavement.py setup.py so the "pkg_resources" folder is present. cd pkg_resources ; ls -l -rw-r--r-- 1 ulf ulf 12211 Aug 2 00:40 api_tests.txt drwxrwxr-x 3 ulf ulf 4096 Sep 30 17:35 extern -rw-r--r-- 1 ulf ulf 104650 Aug 2 00:40 __init__.py -rw-r--r-- 1 ulf ulf600 Aug 2 00:40 py31compat.py drwxrwxr-x 2 ulf ulf 4096 Sep 30 17:35 __pycache__ drwxrwxr-x 2 ulf ulf 4096 Sep 30 17:35 tests drwxrwxr-x 4 ulf ulf 4096 Sep 30 17:35 _vendor so there is NO "pkg_resource.py" file inside. The statement that fails is "from pkg_resources import load_entry_point" "load_entry_point" is defined in pkg_resources/__init__.py Somewhere, something decides that "/usr/lib/python3/dist-packages/pkg_resources.py" is what we want. I have a fresh install of Ubuntu-16.04. This has received the latest package updates. I have also installed a set of packages I usually install on a machine. Not much more. environment lack anything python related. In one test, I git cloned a fresh copy of "poky". No layers added.' Insignificant changes to "local.conf", only changed some directory location Building the beaglebone, and problem occurs. If I build from poky "8b4f16a9cbbaf521461f699b7264fac2ac872581" from Mon Sep 4 11:39:24, I have no problem. Best Regards Ulf Samuelsson then if you do a devshell after do_install, you can check the image directory and find the setuptools.egg file, which is what python-native uses later, if you unzip that egg file, you can see that pkg_resources is there, so it was in fact packaged on Yocto / by bitbake. Lastly, you can also do a $ bitbake bmap-tools-native -c devshell you can then check that python3-native is in fact executing by doing a $ which python3 that should point to python3-native (the one you just built) assuming you got python3-native correctly, execute python3 once in python you can do a from pkg_resources import load_entry_point # which would import the module # check where the module is being loaded from import sys sys.modules['pkg_resources'] That
[yocto] RFC: autotooler: generation of "configure.ac" and "Makefile.am" using Kconfig
Have a need to convert a large number of libraries to use autotools.
I came up with the following idea:
I create an Kconfig based configuration system, where you define a
number of configuration items needed by configure.ac and Makefile.am
You choose if you want to build an application, a shared library or a
static library.
The build normally depends on other libraries, and you checkmarks
which library you are interested in from a (small) number of supported
libraries.
You can likewise select to support options like "--enable-openssl",
again from a (small) number of supported options.
If you have stuff not supported, the autotooler will include Config.in
files allowing you to add your own items.
Once the configuration is complete, you will compile an application
which will generate "configure.ac" from the configuration file.
Again, if you have stuff not supported in the code, you can add it
in a user include file.
The generator will read a user-headers.inc file and
generate an AC_CHECK_HEADERS entry.
The autotooler is available on
https://www.github.com/emagii/autotooler.git
===
Currently, it does not generate any Makefile.am files, but
the idea is to separate the source files into
* C source
* Public Headers
* Local Headers
A tool would then scan the directories and classify them accordingly,
so Makefile.am files should be possible to generate fairly easy.
===
A final step would clone a empty git tree, and populate it
with all the files needed for a complete package.
===
Comments appreciated.
Best Regards
Ulf Samuelsson
===
Here is a typical "autoconh.h" generated by Kconfig.
/*
* Automatically generated C config: don't edit
* Sat Sep 30 16:27:24 2017
*/
#define CONFIG_SHARED_LIB 1
#define CONFIG_PTHREAD 1
#define CONFIG_LIBRARY 1
#define CONFIG_PROJECT "myproject"
#define CONFIG_WORKDIR "${HOME}/projects/autotooler"
#define CONFIG_OPENSSL 1
#define CONFIG_CURL 1
#define CONFIG_COPYRIGHT_DATE "2017"
#define CONFIG_HOMEPAGE "http://www.emagii.com/;
#define CONFIG_EXAMPLES 1
#define CONFIG_DEBUG 1
#define HAVE_DOT_CONFIG 1
#define CONFIG_AC_PRERQ "2.59"
#define CONFIG_BOOST 1
#define CONFIG_OS_LINUX 1
#define CONFIG_LIBRARY_NAME "libyocto"
#define CONFIG_AUTHOR_EMAIL "u...@emagii.com"
#define CONFIG_LIBRARY_VERSION "1.0"
#define CONFIG_AC_CONFIG_HEADER "src/include/config.h"
#define CONFIG_OS "Linux"
#define CONFIG_EXAMPLES_VAR "examples"
#define CONFIG_AC_CONFIG_MACRO_DIR "m4"
#define CONFIG_DEBUG_VAR "debug"
#define CONFIG_PROJECT_TYPE "library"
#define CONFIG_SRCDIR "src"
#define CONFIG_SRC_URI_REPO ""
#define CONFIG_AUTHOR "Ulf Samuelsson"
#define CONFIG_SRC_URI_HOST "https://www.github.com/emagii;
#define CONFIG_CURLPP 1
#define CONFIG_AM_INIT_AUTOMAKE "1.10 -Wall no-define"
The application will from this information generate:
AC_INIT([libyocto],
[1.0],
[Ulf Samuelsson],
[libyocto-1.0],
[http://www.emagii.com/])
AC_PRERQ([2.59])
AC_CONFIG_HEADER([src/include/config.h])
AC_CONFIG_SRCDIR([src])
AC_PROG_CPP
AC_PROG_CC
AC_INIT_AUTOMAKE([1.10 -Wall no-define])
AC_PROG_MAKE_SET
AM_MAINTAINER_MODE
AC_HEADER_STDC
AC_ENABLE_SHARED
AC_DISABLE_STATIC
AC_PROG_LIBTOOL
AC_HEADER_STDC
AC_CHECK_HEADERS( \
ctype.h \
errno.h \
fcntl.h \
openssl/bio.h \
openssl/err.h \
openssl/opensslconf.h \
openssl/rand.h \
openssl/ssl.h \
pthread.h \
stdio.h \
stdlib.h \
stdarg.h \
stdint.h \
string.h \
signal.h \
sys/ioctl.h \
sys/socket.h \
sys/time.h \
sys/types.h \
time.h \
unistd.h \
\
,
dnl to do if not found
[],
dnl to do if not found
[],
dnl default includes
[
#ifdef HAVE_SYS_TYPES_H
#include
#endif
#ifdef HAVE_SYS_TIME_H
#include
#endif
dnl We do this default-include simply to make sure that the nameser_compat.h
dnl header *REALLY* can be include after the new nameser.h. It seems AIX 5.1
dnl (and others?) is not designed to allow this.
#ifdef HAVE_ARPA_NAMESER_H
#include
#endif
dnl *Sigh* these are needed in order for net/if.h to get properly detected.
#ifdef HAVE_SYS_SOCKET_H
#include
#endif
#ifdef HAVE_NETINET_IN_H
#include
#endif
]
)
# Boost Libraries
AC_ARG_WITH([boost-include-path],
[AS_HELP_STRING([--with-boost-include-path],[location of the Boost
headers, defaults to /usr/include/boost])],
[CXXFLAGS_BOOST="-I$withval"],
[CXXFLAGS_BOOST=&q
[yocto] poky using native pkg_resources module
uild/tmp/work/beaglebone-poky-linux-gnueabi/emagii-image/1.0-r0/temp/log.do_image_wic.19342) ERROR: Task (/home/ulf/Kunder/eMagii/Disk/yocto-arm/poky-arm/build/../meta-emagii/recipes-images/images/emagii-image.bb:do_image_wic) failed with exit code '1' NOTE: Tasks Summary: Attempted 3187 tasks of which 3186 didn't need to be rerun and 1 failed. Summary: 1 task failed: /home/ulf/Kunder/eMagii/Disk/yocto-arm/poky-arm/build/../meta-emagii/recipes-images/images/emagii-image.bb:do_image_wic Summary: There was 1 WARNING message shown. Summary: There was 1 ERROR message shown, returning a non-zero exit code. Best Regards Ulf Samuelsson -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
