Marcelo Coelho | 1 Mar 01:25
Picon

Hardened profiles and old gcc/glibc versions

Hi!

I'm trying to setup a server and I tried to use the server profile.
That gave me a lot of warnings about not being a tested profile.

Then I tested the hardened one. Bad luck too, as it fails due to a
sanity check "Downgrading glibc is not supported and a sure way to
destruction"

So, I thought about using a hardened stage3 and go from there... Well,
there was a 2007.0-pre... (something) on my mirror. So I thought about
asking you guys if you know what is going on and how I can install
this server...

Thanks for your help!
Ned Ludd | 1 Mar 01:46
Picon
Favicon

Re: Hardened profiles and old gcc/glibc versions

On Thu, 2007-03-01 at 00:25 +0000, Marcelo Coelho wrote:
> Hi!
> 
> 
> I'm trying to setup a server and I tried to use the server profile.
> That gave me a lot of warnings about not being a tested profile.
> 
> Then I tested the hardened one. Bad luck too, as it fails due to a
> sanity check "Downgrading glibc is not supported and a sure way to
> destruction"

"glibc"
This does not sound embedded at all. 

Please use the gentoo-hardened list for hardened questions. 
Unless you are asking about "uclibc+hardened" which clearly you can't
be..

> So, I thought about using a hardened stage3 and go from there... Well,
> there was a 2007.0-pre... (something) on my mirror. So I thought about
> asking you guys if you know what is going on and how I can install
> this server...
> 
> 
> Thanks for your help!
--

-- 
Ned Ludd <solar@...>
Gentoo Linux

(Continue reading)

Marcelo Coelho | 1 Mar 10:46
Picon

Re: Hardened profiles and old gcc/glibc versions

Sorry. It was late and didn't read the "To" field before sending.

2007/3/1, Ned Ludd <solar@...>:
> On Thu, 2007-03-01 at 00:25 +0000, Marcelo Coelho wrote:
> > Hi!
> >
> >
> > I'm trying to setup a server and I tried to use the server profile.
> > That gave me a lot of warnings about not being a tested profile.
> >
> > Then I tested the hardened one. Bad luck too, as it fails due to a
> > sanity check "Downgrading glibc is not supported and a sure way to
> > destruction"
>
> "glibc"
> This does not sound embedded at all.
>
> Please use the gentoo-hardened list for hardened questions.
> Unless you are asking about "uclibc+hardened" which clearly you can't
> be..
>
>
>
>
> > So, I thought about using a hardened stage3 and go from there... Well,
> > there was a 2007.0-pre... (something) on my mirror. So I thought about
> > asking you guys if you know what is going on and how I can install
> > this server...
> >
> >
(Continue reading)

Jakub Ladman | 3 Mar 17:49
Picon

cross-emerging tcl failed

Hi Friends

At this time is not possible to cross-emerge any version of tcl for sh4 
embedded gentoo system, from portage.

The stable version failed with:
sh4-pc-linux-uclibc-gcc -pipe -c -Os -pipe -Wall -Wno-implicit-int -fno-strict-aliasing -fPIC
-I./../generic -I. -DPEEK_XCLOSEIM=1 -D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_TYPE=long\ 
long -DHAVE_STRUCT_STAT64=1 -DHAVE_OPEN64=1 -DHAVE_LSEEK64=1 -DHAVE_TYPE_OFF64_T=1
-DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -DHAVE_STRTOLL=1
-DHAVE_STRTOULL=1 -DHAVE_TMPNAM=1 -DHAVE_WAITPID=1 -DNO_GETWD=1 -DHAVE_LIMITS_H=1
-DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1
-DHAVE_TM_ZONE=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 -DHAVE_TM_GMTOFF=1
-DHAVE_TIMEZONE_VAR=1 -DHAVE_ST_BLKSIZE=1 -Dstrtod=fixstrtod -DSTDC_HEADERS=1
-DHAVE_SIGNED_CHAR=1 -DHAVE_LANGINFO=1 -DHAVE_SYS_IOCTL_H=1        -DTCL_SHLIB_EXT=\".so\" ./../compat/strstr.c
./../compat/strstr.c: In function `strstr':
./../compat/strstr.c:67: error: `NULL' undeclared (first use in this function)
./../compat/strstr.c:67: error: (Each undeclared identifier is reported only 
once
./../compat/strstr.c:67: error: for each function it appears in.)
make: *** [strstr.o] Error 1

Any other unmasked version fails with:
sh4-pc-linux-uclibc-gcc -pipe -shared -o libtcl8.4.so regcomp.o regexec.o 
regfree.o regerror.o tclAlloc.o tclAsync.o tclBasic.o tclBinary.o 
tclCkalloc.o tclClock.o tclCmdAH.o tclCmdIL.o tclCmdMZ.o tclCompCmds.o 
tclCompExpr.o tclCompile.o tclDate.o tclEncoding.o tclEnv.o tclEvent.o 
tclExecute.o tclFCmd.o tclFileName.o tclGet.o tclHash.o tclHistory.o 
tclIndexObj.o tclInterp.o tclIO.o tclIOCmd.o tclIOGT.o tclIOSock.o 
tclIOUtil.o tclLink.o tclListObj.o tclLiteral.o tclLoad.o tclMain.o 
(Continue reading)

Jakub Ladman | 4 Mar 19:32
Picon

Re: crossdev failed during building uclibc

Dne neděle 25 únor 2007 12:14 jozef maslik napsal(a):
> You can try atomic operations with ebuild:
> 1. ebuild
> /usr/local/portage/cross-mips-pc-linux-uclibc/uclibc-0.9.28.1.ebuild fetch
> unpack
>     (unpacking and patching sources is in unpack part of
> uclibc-0.9.28.1.ebuild) 2. modify sources
> 3. ebuild
> /usr/local/portage/cross-mips-pc-linux-uclibc/uclibc-0.9.28.1.ebuild
> compile install qmerge
>
> please check path to your .ebuild
> (/usr/local/portage/cross-mips-pc-linux-uclibc/uclibc-0.9.28.1.ebuild)
>

I have tried it, and it fails too. But some other error appears.

I thing it is very important, for sure it is one of headstones of gentoo 
embedded and it is notposible to left it uncorrected.

Jakub
Picon

Gentoo Embedded x86: virtual/libconv-0 bug ?

Hi I'm trying to build an Embedded Gentoo x86 (http://www.bulah.com/embedded-guide.html) on my system (Pentium 4 1,700GHz).
During the step n.2 I've received the following error after the command ./bootstrap.sh -p -v:
----
Calculating dependencies |!!! Cannot resolve a virtual package name to an ebuild.
!!! This is a bug, please report it. (virtual/libiconv-0)
---
You can find in attach the whole output of the bootstrap.sh (bootstrap_out.txt) command and the make.conf file.
Any idea?

Thank in advance

localhost scripts # ./bootstrap.sh -p -v

Gentoo Linux; http://www.gentoo.org/
Copyright 1999-2006 Gentoo Foundation; Distributed under the GPLv2
-------------------------------------------------------------------------------
  [[ (0/3) Locating packages ]]
 * Using baselayout : virtual/baselayout
 * Using portage    : >=sys-apps/portage-2.0.51.22
 * Using os-headers : virtual/os-headers
 * Using binutils   : sys-devel/binutils
 * Using gcc        : sys-devel/gcc
 * Using libc       : virtual/libc
 * Using texinfo    : sys-apps/texinfo
 * Using zlib       : sys-libs/zlib
 * Using ncurses    : sys-libs/ncurses
-------------------------------------------------------------------------------
  [[ (1/3) Configuring environment ]]
 * GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo"
 * PORTDIR="/usr/portage"
 * DISTDIR="/usr/portage/distfiles"
 * PKGDIR="/usr/portage/packages"
 * PORTAGE_TMPDIR="/var/tmp"
 * CFLAGS="-Os -pipe"
 * CHOST="i386-gentoo-linux-uclibc"
 * CXXFLAGS="-Os -pipe"
 * MAKEOPTS="-j2"
 * ACCEPT_KEYWORDS="x86"
 * FEATURES="autoaddcvs autoconfig ccache distlocks nodoc noinfo noman sandbox sfperms strict"
 * STAGE1_USE="uclibc"
-------------------------------------------------------------------------------
  [[ (2/3) Updating portage ]]
 * Executing: USE=-* build bootstrap  uclibc emerge --oneshot -p -v >=sys-apps/portage-2.0.51.22

Performing Global Updates: /usr/portage/profiles/updates/4Q-2002
(Could take a couple of minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  @='/var/db move'
  s='/var/db SLOT move' S='binary SLOT move' p='update /etc/portage/package.*'
..............................................................................

Performing Global Updates: /usr/portage/profiles/updates/1Q-2004
(Could take a couple of minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  @='/var/db move'
  s='/var/db SLOT move' S='binary SLOT move' p='update /etc/portage/package.*'
.........................................

Performing Global Updates: /usr/portage/profiles/updates/2Q-2004
(Could take a couple of minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  @='/var/db move'
  s='/var/db SLOT move' S='binary SLOT move' p='update /etc/portage/package.*'
................................................................................................................

Performing Global Updates: /usr/portage/profiles/updates/3Q-2004
(Could take a couple of minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  @='/var/db move'
  s='/var/db SLOT move' S='binary SLOT move' p='update /etc/portage/package.*'
..................................................................................................................................................................................................

Performing Global Updates: /usr/portage/profiles/updates/4Q-2004
(Could take a couple of minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  @='/var/db move'
  s='/var/db SLOT move' S='binary SLOT move' p='update /etc/portage/package.*'
.....................................................................................................................................................................................................................................................................

Performing Global Updates: /usr/portage/profiles/updates/1Q-2005
(Could take a couple of minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  @='/var/db move'
  s='/var/db SLOT move' S='binary SLOT move' p='update /etc/portage/package.*'
...........................................................................................................................................................................................................................................................

Performing Global Updates: /usr/portage/profiles/updates/2Q-2005
(Could take a couple of minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  @='/var/db move'
  s='/var/db SLOT move' S='binary SLOT move' p='update /etc/portage/package.*'
...........................................................................................................

Performing Global Updates: /usr/portage/profiles/updates/3Q-2005
(Could take a couple of minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  @='/var/db move'
  s='/var/db SLOT move' S='binary SLOT move' p='update /etc/portage/package.*'
...............................................................................

Performing Global Updates: /usr/portage/profiles/updates/4Q-2005
(Could take a couple of minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  @='/var/db move'
  s='/var/db SLOT move' S='binary SLOT move' p='update /etc/portage/package.*'
.......................................

Performing Global Updates: /usr/portage/profiles/updates/1Q-2006
(Could take a couple of minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  @='/var/db move'
  s='/var/db SLOT move' S='binary SLOT move' p='update /etc/portage/package.*'
...........................................

Performing Global Updates: /usr/portage/profiles/updates/2Q-2006
(Could take a couple of minutes if you have a lot of binary packages.)
  .='update pass'  *='binary update'  @='/var/db move'
  s='/var/db SLOT move' S='binary SLOT move' p='update /etc/portage/package.*'
...................................

These are the packages that I would merge, in order:

Calculating dependencies ...done!
[ebuild  N    ] sys-apps/sandbox-1.2.17  227 kB
[ebuild  N    ] app-misc/pax-utils-0.1.13  -caps 52 kB
[ebuild  N    ] dev-python/pycrypto-2.0.1-r5  -bindist -gmp -test 150 kB
[ebuild     U ] sys-apps/portage-2.1-r2 [2.0.51.19] +build -doc (-elibc_FreeBSD) -elibc_glibc
+elibc_uclibc* -linguas_pl (-selinux) -userland_Darwin +userland_GNU* 273 kB

Total size of downloads: 704 kB
-------------------------------------------------------------------------------
  [[ (3/3) Emerging packages ]]
 * Executing: emerge --oneshot -p -v virtual/os-headers sys-apps/texinfo sys-devel/binutils
sys-devel/gcc virtual/libc virtual/baselayout sys-libs/zlib

These are the packages that I would merge, in order:

Calculating dependencies |!!! Cannot resolve a virtual package name to an ebuild.
!!! This is a bug, please report it. (virtual/libiconv-0)
Attachment (make.conf): application/octet-stream, 274 bytes
Natanael Copa | 8 Mar 17:00
Picon
Gravatar

init.d scripts and bash

Hi,

Are there anybody more than me that use the gentoo init.d scripts
without using bash?

Most init.d scripts runs just fine with a small runscript wrapper. A few
needs patching to work, typically replacing:

  [[ expr || expr ]]

with:

  [[ expr ]] || [[ expr ]]

But sometimes arrays and such are used (very often its easy to work
around)

Are there any hope for setting a gentoo policy that says bash specific
things should be avoided if possible in init.d scripts?

Natanael Copa

Ned Ludd | 9 Mar 01:00
Picon
Favicon

Re: init.d scripts and bash

On Thu, 2007-03-08 at 17:00 +0100, Natanael Copa wrote:
> Hi,
> 
> Are there anybody more than me that use the gentoo init.d scripts
> without using bash?
> 
> Most init.d scripts runs just fine with a small runscript wrapper. A few
> needs patching to work, typically replacing:
> 
>   [[ expr || expr ]]
> 
> with:
> 
>   [[ expr ]] || [[ expr ]]
> 
> But sometimes arrays and such are used (very often its easy to work
> around)
> 
> Are there any hope for setting a gentoo policy that says bash specific
> things should be avoided if possible in init.d scripts?

That is a goal with baselayout-2. I'd be interested if we started a
tracker bug for such things. I think policy might be a bit far 
reaching at this point. But it's for sure a worthwhile goal.

--

-- 
Ned Ludd <solar@...>
Gentoo Linux

Ned Ludd | 9 Mar 10:08
Picon
Favicon

Re: init.d scripts and bash

On Fri, 2007-03-09 at 07:39 +0000, Roy Marples wrote:
> On Thu, 08 Mar 2007 16:00:50 -0800
> Ned Ludd <solar@...> wrote:
> 
> > On Thu, 2007-03-08 at 17:00 +0100, Natanael Copa wrote:
> > > Hi,
> > > 
> > > Are there anybody more than me that use the gentoo init.d scripts
> > > without using bash?
> > > 
> > > Most init.d scripts runs just fine with a small runscript wrapper.
> > > A few needs patching to work, typically replacing:
> > > 
> > >   [[ expr || expr ]]
> > > 
> > > with:
> > > 
> > >   [[ expr ]] || [[ expr ]]
> 
> Well, not many shells support that either.
> [ expr -o expr ]
> or
> [ expr ] || [ expr]
> should work across the board.
> 
> > > But sometimes arrays and such are used (very often its easy to work
> > > around)
> 
> Yes it's easy to work around.
> Infact we had a discussion about this on -dev and posted the below
> function
> 
> _get_array() {
>     if [ -n "${BASH}" ] ; then
>         case "$(declare -p "$1" 2>/dev/null)" in
>             "declare -a "*)
>                 echo "set -- \"\${$1[@]}\""
>                 return
>                 ;; 
>         esac
>     fi
> 
>     echo "eval set -- \"\$$1\""
> }
> 
> eval "$(_get_array "config_${IFVAR}")"
> for cmd in "$@" ; do
>  ...
> done
> 
> Which means we can support bash arrays AND a non bash array
> config_eth0=( "one" "t w o" "three" )
> and
> config_eth0="'one' 't w o' 'three'"
> 
> > > 
> > > Are there any hope for setting a gentoo policy that says bash
> > > specific things should be avoided if possible in init.d scripts?
> 
> There's no such policy. Our policy has always been init scripts should
> be parseable by a shell. The shell in question has always been bash
> because
> 1) baselayout-1 requires it
> 2) bash forces itself to be /bin/sh anyway
> 
> The lastest bash in the tree no longer enforces it's /bin/sh - instead
> it only creates the link if it does not exist, allowing any shell to be
> used. Yay!

Sweet ass sweet...

I'm sure it will take time to get 99% of the misc remaining bash init
scripts converted over as we find them. If we mostly target server stuff
for now we will be fine..

> > That is a goal with baselayout-2. I'd be interested if we started a
> > tracker bug for such things. I think policy might be a bit far 
> > reaching at this point. But it's for sure a worthwhile goal.
>  
> baselayout-2 is pure C (except for the init scripts themselves) and is
> nearing the final stage of development before it enters the tree. It
> currently works with any shell in portage except for zsh and ksh. It
> can work with bb provided that some things are disabled.

Gimme bugs.. I need #'s if I'm going to work toward solving them.
I'd rather not disable vs update bb to conform with what you need.
Removing our s-s-d for us is very undesirable as long as we have an
alternative to the current bloated s-s-d. So please give us bugs 
to work towards solving etc..

I think Natanael might also become one of your best testers and bug
reporters. He has been very helpful in the past and I'm sure he will
continue to be in the future.

> 
> I'm making it a policy that all init scripts on my local machines have
> already been changed. Naughty me. I've filed bugs for a few other
> scripts too. 

Natanael please search bugzilla for scripts you have noticed in which
Roy has not already filed bugs. If no bug exists please file one
(patches attached if you can)

> So for a desktop it should work off the bat. Not sure if
> I'll put baselayout-2 on my server right now as it's headless and it's a
> PITA to get a head to it.
> 
> Once baselayout-2 hits portage then we can have a tracker bug.
> 
> Thanks
> 
> Roy
> 
--

-- 
Ned Ludd <solar@...>
Gentoo Linux

Natanael Copa | 9 Mar 11:06
Picon
Gravatar

Re: init.d scripts and bash

On Fri, 2007-03-09 at 01:08 -0800, Ned Ludd wrote:
> On Fri, 2007-03-09 at 07:39 +0000, Roy Marples wrote:
> > On Thu, 08 Mar 2007 16:00:50 -0800
> > Ned Ludd <solar@...> wrote:
> > 
> > > On Thu, 2007-03-08 at 17:00 +0100, Natanael Copa wrote:
> > > > Hi,
> > > > 
> > > > Are there anybody more than me that use the gentoo init.d scripts
> > > > without using bash?
> > > > 
> > > > Most init.d scripts runs just fine with a small runscript wrapper.
> > > > A few needs patching to work, typically replacing:
> > > > 
> > > >   [[ expr || expr ]]
> > > > 
> > > > with:
> > > > 
> > > >   [[ expr ]] || [[ expr ]]
> > 
> > Well, not many shells support that either.
> > [ expr -o expr ]
> > or
> > [ expr ] || [ expr]
> > should work across the board.
> > 
> > > > But sometimes arrays and such are used (very often its easy to work
> > > > around)
> > 
> > Yes it's easy to work around.
> > Infact we had a discussion about this on -dev and posted the below
> > function
> > 
> > _get_array() {
> >     if [ -n "${BASH}" ] ; then
> >         case "$(declare -p "$1" 2>/dev/null)" in
> >             "declare -a "*)
> >                 echo "set -- \"\${$1[@]}\""
> >                 return
> >                 ;; 
> >         esac
> >     fi
> > 
> >     echo "eval set -- \"\$$1\""
> > }
> > 
> > eval "$(_get_array "config_${IFVAR}")"
> > for cmd in "$@" ; do
> >  ...
> > done
> > 
> > Which means we can support bash arrays AND a non bash array
> > config_eth0=( "one" "t w o" "three" )
> > and
> > config_eth0="'one' 't w o' 'three'"
> > 
> > > > 
> > > > Are there any hope for setting a gentoo policy that says bash
> > > > specific things should be avoided if possible in init.d scripts?
> > 
> > There's no such policy. Our policy has always been init scripts should
> > be parseable by a shell. The shell in question has always been bash
> > because
> > 1) baselayout-1 requires it
> > 2) bash forces itself to be /bin/sh anyway
> > 
> > The lastest bash in the tree no longer enforces it's /bin/sh - instead
> > it only creates the link if it does not exist, allowing any shell to be
> > used. Yay!
> 
> 
> Sweet ass sweet...
> 
> I'm sure it will take time to get 99% of the misc remaining bash init
> scripts converted over as we find them. If we mostly target server stuff
> for now we will be fine..
> 
> > > That is a goal with baselayout-2. I'd be interested if we started a
> > > tracker bug for such things. I think policy might be a bit far 
> > > reaching at this point. But it's for sure a worthwhile goal.
> >  
> > baselayout-2 is pure C (except for the init scripts themselves) and is
> > nearing the final stage of development before it enters the tree. It
> > currently works with any shell in portage except for zsh and ksh. It
> > can work with bb provided that some things are disabled.

Sweeeet!!!!

How can I getting envolved in the baselayout-2 development?

> Gimme bugs.. I need #'s if I'm going to work toward solving them.

I have a bunch of of them and patches too. I will start reporting them.

> I'd rather not disable vs update bb to conform with what you need.
> Removing our s-s-d for us is very undesirable as long as we have an
> alternative to the current bloated s-s-d. So please give us bugs 
> to work towards solving etc..

I'm not sure I understood. Bugs where use of s-s-d dont work with
busybox s-s-d? They are few. I patched busybox s-s-d to support --chuid
user:group and the problems I had went away.

I think there is still need to fix the verbosity of busybox s-s-d. I
will look at it some day.

> I think Natanael might also become one of your best testers and bug
> reporters. He has been very helpful in the past and I'm sure he will
> continue to be in the future.

Looks like I will :-) My alpinelinux project (distro based on gentoo) is
going pretty well.

> > I'm making it a policy that all init scripts on my local machines have
> > already been changed. Naughty me. I've filed bugs for a few other
> > scripts too. 
> 
> Natanael please search bugzilla for scripts you have noticed in which
> Roy has not already filed bugs. If no bug exists please file one
> (patches attached if you can)

I have a bunch of patches. Will do!

> > So for a desktop it should work off the bat. Not sure if
> > I'll put baselayout-2 on my server right now as it's headless and it's a
> > PITA to get a head to it.
> > 
> > Once baselayout-2 hits portage then we can have a tracker bug.
> > 
> > Thanks
> > 
> > Roy
> > 
> -- 
> Ned Ludd <solar@...>
> Gentoo Linux
> 


Gmane