Re: [oe] [PATCH 2/2 meta-networking] vsftpd: change default secure_chroot_dir
On 10/19/2013 12:29 AM, Joe MacDonald wrote:
Hi Roy,
Is this different from the patch I received from Ming Liu about a month
ago? It doesn't look it at first glance, but I didn't diff the two.
-J.
Sorry, I did not sync my repo, LiuMing patch is OK.
Thanks
-Roy
[[oe] [PATCH 2/2 meta-networking] vsftpd: change default secure_chroot_dir] On
13.10.10 (Thu 16:34) rongqing...@windriver.com wrote:
From: Roy Li
Change default value of secure_chroot_dir to /var/run/vsftpd/empty, add
volatiles entry for it, to ensure it won't fail to start by xinetd.
Signed-off-by: Roy Li
---
.../vsftpd/files/change-secure_chroot_dir.patch| 55
meta-networking/recipes-daemons/vsftpd/files/init |2 +-
.../vsftpd/files/volatiles.99_vsftpd |2 +
.../recipes-daemons/vsftpd/vsftpd_3.0.0.bb |7 ++-
4 files changed, 64 insertions(+), 2 deletions(-)
create mode 100644
meta-networking/recipes-daemons/vsftpd/files/change-secure_chroot_dir.patch
create mode 100644
meta-networking/recipes-daemons/vsftpd/files/volatiles.99_vsftpd
diff --git
a/meta-networking/recipes-daemons/vsftpd/files/change-secure_chroot_dir.patch
b/meta-networking/recipes-daemons/vsftpd/files/change-secure_chroot_dir.patch
new file mode 100644
index 000..e7a673e
--- /dev/null
+++
b/meta-networking/recipes-daemons/vsftpd/files/change-secure_chroot_dir.patch
@@ -0,0 +1,55 @@
+vsftpd: change secure_chroot_dir default value
+
+Upstream-Status: Pending
+
+Change secure_chroot_dir pointing to a volatile directory.
+
+Signed-off-by: Ming Liu
+---
+ INSTALL |6 +++---
+ tunables.c|2 +-
+ vsftpd.conf.5 |2 +-
+ 3 files changed, 5 insertions(+), 5 deletions(-)
+
+diff -urpN a/INSTALL b/INSTALL
+--- a/INSTALL 2013-09-13 10:23:57.504972397 +0800
b/INSTALL 2013-09-13 10:25:25.664971779 +0800
+@@ -27,11 +27,11 @@ user in case it does not already exist.
+ [root@localhost root]# useradd nobody
+ useradd: user nobody exists
+
+-2b) vsftpd needs the (empty) directory /usr/share/empty in the default
++2b) vsftpd needs the (empty) directory /var/run/vsftpd/empty in the default
+ configuration. Add this directory in case it does not already exist. e.g.:
+
+-[root@localhost root]# mkdir /usr/share/empty/
+-mkdir: cannot create directory `/usr/share/empty': File exists
++[root@localhost root]# mkdir /var/run/vsftpd/empty/
++mkdir: cannot create directory `/var/run/vsftpd/empty': File exists
+
+ 2c) For anonymous FTP, you will need the user "ftp" to exist, and have a
+ valid home directory (which is NOT owned or writable by the user "ftp").
+diff -urpN a/tunables.c b/tunables.c
+--- a/tunables.c 2013-09-13 10:26:29.554972817 +0800
b/tunables.c 2013-09-13 10:27:18.104972210 +0800
+@@ -254,7 +254,7 @@ tunables_load_defaults()
+ /* -rw--- */
+ tunable_chown_upload_mode = 0600;
+
+- install_str_setting("/usr/share/empty", &tunable_secure_chroot_dir);
++ install_str_setting("/var/run/vsftpd/empty", &tunable_secure_chroot_dir);
+ install_str_setting("ftp", &tunable_ftp_username);
+ install_str_setting("root", &tunable_chown_username);
+ install_str_setting("/var/log/xferlog", &tunable_xferlog_file);
+diff -urpN a/vsftpd.conf.5 b/vsftpd.conf.5
+--- a/vsftpd.conf.52013-09-13 10:09:33.774972462 +0800
b/vsftpd.conf.52013-09-13 10:10:41.914971989 +0800
+@@ -969,7 +969,7 @@ This option should be the name of a dire
+ directory should not be writable by the ftp user. This directory is used
+ as a secure chroot() jail at times vsftpd does not require filesystem access.
+
+-Default: /usr/share/empty
++Default: /var/run/vsftpd/empty
+ .TP
+ .B ssl_ciphers
+ This option can be used to select which SSL ciphers vsftpd will allow for
diff --git a/meta-networking/recipes-daemons/vsftpd/files/init
b/meta-networking/recipes-daemons/vsftpd/files/init
index d0ec010..513f407 100755
--- a/meta-networking/recipes-daemons/vsftpd/files/init
+++ b/meta-networking/recipes-daemons/vsftpd/files/init
@@ -2,7 +2,7 @@
DAEMON=/usr/sbin/vsftpd
NAME=vsftpd
DESC="FTP Server"
-ARGS=""
+ARGS="/etc/vsftpd.conf"
FTPDIR=/var/lib/ftp
test -f $DAEMON || exit 0
diff --git a/meta-networking/recipes-daemons/vsftpd/files/volatiles.99_vsftpd
b/meta-networking/recipes-daemons/vsftpd/files/volatiles.99_vsftpd
new file mode 100644
index 000..0f80776
--- /dev/null
+++ b/meta-networking/recipes-daemons/vsftpd/files/volatiles.99_vsftpd
@@ -0,0 +1,2 @@
+#
+d root root 0755 /var/run/vsftpd/empty none
diff --git a/meta-networking/recipes-daemons/vsftpd/vsftpd_3.0.0.bb
b/meta-networking/recipes-daemons/vsftpd/vsftpd_3.0.0.bb
index 7677477..09de1e9 100644
--- a/meta-networking/recipes-daemons/vsftpd/vsftpd_3.0.0.bb
+++ b/meta-networking/recipes-daemons/vsftpd/vsftpd_3.0.0.bb
@@ -14,6 +14,8 @@ SRC_URI =
"https://security.appspot.com/downloads/vsftpd-${PV}.tar.gz \
file://vsftpd.conf \
file://vsftpd.user_list \
file://vsftpd.f
Re: [oe] Regarding layers and their versioning.
Thanks for your replies. It was very reassuring that I'm not doing the wrong thing. -- Søren Holm ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][meta-multimedia][PATCH 1/2] llvm3.2: drop this version
On Sun, Oct 20, 2013 at 5:53 AM, Martin Jansa wrote: > * 3.3 is used by default mesa config, 2.8 is used in meta-java, keep 2.9 as > last in 2* who is using 2.9 ? I would suggest to keep the one we know is used. > > Signed-off-by: Martin Jansa > --- > meta-oe/recipes-core/llvm/llvm3.2/arm_fenv_uclibc.patch | 14 -- > meta-oe/recipes-core/llvm/llvm3.2_3.2.bb| 9 - > 2 files changed, 23 deletions(-) > delete mode 100644 meta-oe/recipes-core/llvm/llvm3.2/arm_fenv_uclibc.patch > delete mode 100644 meta-oe/recipes-core/llvm/llvm3.2_3.2.bb > > diff --git a/meta-oe/recipes-core/llvm/llvm3.2/arm_fenv_uclibc.patch > b/meta-oe/recipes-core/llvm/llvm3.2/arm_fenv_uclibc.patch > deleted file mode 100644 > index c3ae494..000 > --- a/meta-oe/recipes-core/llvm/llvm3.2/arm_fenv_uclibc.patch > +++ /dev/null > @@ -1,14 +0,0 @@ > -Index: llvm-2.9/include/llvm/Support/FEnv.h > -=== > llvm-2.9.orig/include/llvm/Support/FEnv.h 2010-11-29 20:44:50.0 > +0100 > -+++ llvm-2.9/include/llvm/Support/FEnv.h 2011-11-18 18:42:22.580161297 > +0100 > -@@ -17,6 +17,9 @@ > - > - #include "llvm/Config/config.h" > - #include > -+ > -+#undef HAVE_FENV_H > -+ > - #ifdef HAVE_FENV_H > - #include > - #endif > diff --git a/meta-oe/recipes-core/llvm/llvm3.2_3.2.bb > b/meta-oe/recipes-core/llvm/llvm3.2_3.2.bb > deleted file mode 100644 > index 48e27b9..000 > --- a/meta-oe/recipes-core/llvm/llvm3.2_3.2.bb > +++ /dev/null > @@ -1,9 +0,0 @@ > -require llvm.inc > -require llvm3.inc > - > -# 3.2 is different then 2.8, 2.9 and 3.3 > -LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=60fdd7739841f04a2ce2171a726be8f3" > - > -SRC_URI_append_libc-uclibc = " file://arm_fenv_uclibc.patch " > -SRC_URI[md5sum] = "71610289bbc819e3e15fdd562809a2d7" > -SRC_URI[sha256sum] = > "125090c4d26740f1d5e9838477c931ed7d9ad70d599ba265f46f3a42cb066343" > -- > 1.8.4 > > ___ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Regarding layers and their versioning.
On Mon, Oct 21, 2013 at 7:01 AM, Paul Eggleton wrote: > On Monday 21 October 2013 09:29:27 Anders Darander wrote: >> "Søren Holm" wrote: >> >What is the best way to manage a private repo with recipes as well as >> >meta-oe, >> >meta-core and meta-angstrom. >> > >> >Currently I have a private repo that has the layers attached as >> >submodules. Is that a crazy setup or what? >> >> We're doing the same internally at ChargeStorm. One benefit is that we're >> having our "master" repo keeping track of all the layers that we're using >> and which revision of those layers. >> >> Other people / projects just use a shell script checking out the desired >> layers. Some people combines layers into one huge repo (though I'd >> personally not recommend that approach). (That'd be similar to how Poky is >> being managed). >> >> Yet other people / projects use repo. >> >> It's up to what you're comfortable with in the end. > > Just to clarify, we use the combo-layer script (scripts/combo-layer) to manage > the Poky repository. It can combine multiple repositories or even parts of > repositories into one and keep it up-to-date. It works well for our purposes, > i.e. providing a single repository that people can download containing all of > the needed basic components. However, it's just one of a number of different > solutions in this area and you'd have to evaluate which tool works best for > your situation. At O.S. Systems we used some variants here. We started with forking and moved to combo-layer script. The combo-layer works for most case but it fails badly with empty merge commits and like. So it works quite fine for Yocto use case but not as fine for company workflow. In the end we choose 'repo' and we provide some 'platform' for customers where we link all need projects in a single .xml file; this scales fine and is quite easy to use. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [meta-oe][meta-multimedia][PATCH 2/2] bigbuckbunny: Don't use whole avi in LIC_FILES_CHKSUM and add version
On Sun, Oct 20, 2013 at 10:53 AM, Martin Jansa wrote: > * it's causing huge deploy/licenses files: > 211Mdeploy/licenses/bigbuckbunny-480p > 317Mdeploy/licenses/bigbuckbunny-720p > 886Mdeploy/licenses/bigbuckbunny-1080p > and avi checksum is already verified by SRC_URI checksums > > Signed-off-by: Martin Jansa Agreed! Acked-by: Otavio Salvador -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Regarding layers and their versioning.
On Mon, Oct 21, 2013 at 09:29:27AM +0100, Anders Darander wrote: > > > "Søren Holm" wrote: > >Hello > > > >What is the best way to manage a private repo with recipes as well as > >meta-oe, > >meta-core and meta-angstrom. > > >Currently I have a private repo that has the layers attached as > >submodules. Is > >that a crazy setup or what? > > We're doing the same internally at ChargeStorm. One benefit is that we're > having our "master" repo keeping track of all the layers that we're using and > which revision of those layers. > > Other people / projects just use a shell script checking out the desired > layers. Some people combines layers into one huge repo (though I'd personally > not recommend that approach). (That'd be similar to how Poky is being > managed). > > Yet other people / projects use repo. > > It's up to what you're comfortable with in the end. I was using Makefile to checkout correct set of layers with correct revisions for SHR before and then changed it to use layerman script very similar to script used in angstrom-setup-scripts, because layers.txt is more "declarative" and easier to update than what I had in Makefile. For webos-ports project I use the same. For webos we recently switched from repo with submodules to repository with similar script (mcf - this time in python). Mostly because repos with submodules don't work well when replicating from gerrit to github. I think that biggest advantage of solution with some script, is that layers are still standalone checkouts, which developers can use as any other project (easier to submit patches upstream etc). And the script can be more clever than git pull --rebase in repo with submodules, e.g. for jenkins builds I want to automatically update build configuration in non-interactive way (because jenkins shouldn't ever keep some local changes), but for local build I want to preserve developer's local.conf changes and e.g. extra layers added in bblayers.conf etc. -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] State of bitbake world
On Mon, Oct 21, 2013 at 12:38 PM, Martin Jansa wrote: > On Mon, Oct 21, 2013 at 10:58:45AM +0200, Andrea Adami wrote: >> >> > qemux86* common (5): >> > meta-openembedded/meta-initramfs/recipes-bsp/images/initramfs-kexecboot-klibc-image.bb, >> > do_rootfs >> >> >> Hi Martin, thanks for taking care of all those builds. >> About this new do_rootfs failure [1], it seems related to update-rc.d >> /postinst code. >> >> As you already know, for this image we don't want any initscript nor >> package manager cruft but now and then some change in oe-core opens >> unwanted doors... >> >> I'll investigate what's happening: seems strange it only fails on x86*. > > This world build didn't have this fix included: > http://git.openembedded.org/openembedded-core/commit/?id=2b179d90eacc58f0b217f64407782a9174362850 > > it's queued for next one, maybe it will help. > >> | makedevs: No entry for root in search list > is also interesting, should it be calling makedevs in this initramfs > (IIRC kexecboot is creating all dev nodes manually?) > Yes... > | makedevs: No entry for root in search list Seems oiginated by commit d073ca77ba886c7912abd3ec064088 1c00aea3bb image.bbclass: create device table after package installation In fact, we set IMAGE_DEVICE_TABLES = "" for the initramfs then we mount devtmps during init. Cheers Andrea > >> >> Cheers >> Andrea >> >> >> [1] >> ERROR: Function failed: do_rootfs (log file is located at >> /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/temp/log.do_rootfs.23292) >> ERROR: Logfile of failure stored in: >> /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/temp/log.do_rootfs.23292 >> Log data follows: >> | DEBUG: Executing python function rootfs_process_ignore >> | DEBUG: Python function rootfs_process_ignore finished >> | DEBUG: Executing python function rootfs_runtime_mapping >> | DEBUG: Python function rootfs_runtime_mapping finished >> | DEBUG: Executing shell function do_rootfs >> | Downloading >> file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/Packages. >> | Updated list of available packages in >> /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe. >> | Downloading >> file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/all/Packages. >> | Updated list of available packages in >> /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-all. >> | Downloading >> file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/i586/Packages. >> | Updated list of available packages in >> /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-i586. >> | Downloading >> file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/qemux86/Packages. >> | Updated list of available packages in >> /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-qemux86. >> | Downloading >> file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/Packages. >> | Updated list of available packages in >> /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe. >> | Downloading >> file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/all/Packages. >> | Updated list of available packages in >> /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-all. >> | Downloading >> file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/i586/Packages. >> | Updated list of available packages in >> /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-i586. >> | Downloading >> file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/qemux86/Packages. >> | Updated list of available packages in >> /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-qemux86. >> | Installing kexec-klibc (2.0.2-r0.16) to root... >> | Downloading >> file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/i586/kexec-klibc_2.0.2-r0.16_i586.ipk. >> | Installing run-postinsts (1.0-r9.26) to root... >> | Downloading >> file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/i586/run-postinsts_1.0-r9.26_i586.ipk. >> | Installing update-rc.d (0.7-r5.37) to root... >> | Downloading >> file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-e
Re: [oe] [OE-core] State of bitbake world
On Mon, Oct 21, 2013 at 10:58:45AM +0200, Andrea Adami wrote: > > > qemux86* common (5): > > meta-openembedded/meta-initramfs/recipes-bsp/images/initramfs-kexecboot-klibc-image.bb, > > do_rootfs > > > Hi Martin, thanks for taking care of all those builds. > About this new do_rootfs failure [1], it seems related to update-rc.d > /postinst code. > > As you already know, for this image we don't want any initscript nor > package manager cruft but now and then some change in oe-core opens > unwanted doors... > > I'll investigate what's happening: seems strange it only fails on x86*. This world build didn't have this fix included: http://git.openembedded.org/openembedded-core/commit/?id=2b179d90eacc58f0b217f64407782a9174362850 it's queued for next one, maybe it will help. > | makedevs: No entry for root in search list is also interesting, should it be calling makedevs in this initramfs (IIRC kexecboot is creating all dev nodes manually?) > > Cheers > Andrea > > > [1] > ERROR: Function failed: do_rootfs (log file is located at > /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/temp/log.do_rootfs.23292) > ERROR: Logfile of failure stored in: > /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/temp/log.do_rootfs.23292 > Log data follows: > | DEBUG: Executing python function rootfs_process_ignore > | DEBUG: Python function rootfs_process_ignore finished > | DEBUG: Executing python function rootfs_runtime_mapping > | DEBUG: Python function rootfs_runtime_mapping finished > | DEBUG: Executing shell function do_rootfs > | Downloading > file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/Packages. > | Updated list of available packages in > /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe. > | Downloading > file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/all/Packages. > | Updated list of available packages in > /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-all. > | Downloading > file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/i586/Packages. > | Updated list of available packages in > /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-i586. > | Downloading > file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/qemux86/Packages. > | Updated list of available packages in > /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-qemux86. > | Downloading > file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/Packages. > | Updated list of available packages in > /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe. > | Downloading > file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/all/Packages. > | Updated list of available packages in > /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-all. > | Downloading > file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/i586/Packages. > | Updated list of available packages in > /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-i586. > | Downloading > file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/qemux86/Packages. > | Updated list of available packages in > /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-qemux86. > | Installing kexec-klibc (2.0.2-r0.16) to root... > | Downloading > file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/i586/kexec-klibc_2.0.2-r0.16_i586.ipk. > | Installing run-postinsts (1.0-r9.26) to root... > | Downloading > file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/i586/run-postinsts_1.0-r9.26_i586.ipk. > | Installing update-rc.d (0.7-r5.37) to root... > | Downloading > file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/all/update-rc.d_0.7-r5.37_all.ipk. > | Installing ubiattach-klibc (1.5.0-r0.28) to root... > | Downloading > file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/i586/ubiattach-klibc_1.5.0-r0.28_i586.ipk. > | Installing kexecboot-klibc (0.6-r0.2) to root... > | Downloading > file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/qemux86/kexecboot-klibc_0.6-r0.2_qemux86.ipk. > | > /ho
Re: [oe] Regarding layers and their versioning.
On 21 October 2013 09:29, Anders Darander wrote: > We're doing the same internally at ChargeStorm. One benefit is that we're > having our > "master" repo keeping track of all the layers that we're using and which > revision of > those layers. Guacamayo uses a master repository with submodules for each layer. Works nicely as the layers are pinned to revisions which are known to work, and then branches can be made to integrate upgraded layers. Ross ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Regarding layers and their versioning.
On Monday 21 October 2013 09:29:27 Anders Darander wrote: > "Søren Holm" wrote: > >What is the best way to manage a private repo with recipes as well as > >meta-oe, > >meta-core and meta-angstrom. > > > >Currently I have a private repo that has the layers attached as > >submodules. Is that a crazy setup or what? > > We're doing the same internally at ChargeStorm. One benefit is that we're > having our "master" repo keeping track of all the layers that we're using > and which revision of those layers. > > Other people / projects just use a shell script checking out the desired > layers. Some people combines layers into one huge repo (though I'd > personally not recommend that approach). (That'd be similar to how Poky is > being managed). > > Yet other people / projects use repo. > > It's up to what you're comfortable with in the end. Just to clarify, we use the combo-layer script (scripts/combo-layer) to manage the Poky repository. It can combine multiple repositories or even parts of repositories into one and keep it up-to-date. It works well for our purposes, i.e. providing a single repository that people can download containing all of the needed basic components. However, it's just one of a number of different solutions in this area and you'd have to evaluate which tool works best for your situation. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] [OE-core] State of bitbake world
> qemux86* common (5): > meta-openembedded/meta-initramfs/recipes-bsp/images/initramfs-kexecboot-klibc-image.bb, > do_rootfs Hi Martin, thanks for taking care of all those builds. About this new do_rootfs failure [1], it seems related to update-rc.d /postinst code. As you already know, for this image we don't want any initscript nor package manager cruft but now and then some change in oe-core opens unwanted doors... I'll investigate what's happening: seems strange it only fails on x86*. Cheers Andrea [1] ERROR: Function failed: do_rootfs (log file is located at /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/temp/log.do_rootfs.23292) ERROR: Logfile of failure stored in: /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/temp/log.do_rootfs.23292 Log data follows: | DEBUG: Executing python function rootfs_process_ignore | DEBUG: Python function rootfs_process_ignore finished | DEBUG: Executing python function rootfs_runtime_mapping | DEBUG: Python function rootfs_runtime_mapping finished | DEBUG: Executing shell function do_rootfs | Downloading file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/Packages. | Updated list of available packages in /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe. | Downloading file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/all/Packages. | Updated list of available packages in /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-all. | Downloading file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/i586/Packages. | Updated list of available packages in /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-i586. | Downloading file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/qemux86/Packages. | Updated list of available packages in /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-qemux86. | Downloading file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/Packages. | Updated list of available packages in /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe. | Downloading file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/all/Packages. | Updated list of available packages in /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-all. | Downloading file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/i586/Packages. | Updated list of available packages in /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-i586. | Downloading file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/qemux86/Packages. | Updated list of available packages in /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/lists/oe-qemux86. | Installing kexec-klibc (2.0.2-r0.16) to root... | Downloading file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/i586/kexec-klibc_2.0.2-r0.16_i586.ipk. | Installing run-postinsts (1.0-r9.26) to root... | Downloading file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/i586/run-postinsts_1.0-r9.26_i586.ipk. | Installing update-rc.d (0.7-r5.37) to root... | Downloading file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/all/update-rc.d_0.7-r5.37_all.ipk. | Installing ubiattach-klibc (1.5.0-r0.28) to root... | Downloading file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/i586/ubiattach-klibc_1.5.0-r0.28_i586.ipk. | Installing kexecboot-klibc (0.6-r0.2) to root... | Downloading file:/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/deploy/ipk/qemux86/kexecboot-klibc_0.6-r0.2_qemux86.ipk. | /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/info/run-postinsts.postinst: 8: /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs//var/lib/opkg/info/run-postinsts.postinst: /etc/init.d/run-postinsts: not found | update-rc.d: /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/qemux86-oe-linux/initramfs-kexecboot-klibc-image/1.0-r0/rootfs/etc/init.d/run-postinsts exists during rc.d purge (continuing) | Removing any
Re: [oe] State of bitbake world
On 20 October 2013 20:43, Martin Jansa wrote: > libtool-cross-2.4.2: libtool-cross: configure was passed unrecognised > options: --with-sysroot > libxdmcp-1.1.1: libxdmcp: configure was passed unrecognised options: > --without-groff --disable-malloc0returnsnull --without-ps2pdf --disable-specs > libxau-1.0.8: libxau: configure was passed unrecognised options: > --without-xmlto --disable-malloc0returnsnull --without-ps2pdf --without-groff > --without-fop --disable-specs [snip many many more lines] Well at least my QA test works. :) I thought I'd send patches for a large number of these already that are in oe-core, but obviously not. I'll definitely do that shortly. Ross ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Re: [oe] Regarding layers and their versioning.
"Søren Holm" wrote: >Hello > >What is the best way to manage a private repo with recipes as well as >meta-oe, >meta-core and meta-angstrom. >Currently I have a private repo that has the layers attached as >submodules. Is >that a crazy setup or what? We're doing the same internally at ChargeStorm. One benefit is that we're having our "master" repo keeping track of all the layers that we're using and which revision of those layers. Other people / projects just use a shell script checking out the desired layers. Some people combines layers into one huge repo (though I'd personally not recommend that approach). (That'd be similar to how Poky is being managed). Yet other people / projects use repo. It's up to what you're comfortable with in the end. > .. and while I'm at it - which >revision of >all those layers are ment to match together? does master og meta-oe >match >master of meta-core or do they have simmilar tags/branches. Yes, in general master of all (most) layers are intended to be used with master from oe-core. Most layers k att least bigger and more used ones) try to support a few old releases, and typically do this using the same branch name as used in oe-core. Cheers, Anders -- ChargeStorm AB / eStorm ___ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel
