: Julian Pidancet
---
meta/recipes-connectivity/openssh/openssh_5.8p2.bb | 29 +--
1 files changed, 8 insertions(+), 21 deletions(-)
diff --git a/meta/recipes-connectivity/openssh/openssh_5.8p2.bb
b/meta/recipes-connectivity/openssh/openssh_5.8p2.bb
index 030a83b..c94ec84 100644
On Tue, Sep 27, 2011 at 12:38 AM, Saul Wold wrote:
>
> Is there a reason you did not include the group and --disable-password here?
>
> I think it would be good to leave thelong name options in also.
>
> Sau!
>
The -U option creates a group with the same name. The
--disable-password option only e
On Tue, Sep 27, 2011 at 12:59 AM, Julian Pidancet
wrote:
> On Tue, Sep 27, 2011 at 12:38 AM, Saul Wold wrote:
>>
>> Is there a reason you did not include the group and --disable-password here?
>>
>> I think it would be good to leave thelong name options in also.
>
modified from the previous proposed version to
use useradd long options for more clarity.
Signed-off-by: Julian Pidancet
---
meta/recipes-connectivity/openssh/openssh_5.8p2.bb | 29 +--
1 files changed, 8 insertions(+), 21 deletions(-)
diff --git a/meta/recipes-connectivity
, and this issue was preventing to use useradd and
groupadd long options while using the class.
Signed-off-by: Julian Pidancet
---
.../shadow/files/add_root_cmd_options.patch| 204 ++--
1 files changed, 101 insertions(+), 103 deletions(-)
diff --git a/meta/recipes-exten
, it had
been reworked to use useradd long options in the USERADD_PARAM variable.
Julian Pidancet (2):
Fix the --root option in shadow-native programs.
Use useradd and update-rc.d classes in the OpenSSH recipe
meta/recipes-connectivity/openssh/openssh_5.8p2.bb | 29 +--
.../shadow/files
been suggested in an answer to one of my
initial post.
Julian Pidancet (2):
Fix the --root option in shadow-native programs.
Use useradd and update-rc.d classes in the OpenSSH recipe
meta/recipes-connectivity/openssh/openssh_5.8p2.bb | 29 +---
.../shadow/files/add_root_cmd_options
modified from the previous proposed version to
use useradd long options for more clarity.
Signed-off-by: Julian Pidancet
---
meta/recipes-connectivity/openssh/openssh_5.8p2.bb | 29 +--
1 files changed, 8 insertions(+), 21 deletions(-)
diff --git a/meta/recipes-connectivity
, and this issue was preventing to use useradd and
groupadd long options while using the class.
Signed-off-by: Julian Pidancet
---
.../shadow/files/add_root_cmd_options.patch| 180 ++--
1 files changed, 89 insertions(+), 91 deletions(-)
diff --git a/meta/recipes-exten
modified from the previous proposed version to
use useradd long options for more clarity.
Signed-off-by: Julian Pidancet
---
meta/recipes-connectivity/openssh/openssh_5.8p2.bb | 29 +--
1 files changed, 8 insertions(+), 21 deletions(-)
diff --git a/meta/recipes-connectivity
the OpenSSH
recipe to useradd.
v2: Fixed a typo in add_root_cmd_options.patch, --root is equivalent to -Q
instead of -R.
v3: Comment modifications and add Signed-off-by line in the modified patch
directly.
Julian Pidancet (2):
Fix the --root option in shadow-native programs
Use useradd and
, and this issue was preventing to use useradd and
groupadd long options while using the class.
Signed-off-by: Julian Pidancet
---
.../shadow/files/add_root_cmd_options.patch| 189 ++--
1 files changed, 98 insertions(+), 91 deletions(-)
diff --git a/meta/recipes-exten
On Sat, Oct 22, 2011 at 12:54 PM, Nicolas François
wrote:
> Hello,
>
> I'm the upstream maintainer of the shadow utilities.
>
> I was informed of the OpenEmbedded's add_root_cmd_options patch and would
> like to integrate it upstream.
>
> First of all, thanks a lot for implementing this feature. I
applications with a 64bit kernel without having to
deal with two separate libc.
Signed-off-by: Julian Pidancet
---
meta/recipes-devtools/binutils/binutils-cross.inc |3 ++-
meta/recipes-devtools/binutils/binutils.inc|3 ++-
meta/recipes-devtools/gcc/gcc-common.inc
The coreutils configure script is unable determine how to get free
space from the Operating System when cross-compiling. This patch
gives it some extra help by setting the fu_cv_sys_stat_statfs2_bsize
variable to yes before invoking the configure script.
Signed-off-by: Julian Pidancet
---
meta
On Wed, Oct 26, 2011 at 2:59 AM, McClintock Matthew-B29882
wrote:
> On Mon, Oct 24, 2011 at 8:18 PM, Julian Pidancet
> wrote:
>> +do_configure_prepend () {
>> + export fu_cv_sys_stat_statfs2_bsize=yes
>
> I'm asking out of curiosity.. why don't these go i
s a struct statfs containing a f_bsize field. That's why
the fu_cv_sys_stat_statfs2_bsize variable has to be defined for
both libcs.
Signed-off-by: Julian Pidancet
---
meta/recipes-core/coreutils/coreutils_8.14.bb |2 +-
meta/site/common-glibc|3 +++
meta/sit
On Wed, Oct 26, 2011 at 3:09 AM, McClintock Matthew-B29882
wrote:
> On Mon, Oct 24, 2011 at 8:18 PM, Julian Pidancet
> wrote:
>> This patch introduces a distro feature which enables gcc to produce
>> both 32bit and 64bit code, and enables binutils to operate on both
>>
On 11/08/11 20:29, Richard Purdie wrote:
>
> I'm left wondering how useful the resulting compiler is to most users.
> In most cases a user would expect full libc support and hence this is
> likely to confuse them. I do appreciate people do have usecases for a
> compiler that can handle the other b
-targets=powerpc64 option (although 'all' also works).
Note: - Untested on powerpc and sparc. But I believe it works the same
as with x86.
- gcc in meta-toolchain is also made multiarch.
Signed-off-by: Julian Pidancet
---
meta/recipes-devtools/binutils/binutils-cross.inc |3
On Wed, Nov 16, 2011 at 1:01 AM, Julian Pidancet
wrote:
> This patch introduces a distro feature which enables gcc to produce
> both 32bit and 64bit code, and enables binutils to operate on both
> 32bit and 64bit binaries. It differs from multilib toolchains in
> that it does no
On Wed, Nov 23, 2011 at 4:47 PM, Richard Purdie
wrote:
> On Wed, 2011-11-23 at 16:39 +0000, Julian Pidancet wrote:
>> On Wed, Nov 16, 2011 at 1:01 AM, Julian Pidancet
>> wrote:
>> > This patch introduces a distro feature which enables gcc to produce
>> > both
>> +def get_gcc_multiarch_setting(bb, d):
>> + if 'multiarch' in bb.data.getVar('DISTRO_FEATURES',d,1).split() :
>> + if bb.data.getVar('TARGET_ARCH', d, 1) in [ 'i586', 'i686' ] :
>> + return "--enable-targets=all"
>> + if bb.data.getVar('TARGET_ARCH', d, 1) in [ 'power
On Thu, Nov 24, 2011 at 5:36 PM, Khem Raj wrote:
>
> and we also need multiarch support in gdb recipes as well.
>
Support for Biarch exists in gdb for x86 since May 2009, and it is
enabled by default as far as I can tell.
I managed to dig up the exact commit in the gdb sources:
http://sourceware.
d.getVar.
- Remove i686 from the architecture list because it doesn't seem
to be a valid TARGET_ARCH any more in OE.
- Configure gdb (gdb and gdb-cross) with --enable-64-bit-bfd if
multiarch DISTRO_FEATURE is present
Signed-off-by: Julian Pidancet
---
meta/recipes-devtools/binutils/bin
On Mon, Nov 28, 2011 at 9:32 PM, McClintock Matthew-B29882
wrote:
> On Fri, Nov 25, 2011 at 5:40 PM, Richard Purdie
> wrote:
>> This is firmly in multilib territory as its not just libgcc but libc as
>> well and so it goes on.
>>
>> One of the reasons I'm nervous of the patch you're replying to i
On Tue, Nov 29, 2011 at 3:48 PM, Saul Wold wrote:
>
> Julian,
>
> Thanks for your patience, this is merged into OE-Core
>
> Thanks
> Sau!
>
Saul, I believe you applied the wrong version of the patch.
According to:
http://git.openembedded.org/openembedded-core/commit/?id=99e295ef30ba02db396
t-bfd if
multiarch DISTRO_FEATURE is present
Signed-off-by: Julian Pidancet
---
meta/recipes-devtools/gcc/gcc-common.inc | 17 ++---
meta/recipes-devtools/gdb/gdb-common.inc |1 +
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-commo
On 04/09/12 19:01, Liu, Song wrote:
> Hi all,
>
> This is to restate and clarify the schedule for Yocto Project 1.2 M4
> (milestone 4). If you are concerned or have patches you would like to merge,
> please see the following dates:
>
> 1. RC3 official patch cut-off time: 12:00AM April 8th, 2012
On Thu, Apr 12, 2012 at 5:55 PM, Khem Raj wrote:
>
> I think that string is fine as long as its just for yocto but I think
> for OE-Core we are going to do a General release
> so tagging that with something yocto project will be very confusing
> unless we plan to do different releases of OE-Core f
30 matches
Mail list logo
