Re: [yocto] How to build the uclibc toolchain by Yocto
Thanks a lot, Paul. Best Regards, Zhenhua -Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: Wednesday, November 19, 2014 7:02 PM To: Luo Zhenhua-B19537 Cc: yocto@yoctoproject.org Subject: Re: [yocto] How to build the uclibc toolchain by Yocto Hi Zhenhua, On Wednesday 19 November 2014 09:43:59 zhenhua@freescale.com wrote: The eglibc is used for meta-toolchain build in Yocto, may I know how to build the uclibc meta-toolchain in Yocto? It should be as easy as setting TCLIBC = uclibc in your custom distro config. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-selinux][PATCH 1/2] ustr: Get source from official upstream instead of Fedora Project
Official upstream is still OK, so we use it first
Signed-off-by: Qian Lei qianl.f...@cn.fujitsu.com
---
recipes-extended/ustr/ustr_1.0.4.bb | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/recipes-extended/ustr/ustr_1.0.4.bb
b/recipes-extended/ustr/ustr_1.0.4.bb
index 6651a73..d1f3d93 100644
--- a/recipes-extended/ustr/ustr_1.0.4.bb
+++ b/recipes-extended/ustr/ustr_1.0.4.bb
@@ -11,11 +11,8 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=c79c6e2ae13418d16d7dc82df960a1e7 \
file://LICENSE_LGPL;md5=d8045f3b8f929c1cb29a1e3fd737b499 \
file://LICENSE_MIT;md5=c61e779b782608472bd87593c3c3916f
-# Official upstream seems to be offline.. replace w/ a Fedora Project mirror.
-# http://www.and.org/ustr/1.0.4/ustr-1.0.4.tar.bz2
-
SRC_URI = \
-
http://pkgs.fedoraproject.org/repo/pkgs/ustr/ustr-1.0.4.tar.bz2/93147d9f0c9765d4cd0f04f7e44bdfce/ustr-1.0.4.tar.bz2
\
+http://www.and.org/ustr/${PV}/${PN}-${PV}.tar.bz2 \
file://ustr-makefile-fix.patch;patch=1 \
file://ustr-fix__va_copy-not-defined.patch;patch=2
SRC_URI[md5sum] = 93147d9f0c9765d4cd0f04f7e44bdfce
--
1.8.3.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-selinux][PATCH 2/2] ustr: Add a new patch
This patch has been applied in fedora to fix c99 inline problems.
Upstream hasn't been updated since 2008 and those c99 problems
still exist in the last version 1.0.4.
Signed-off-by: Qian Lei qianl.f...@cn.fujitsu.com
---
recipes-extended/ustr/ustr/ustr-c99-inline.patch | 30
recipes-extended/ustr/ustr_1.0.4.bb | 3 ++-
2 files changed, 32 insertions(+), 1 deletion(-)
create mode 100644 recipes-extended/ustr/ustr/ustr-c99-inline.patch
diff --git a/recipes-extended/ustr/ustr/ustr-c99-inline.patch
b/recipes-extended/ustr/ustr/ustr-c99-inline.patch
new file mode 100644
index 000..dfa021f
--- /dev/null
+++ b/recipes-extended/ustr/ustr/ustr-c99-inline.patch
@@ -0,0 +1,30 @@
+diff -rup ustr-1.0.4-orig/ustr-compiler.h ustr-1.0.4/ustr-compiler.h
+--- ustr-1.0.4-orig/ustr-compiler.h2008-02-15 15:12:28.0 -0500
ustr-1.0.4/ustr-compiler.h 2008-06-13 15:25:18.0 -0400
+@@ -113,17 +113,23 @@
+ #endif
+
+ #ifndef USTR_CONF_EI_PROTO /* external inline */
+-# if USTR_CONF_INCLUDE_CODEONLY_HEADERS
++# if USTR_CONF_INCLUDE_CODEONLY_HEADERS || ! defined(__GNUC__) || \
++ ! USTR_CONF_COMPILE_USE_INLINE
+ # define USTR_CONF_EI_PROTO static USTR__INLINE
+ # else
+ # define USTR_CONF_EI_PROTO extern
+ # endif
+ #endif
+ #ifndef USTR_CONF_II_PROTO /* implementation of inline */
+-# if USTR_CONF_INCLUDE_CODEONLY_HEADERS
++# if USTR_CONF_INCLUDE_CODEONLY_HEADERS || ! defined(__GNUC__) || \
++ ! USTR_CONF_COMPILE_USE_INLINE
+ # define USTR_CONF_II_PROTO static USTR__INLINE
+ # else
+-# define USTR_CONF_II_PROTO extern inline
++# if defined(__GNUC_STDC_INLINE__) || defined(__GNUC_GNU_INLINE__)
++# define USTR_CONF_II_PROTO extern inline __attribute__ ((__gnu_inline__))
++# else
++# define USTR_CONF_II_PROTO extern inline
++# endif
+ # endif
+ #endif
+
diff --git a/recipes-extended/ustr/ustr_1.0.4.bb
b/recipes-extended/ustr/ustr_1.0.4.bb
index d1f3d93..485e80d 100644
--- a/recipes-extended/ustr/ustr_1.0.4.bb
+++ b/recipes-extended/ustr/ustr_1.0.4.bb
@@ -14,7 +14,8 @@ LIC_FILES_CHKSUM =
file://LICENSE;md5=c79c6e2ae13418d16d7dc82df960a1e7 \
SRC_URI = \
http://www.and.org/ustr/${PV}/${PN}-${PV}.tar.bz2 \
file://ustr-makefile-fix.patch;patch=1 \
-file://ustr-fix__va_copy-not-defined.patch;patch=2
+file://ustr-fix__va_copy-not-defined.patch;patch=2 \
+file://ustr-c99-inline.patch;patch=3
SRC_URI[md5sum] = 93147d9f0c9765d4cd0f04f7e44bdfce
SRC_URI[sha256sum] =
3daf6eae9f78de1e872c0b2b83cce35515b94d4bb8a074e48f331fd99e1fc2c4
--
1.8.3.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] FWD: FOSDEM 2015 Embedded devroom Call For Participation
Hi all, I've seen this CFP elsewhere but not on any Yocto Project related lists. I'm reposting it incase anyone has missed it. It'd be good to see some Yocto Project talks at FOSDEM 2015! Call For Participation (CFP) Embedded devroom FOSDEM 2015 Devroom date: Saturday January 31st and February 1st 2015 in Brussels, Belgium CFP deadline: Monday December 1st 2014 Final notification two weeks later, December 15th 2014 CFP Introduction -- Embedded software is transforming the world, and FOSS embedded software is leading the way. From automotive to the Internet of Things, small devices, embedded systems, industrial process control and automatons are beginning their inevitable rise to the singularity. Join in! Or be assimilated. ;) NB: This year FOSDEM plans to record all presentations, no exceptions. Please only propose a talk that you're really able and willing to share. Topics Sought -- The embedded devroom seeks topics related to automotive, mobile, autonomous, and generally small systems. Related areas are of course of interest as well and our definition of embedded is elastic. Are you controlling and launching rockets, made your own set-top box, built some heating control for your house, hacked your mobile phone or just built a small gadget using FOSS software then you might have exactly what we're looking for. This year the automotive devroom has been merged into the embedded devroom so automotive projects are for sure on topic here too. CFP Schedule And Submission Details Please submit proposals no later than the first of December. Please use the following URL to submit your talk to FOSDEM 2015: https://penta.fosdem.org/submission/FOSDEM15 and follow the following rules: * Select as the Track embedded devroom. * Include a title. (Note that Subtitle entry doesn't appear on all conference documents, so make sure Title can stand on its own without Subtitle present.) Also try to make it catchy and descriptive of what you will talk about. For example Launching rockets with an Arduino and not Programming a microcontroller for aerodynamic control * Include an Abstract of about 500 characters and a full description of any length you wish, but in both fields, please be concise, but clear and descriptive. * Indicate whether you seek a 25 or 45 minute slot. * Use the Links sub-area to your past work in the field you'd like to share. * Affirmative confirmation that you agree to CC-By-SA-4.0 or Cc-By-4.0 licensing of your talk, in the Submission Notes field. Add a statement such as this: Should my presentation be scheduled for FOSDEM 2015, I hereby agree to license all recordings, slides and any other materials presented under the Creative Commons Attribution Share-Alike 4.0 International license. Sincerely, s/YOUR_NAME/ * Also in the notes field, note your affirmative confirmation of availability to speak on Saturday 31 January or 1 February 2015 in Brussels. Also mention if you plan to do a demo and if you have special requirements. * Make sure you give a valid email so we can contact you easily in case we have more questions or want to make sure you received the confirmation. Should you have any questions we can send more information as needed. Thank you very much and we look forward to reviewing your proposals! -- Philippe and Jeremiah along with the other members of the FOSDEM embedded devroom team. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] qtbase: Add basic Qt5 building support
Hello Yen,
On Sat, Oct 25, 2014 at 10:21:47AM +0800, Yen-Chin Lee wrote:
To build raspberrypi with Qt5, we need to add extra QT_CONFIG_FLAGS to
indicate device config.
Signed-off-by: Yen-Chin Lee coldnew...@gmail.com
---
recipes-qt/qt5/qtbase_%.bbappend | 7 +++
1 file changed, 7 insertions(+)
create mode 100644 recipes-qt/qt5/qtbase_%.bbappend
diff --git a/recipes-qt/qt5/qtbase_%.bbappend
b/recipes-qt/qt5/qtbase_%.bbappend
new file mode 100644
index 000..c994cf5
--- /dev/null
+++ b/recipes-qt/qt5/qtbase_%.bbappend
@@ -0,0 +1,7 @@
+FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
+
+QT_CONFIG_FLAGS += \
+-device linux-rasp-pi-g++ \
+-device-option CROSS_COMPILE=${TARGET_PREFIX} \
+-I${STAGING_DIR_TARGET}${includedir}/interface/vcos/pthreads \
+
If we add this append we need to change the layer dependencies and probably add
this package to the test image too. But maybe we can avoid this by using a
separate layer specific directory as meta-fsl-arm does with qt5-layer.
Check https://github.com/Freescale/meta-fsl-arm and
https://github.com/Freescale/meta-fsl-arm/blob/master/conf/layer.conf
P.S.: Sorry for this very late reply but I had a very busy period lately.
Thanks for understanding.
--
Andrei Gherzan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Raspberry b+ support
Hello, On Wed, Nov 05, 2014 at 02:14:48PM +0100, Andrei Gherzan wrote: I did nothing regarding RPI b+ as i don't own a device like that. If you guys can make it work and patches are needed in order to accomplish this, please send them over mailing list and/or review gerrit. Thanks. On Fri, Oct 31, 2014 at 4:06 PM, Mike Hogg [1]mikeh...@mountdrive.com wrote: Yes you can and I have. Search the pi forum for my posts there, last time I tried a yocto build for the b+ it pulled in the old pi firmware which doesn't work on the b+. Per my notes on the pi forum thats easily fixed by copying firmware from another b+ image. On 31 October 2014 12:13:53 GMT+00:00, Natural Groove [2]natural_gro...@hotmail.fr wrote: Hi, I am interested in using oe to crossbuild stuff for raspberry pi b+, and I wondered if someone already achieved to do this? From what I read there are some specifics to deal with, can someone help me with setting this up for b+? Any issues while trying meta-rpi with b+? Anyone succeeded? Ping me if any help is needed. -- Andrei Gherzan -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH] gstreamer1.0-plugins-bad: raname bbappend to work with any version in oe-core
Hello,
On Sun, Oct 19, 2014 at 06:25:55PM +0300, Laurentiu Palcu wrote:
Signed-off-by: Laurentiu Palcu lpa...@gmail.com
---
...bappend = gstreamer1.0-plugins-bad_%.bbappend} |0
1 file changed, 0 insertions(+), 0 deletions(-)
rename recipes-multimedia/gstreamer/{gstreamer1.0-plugins-bad_1.4.0.bbappend
= gstreamer1.0-plugins-bad_%.bbappend} (100%)
diff --git
a/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.4.0.bbappend
b/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
similarity index 100%
rename from
recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.4.0.bbappend
rename to recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
--
1.7.9.5
A similar patch was merged. Thanks.
--
Andrei Gherzan
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Layer model doomed, unless we all work together
Hi, On 11/19/2014 05:19 PM, Philip Balister wrote: http://layers.openembedded.org/layerindex/branch/master/duplicates/?l=91l=123l=30l=147l=168l=148l=31l=65l=66l=32l=124l=164l=67l=149l=77l=101l=118l=33l=3l=34l=142l=169l=35l=137l=171l=139l=108l=162l=81l=82l=95l=125l=145l=146l=114l=4l=36l=68l=140l=83l=132l=5l=154l=120l=84l=6l=93l=112l=7l=37l=167l=38l=8l=98l=39l=165l=40l=105l=69l=9l=10l=110l=107l=11l=12l=13l=14l=41l=15l=99l=151l=170l=85l=42l=43l=113l=159l=16l=78l=92l=103l=157l=97l=119l=70l=152l=153l=71l=126l=115l=136l=44l=45l=163l=17l=102l=150l=46l=18l=19l=79l=2l=138l=174l=20l=21l=128l=129l=130l=131l=47l=104l=48l=135l=22l=173l=121l=23l=160l=49l=106l=24l=50l=117l=143l=87l=51l=52l=25l=133l=116l=53l=72l=122l=73l=54l=55l=172l=88l=109l=56l=57l=100l=26l=155l=90l=58l=144l=59l=60l=74l=61l=75l=158l=134l=62l=111l=27l=76l=28l=141l=1l=64 Although that url might fail, you get the idea how to use the tool better :) The url works for me;) You just mention duplicated classes and recipes here, but there are more things which should be cleaned up ;) The worst thing about Yocto/poky/OE is, that people can do and do things in many mysterious ways. Looking through various meta-layers you don't see a common coding style, which means that you either need to twist your brain to understand what others did, or write things from scratch. I guess we should first publish best practices and then try to enforce them in a first step with maybe with something like WARN_QA and ERROR_QA and/or extend oelint. What do you think? Philip Regards, Robert ...Stroustroup writes in the ARM: C programmers think that memory allocation is too important to be left to the computer, Lisp programmers think that memory allocation is too important to be left to the programmer. My public pgp key is available,at: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x90320BF1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fw: progressbar
2014-11-20 13:47 GMT+01:00 Mahdi Sa'adat mahdisaa...@yahoo.com: No one answer my email :( Blame Yahoo: http://www.ietf.org/mail-archive/web/ietf/current/msg87153.html -- Regards Samuel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Layer model doomed, unless we all work together
On Wednesday 19 November 2014 22:34:41 Joe MacDonald wrote: [[yocto] Layer model doomed, unless we all work together] On 14.11.18 (Tue 16:28) Philip Balister wrote: I see a couple of issues we need to start talking about: 1) recipes that need to move closer to core because a range of other packages use them. This was actually the only thing I thought needed further discussion (everything else should largely be a nod-in-agreement thing), as in some cases I'm not sure it's always clear what constitutes closer to the core. Poky and oe-core layers are pretty clear, but the next step beyond that isn't. Are all layers hosted on git.yoctoproject.org inherhently more core than layers on git.openenbedded.org? And there's a number of shells when you start including all of the github projects, setting aside other open-source project hosting services. The answer to me there is certainly not. I've said this recently in other discussions, but I'll say it here anyway in case anyone else isn't sure - layers on git.yoctoproject.org should not be considered in any way more official than anywhere else solely based on them being hosted there. Anyone who wants to maintain and publish a layer suitable for others to use can get a repository on git.yoctoproject.org - there's no official review, validation, or acceptance criteria in the general case just for having a repository there (beyond being related to the project, that is). To me this isn't so much about closer to the core, it's about: 1) sensible recipe groupings, e.g. meta-networking rather than a particular project's mixed recipes layer 2) good maintenance, i.e. recipes are semi-regularly updated when upstream releases happen, fixed when needed to accommodate changes that happen in other layers it depends upon such as OE-Core, and the maintainer is reasonably responsive to patches or questions relating to the layer. We need both of those things to encourage re-use, and if we have both then it doesn't really matter where a layer is hosted as long as it's listed in the layer index. Looking at the link you sent out based on Paul's suggestion, I see I'm actually on both sides of this equation, so yay! And I'll limit the discussion to what's indexed there. Here're my examples. iscsi-initiator-utils: both in meta-networking nd meta-openstack. Both at the same version currently but wildly different contents. meta-openstack is a git.yoctoproject.org project, so does that make it closer to the core? I would think not, but as I recall there had been some comment about the openstack layer intending to limit layer dependencies outside Yocto core when it first appeared, so maybe making meta-networking a dependency is a non-starter for them. So I've talked to Bruce about meta-openstack before, with particular regard to the number of python recipes that the layer ships and future overlap with meta-python, and apparently the policy there is not to pull in other layers for some dependencies with the aim of avoiding breakage on upgrades. I don't like that very much at all, to be frank, but I can at least understand it given how huge OpenStack is. It does of course mean that the overlap with that layer in particular is only going to increase as time goes on. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Fwd: [PATCH] Perl: fix PERL5LIB settings
Hi Richard, I've seen you sent a patch for Yocto for https://bugzilla.yoctoproject.org/show_bug.cgi?id=6890 which seems to me (compared to Wolfgang's Patch) incomplete and shows another issue ^^. 1st - Wolfgang's Patch also fixes the native-perl, which is important when having a native module requiring another native-module which isn't core... Think about taking the entire fix from Wolfgang (https://www.mail-archive.com/yocto@yoctoproject.org/msg21489.html) and also patch daisy. 2nd: See https://github.com/rdm-dev/poky/commit/d58539e94126019126565e7e76f406f0d4975a0e for some other Perl quirks when using CPAN modules ... 3rd: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/perl/perl-native_5.20.0.bb?id=6839a39912d483c6a403bd52e5f889547f1f4807#n10 - compare to $(corelist -a Module::Build) - there is no Module::Build in 5.20 anymore. Maybe a look to 5.20.1 is also recommended: https://metacpan.org/pod/distribution/perl/pod/perldelta.pod Anfang der weitergeleiteten Nachricht: Von: Jens Rehsack rehs...@gmail.com Betreff: Aw: [yocto] [PATCH] Perl: fix PERL5LIB settings Datum: 8. November 2014 13:47:01 MEZ An: Burton, Ross ross.bur...@intel.com Kopie: Wolfgang Denk w...@denx.de, yocto@yoctoproject.org yocto@yoctoproject.org Am 07.11.2014 um 12:55 schrieb Burton, Ross ross.bur...@intel.com: Hi Wolfgang, On 5 November 2014 19:29, Wolfgang Denk w...@denx.de wrote: meta/recipes-devtools/perl/perl-native_5.14.3.bb | 4 ++-- meta/recipes-devtools/perl/perl_5.14.3.bb| 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) Perl was upgraded to 5.20.0 in July, can you rebase and verify that this is still required? I can finally confirm that it fixes the issues in daisy (bitbaking Dancer2 using https://github.com/rehsack/meta-cpan/tree/master/recipes-www/dancer2-perl). You can try whether Dancer2 bitbakes for dizzy and/or master to verify - for me it's impossible to create a dizzy build - to many daisy adoptions and release pressure for next weeks. If you know someone having dizzy - bitbake Dancer2, Unix::Statgrab or alike to prove ... Cheers -- Jens Rehsack rehs...@gmail.com -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] Perl: fix PERL5LIB settings
On Sat, 2014-11-08 at 13:47 +0100, Jens Rehsack wrote: Am 07.11.2014 um 12:55 schrieb Burton, Ross ross.bur...@intel.com: Hi Wolfgang, On 5 November 2014 19:29, Wolfgang Denk w...@denx.de wrote: meta/recipes-devtools/perl/perl-native_5.14.3.bb | 4 ++-- meta/recipes-devtools/perl/perl_5.14.3.bb| 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) Perl was upgraded to 5.20.0 in July, can you rebase and verify that this is still required? I can finally confirm that it fixes the issues in daisy (bitbaking Dancer2 using https://github.com/rehsack/meta-cpan/tree/master/recipes-www/dancer2-perl). You can try whether Dancer2 bitbakes for dizzy and/or master to verify - for me it's impossible to create a dizzy build - to many daisy adoptions and release pressure for next weeks. If you know someone having dizzy - bitbake Dancer2, Unix::Statgrab or alike to prove ... I was asked why this patch hasn't gone in. I agree there is a problem here which needs fixing. The trouble is that it doesn't easily apply to master, we don't have many perl experts to review this and patches against oe-core really need to go to the openembedded-core mailing list. I believe Aníbal did fix part of the problem with: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=6839a39912d483c6a403bd52e5f889547f1f4807 which leaves the perl-native part. I don't normally do this however I've updated the remaining part of the patch to apply against master and included it in master-next since I hate to see things getting lost. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fwd: [PATCH] Perl: fix PERL5LIB settings
Hi, On Thu, 2014-11-20 at 15:37 +0100, Jens Rehsack wrote: I've seen you sent a patch for Yocto for https://bugzilla.yoctoproject.org/show_bug.cgi?id=6890 which seems to me (compared to Wolfgang's Patch) incomplete and shows another issue ^^. Aníbal sent a patch for this, I merged it. http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=6839a39912d483c6a403bd52e5f889547f1f4807 I agree that there is a missing -native part, I've replied separately to that patch thread about why that patch was at risk of getting lost. 1st - Wolfgang's Patch also fixes the native-perl, which is important when having a native module requiring another native-module which isn't core... Think about taking the entire fix from Wolfgang (https://www.mail-archive.com/yocto@yoctoproject.org/msg21489.html) and also patch daisy. Firstly, we *need* to fix master. We can then consider backports to previous releases, sounds like we need this for dizzy and daisy in this case. 2nd: See https://github.com/rdm-dev/poky/commit/d58539e94126019126565e7e76f406f0d4975a0e for some other Perl quirks when using CPAN modules ... This does look exactly like the kind of fixes the perl recipe could use. Unfortunately the format of the mail and where it was sent to has meant it has fallen through the cracks. If it went to the openembedded-core mailing list, it would have had less chance of that. It does need some tweaks as per http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines in particular the subject should start cpan*:. I am a little puzzled why the --install_path pieces are removed and a little more detail in the commit message might help there. If you could do that, great. If not, please just say so and we'll have to see what else we can do but I'll try and ensure it doesn't get lost. 3rd: https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/perl/perl-native_5.20.0.bb?id=6839a39912d483c6a403bd52e5f889547f1f4807#n10 - compare to $(corelist -a Module::Build) - there is no Module::Build in 5.20 anymore. The PROVIDES += libmodule-build-perl-native is probably there to mean that recipes which DEPEND on that continued to work. Ideally, it sounds like we should try and remove that. Maybe a look to 5.20.1 is also recommended: https://metacpan.org/pod/distribution/perl/pod/perldelta.pod I'd be very happy to see that upgrade FWIW. I think part of the problem is we don't have a good set of automated perl tests (be it building perl modules, or testing the perl runtime). The problem isn't with perl itself, its just us interfacing to the tests that exist there and knowing for example which set of say 5 modules would test the widest range of ways of building perl modules. Any help with those things would be much appreciated. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Layer model doomed, unless we all work together
Hi Paul, [Re: [yocto] Layer model doomed, unless we all work together] On 14.11.20 (Thu 13:43) Paul Eggleton wrote: On Wednesday 19 November 2014 22:34:41 Joe MacDonald wrote: [[yocto] Layer model doomed, unless we all work together] On 14.11.18 (Tue 16:28) Philip Balister wrote: I see a couple of issues we need to start talking about: 1) recipes that need to move closer to core because a range of other packages use them. This was actually the only thing I thought needed further discussion (everything else should largely be a nod-in-agreement thing), as in some cases I'm not sure it's always clear what constitutes closer to the core. Poky and oe-core layers are pretty clear, but the next step beyond that isn't. Are all layers hosted on git.yoctoproject.org inherhently more core than layers on git.openenbedded.org? And there's a number of shells when you start including all of the github projects, setting aside other open-source project hosting services. The answer to me there is certainly not. I've said this recently in other discussions, but I'll say it here anyway in case anyone else isn't sure - layers on git.yoctoproject.org should not be considered in any way more official than anywhere else solely based on them being hosted there. Anyone who wants to maintain and publish a layer suitable for others to use can get a repository on git.yoctoproject.org - there's no official review, validation, or acceptance criteria in the general case just for having a repository there (beyond being related to the project, that is). That certainly makes sense to me, though I can respect if a project maintainer wanted to try to keep everything they put there contained to other projects hosted there. Probably that's not even the case now, I've not looked, but if I were starting a layer that I wanted to be dependent only on, say, oe-core, and it was still useful to the community at large, I would consider git.yoctoproject.org to be the most sensible place to host it. Regardless, I think your clarification makes perfect sense. To me this isn't so much about closer to the core, it's about: 1) sensible recipe groupings, e.g. meta-networking rather than a particular project's mixed recipes layer 2) good maintenance, i.e. recipes are semi-regularly updated when upstream releases happen, fixed when needed to accommodate changes that happen in other layers it depends upon such as OE-Core, and the maintainer is reasonably responsive to patches or questions relating to the layer. We need both of those things to encourage re-use, and if we have both then it doesn't really matter where a layer is hosted as long as it's listed in the layer index. Fair enough. Though I do think that a natural consequence of the groupings in #1 above would tend to have recipes that appear in multiple project's mixed recipe layers move toward the core. But I also agree that it needs to make sense for the layers involved. Looking at the link you sent out based on Paul's suggestion, I see I'm actually on both sides of this equation, so yay! And I'll limit the discussion to what's indexed there. Here're my examples. iscsi-initiator-utils: both in meta-networking nd meta-openstack. Both at the same version currently but wildly different contents. meta-openstack is a git.yoctoproject.org project, so does that make it closer to the core? I would think not, but as I recall there had been some comment about the openstack layer intending to limit layer dependencies outside Yocto core when it first appeared, so maybe making meta-networking a dependency is a non-starter for them. So I've talked to Bruce about meta-openstack before, with particular regard to the number of python recipes that the layer ships and future overlap with meta-python, and apparently the policy there is not to pull in other layers for some dependencies with the aim of avoiding breakage on upgrades. I don't like that very much at all, to be frank, but I can at least understand it given how huge OpenStack is. It does of course mean that the overlap with that layer in particular is only going to increase as time goes on. Hmm. Okay, I don't want to veer too far off the topic, but what I'm getting from this is that meta-openstack is a layer usable for building OpenStack, but otherwise probably isn't an ideal base for other layers. There's two obvious points of divergence between meta-networking recipes and meta-openstack ones, both of which have the same priority, and it sounds like there's going to be an increasing number of these with meta-python. I don't know that, given how large OpenStack is, adding other layer dependencies would amount to more than a drop in the bucket, but as a philosophical discussion rather than a technical one, I'll stick to knowing to regularly check the index and time I'm looking at recipes or working with a new
[yocto] [autobuilder][PATCH] buildset-config.controller: add nightly-arm64 target
This is based on the nightly-arm target with the beaglebone builds removed.
Signed-off-by: Ross Burton ross.bur...@intel.com
---
buildset-config.controller/nightly-arm64.conf | 27 +
1 file changed, 27 insertions(+)
create mode 100644 buildset-config.controller/nightly-arm64.conf
diff --git a/buildset-config.controller/nightly-arm64.conf
b/buildset-config.controller/nightly-arm64.conf
new file mode 100644
index 000..7c2524b
--- /dev/null
+++ b/buildset-config.controller/nightly-arm64.conf
@@ -0,0 +1,27 @@
+[nightly-arm64]
+builders: 'example-worker'
+repos: [{'poky':
+{'repourl':'git://git.yoctoproject.org/poky',
+'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-bsp'},
+ 'branch':'master'}},
+{'meta-qt3':
+{'repourl':'git://git.yoctoproject.org/meta-qt3',
+ 'branch':'master'}}]
+steps: [{'SetDest':{}},
+{'CheckOutLayers': {}},
+{'RunPreamble': {}},
+{'GetDistroVersion' : {'distro': 'poky'}},
+{'CreateAutoConf': {'machine': 'qemuarm64', 'SDKMACHINE' : 'i686',
'distro': 'poky', 'buildhistory' : True}},
+{'CreateBBLayersConf': {'buildprovider' : 'yocto'}},
+{'SyncPersistDB' : {'distro' : 'poky'}},
+{'BuildImages': {'images': 'core-image-sato core-image-sato-dev
core-image-sato-sdk core-image-minimal core-image-minimal-dev'}},
+{'RunSanityTests': {'images': 'core-image-minimal core-image-sato
core-image-sato-sdk'}},
+{'CreateAutoConf': {'machine': 'qemuarm64', 'SDKMACHINE' : 'i686',
'distro': 'poky', 'buildhistory' : False}},
+{'BuildToolchainImages': {}},
+{'CreateAutoConf': {'machine': 'qemuarm64', 'SDKMACHINE' : 'x86_64',
'distro': 'poky', 'buildhistory' : False}},
+{'BuildToolchainImages': {}},
+{'SyncPersistDB' : {'commit' : True, 'distro':'poky'}},
+{'PublishLayerTarballs':{}},
+{'SendErrorReport': {}},
+{'PublishArtifacts': {'artifacts': ['qemuarm64', 'ipk', 'toolchain',
'md5sums']}}]
+
--
1.7.10.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Yocto installation] Yocto installation on corporate environment
Hi All, I am looking for some feedback on yocto distribution installation and deployment into corporate environment. The context is the following: We will receive a commercial yocto distribution from a third party in form of a CD/DVD every year with some cumulative patches every months. This distribution will be used by different projects within the company to make products My concern is how to share/distribute this distribution with the following objectives: - Secure all dependencies on corporate network for product maintenance purpose - Easily access and installation of a given revision of the distribution - Control disk space and avoid each project to duplicate the distribution support - Avoid lock down effect on third-party proprietary installation mechanism I though about the following possibilities 1) Mirror all source code URLs including tarball delivery onto corporate network = very costly, need to support all reference type of version control system(Git, SVN, ) = risk to miss mirroring one url 2) Put in source control (Git) the content of the Downloads directory create by yocto = single Git may be very heavy with lot of binaries = Split Git but need then to use something to manage the forest like google repo tool 3) Rely on docker image and create a new version of docker image for each new distribution revision = working on a shell inside the docker image may be not much easy since need to rely on external volumes to access user personal data or environment Thanks in advance for your return BR Olivier -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
