Re: [yocto] Yocto layers missing thud branches
hi, while we are there.. in our builds we use the following layers which also need the 'thud' branches: name="OSSystems/meta-browser" path="layers/meta-browser" name="git/meta-ti" path="layers/meta-ti" remote="yocto" name="kraj/meta-clang" path="layers/meta-clang" name="meta-rust/meta-rust" path="layers/meta-rust" thanks! nico On Sun, Nov 18, 2018 at 12:50 AM akuster808 wrote: > Can the maintainers of meta-qt3, meta-qt4, meta-selinux, and meta-cgl > please add a "Thud" branch > > kind regards, > Armin > -- > ___ > 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] Yocto layers missing thud branches
Can the maintainers of meta-qt3, meta-qt4, meta-selinux, and meta-cgl please add a "Thud" branch kind regards, Armin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocto-autobuilder2][PATCH] schedulers: fix typo in thud entry.
There are two sumo entires.
Signed-off-by: Armin Kuster
---
schedulers.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/schedulers.py b/schedulers.py
index 1f32970..4c28e12 100644
--- a/schedulers.py
+++ b/schedulers.py
@@ -142,7 +142,7 @@ schedulers.append(sched.ForceScheduler(
'branch_meta-qt4': 'master',
'branch_oecore': 'master',
},
- 'sumo': {
+ 'thud': {
'branch': 'thud',
'branch_poky': 'thud',
'branch_bitbake': '1.40',
--
2.7.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] supplier workflow
On Sat, Nov 17, 2018 at 12:35 AM Robert Berger wrote: > > Hi, > > I came across a scenario, which does not seem too strange, but I am not > sure how this can be handled with OE/YP. (just nasty hacks with SSTATE) > > 1) Company A provides an SDK to to Company B - no source code provided > 2) Company B provides a "binary" back to Company A - no source code povided > 3) Company A integrates this "binary" back into some project and > bitbakes the image > > Ideally Company B does not just provide a "binary" executable/library, > but a package e.g. ipk. > > Company A could provide an extensible SDK and Company B could create a > package of their stuff with it. > > Now comes the question: "Is it possible for Company A to add a package > (no source code available) back into a project and bitbake this? > If yes, how?" > there is some help if you inherit bin_package > The advantage would be that Company B would be forced to bitbake it > (with the additional checks done by OE/YP) and not just compile > something somehow with a "classic" SDK and ship it. > > Regards, > > Robert > -- > ___ > 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] supplier workflow
You can put the ipk file location directly into SRC_URI. Bitbake will unpack it without further tricks. Then just copy the contents in do_install(). Alex On Sat, 17 Nov 2018 at 09:35, Robert Berger wrote: > > Hi, > > I came across a scenario, which does not seem too strange, but I am not > sure how this can be handled with OE/YP. (just nasty hacks with SSTATE) > > 1) Company A provides an SDK to to Company B - no source code provided > 2) Company B provides a "binary" back to Company A - no source code povided > 3) Company A integrates this "binary" back into some project and > bitbakes the image > > Ideally Company B does not just provide a "binary" executable/library, > but a package e.g. ipk. > > Company A could provide an extensible SDK and Company B could create a > package of their stuff with it. > > Now comes the question: "Is it possible for Company A to add a package > (no source code available) back into a project and bitbake this? > If yes, how?" > > The advantage would be that Company B would be forced to bitbake it > (with the additional checks done by OE/YP) and not just compile > something somehow with a "classic" SDK and ship it. > > Regards, > > Robert > -- > ___ > 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] supplier workflow
Hi, I came across a scenario, which does not seem too strange, but I am not sure how this can be handled with OE/YP. (just nasty hacks with SSTATE) 1) Company A provides an SDK to to Company B - no source code provided 2) Company B provides a "binary" back to Company A - no source code povided 3) Company A integrates this "binary" back into some project and bitbakes the image Ideally Company B does not just provide a "binary" executable/library, but a package e.g. ipk. Company A could provide an extensible SDK and Company B could create a package of their stuff with it. Now comes the question: "Is it possible for Company A to add a package (no source code available) back into a project and bitbake this? If yes, how?" The advantage would be that Company B would be forced to bitbake it (with the additional checks done by OE/YP) and not just compile something somehow with a "classic" SDK and ship it. Regards, Robert -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
