devil-linux-develop Mailing List for Devil-Linux (Page 22)

This do not change the current way to compile and generate the iso?

regards

On Tue, Jan 5, 2010 at 5:00 PM, Heiko Zuerker <he...@zu...> wrote:

>  Hey,
>
>
>
> I removed the insserv stuff for handling the script dependencies.
>
> I moved everything into Makefiles, which reside in the root of the build
> directory.
>
>
>
> Since I got a cold, I don’t feel like too many words. So here the
> copy’n’paste from the changelog:
>
>
>
> - closed bug #18 - build system - replace insserv
>
>   - make targets "prepare build install iso" now use makefiles
> automatically
>
>   - new make target 'all' executes 'prepare build install iso'
>
>   - remove 'makefile' and 'buildorder' targets
>
>   - build order is now only controlled through the makefiles
>
>
>
> Regards
>
>   Heiko Zuerker
>
>   http://www.devil-linux.org
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>
>


-- 
WARPTROSSE {The knowledge of a man belongs to all the humanity}

Hey,

 

I removed the insserv stuff for handling the script dependencies.

I moved everything into Makefiles, which reside in the root of the build
directory.

 

Since I got a cold, I don't feel like too many words. So here the
copy'n'paste from the changelog:

 

- closed bug #18 - build system - replace insserv

  - make targets "prepare build install iso" now use makefiles automatically

  - new make target 'all' executes 'prepare build install iso'

  - remove 'makefile' and 'buildorder' targets

  - build order is now only controlled through the makefiles

 

Regards

  Heiko Zuerker

  http://www.devil-linux.org

 

Heiko Zuerker wrote:
> Are you starting over with a fresh lfssystem and do a 'make mrproper' ?

After problems next time I always start with fresh lfssystem.

As You know, in lfsystem/root/.bash_history is prepared command:
	make mrproper unpack prepare makefile dist
I'm so lazy, so after chrooting I'm always using up key four times and Return ;-)

But I don't checked one suspicion. I'm always before update_src copying from 
side contents of lfssystem/build/src tree. Theoretically update_src should 
update out-of-date source files. But once it didn't.

So now I run update_src with empty lfssystem/build/src tree and again run 
build process.

Best regards

Andrzej Odyniec

Quoting Andrzej Odyniec <an...@ma...>:

> Heiko Zuerker ask:
>> I just had another thought, is the loop module loaded?
>
> I tried again. I compilled without any my modification too.
> There is no difference.
> On real machine as on virtual one, there is no success.
> loop module is loaded but there are no loop devices in /dev directory
> Last compilation (from new clean environment) I did last night.
>
> So there are problems with loop module update?
>
> I will read docs in loop module src and compilation log

yeah this is weird.
Are you starting over with a fresh lfssystem and do a 'make mrproper' ?

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Heiko Zuerker ask:
> I just had another thought, is the loop module loaded?

I tried again. I compilled without any my modification too.
There is no difference.
On real machine as on virtual one, there is no success.
loop module is loaded but there are no loop devices in /dev directory
Last compilation (from new clean environment) I did last night.

So there are problems with loop module update?

I will read docs in loop module src and compilation log

Regards

-- 
Andrzej Odyniec

Patch is checked into CVS.
Thanks for sending it in.

Heiko

> -----Original Message-----
> From: Roland Pabel [mailto:rp...@gm...]
> Sent: Friday, December 25, 2009 12:30 PM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] ipv6/postfix in 1.4RC2
> 
> On Friday 25 December 2009, Heiko Zuerker wrote:
> > Can you create a bug report (well the postfix is a feature request)
> in
> > Mantis, so we don't lose track of it?
> > http://www.devil-linux.org/support/bugs.php
> ok, you now have two new feature requests and a bug report (ifconfig
> not knowing about ipv6 is a bug independent of the networt scripts
> using it or
> not)
> 
> > Please provide a patch for the postfix one.
> See the attached files. I changed the init script and tested that on my
> router, it ran fine. Now the database file has to be generated
> somewhere, I patched the postfix build script to create it when
> installing the package.
> Somebody needs to test it, I cannot run a complete build today (or
> probably this week), but it's just one line...
> cu
> Rolnad

I just had another thought, is the loop module loaded?

Heiko

> -----Original Message-----
> From: Andrzej Odyniec [mailto:an...@ma...]
> Sent: Wednesday, December 30, 2009 10:27 AM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] DL compiled 28 dec kernel 2.6.31.9
> booting problem
> 
> Heiko Zuerker wrote:
> > Quoting Heiko Zuerker <he...@zu...>:
> >>I updated the loop-aes package and some other tools, maybe it's
> >>related to that.
> >>I'll check if my last test compile boots.
> > My version I compiled last night from the CVS sources started fine.
> > Make sure you got all the latest packages and update from CVS.
> 
> I updated again. I changed according to your changes in my testing
> scripts and
>   corrected "# Required-Start: ".
> 
> I did two compilation: for router and for VoIP (with Asterisk but
> without grsec).
> 
> In start phase I tried with old configuration and with configuration
> conversion.
> 
> There is no difference and I have not loop devices, so I can do not do
> run
> from ram or from usb. Maybe I need special Config settings?
> 
> For test on VM I need now another IDE disk with configuration on it,
> beacause
> now BusLogic is not supported in initrd as LSI Logic (only this two
> SCSII are
> supported in VMware Wks).
> 
> > I just checked in a couple of other changes. Let me know if the
> > 'buildorder' run is faster.
> 
> It seems, yes. Should be after Your changes. But exactly I don't know.
> I never
> meassured this phase time.
> 
> Now I try make another compilation from clean state without any changes
> to
> config files, as I'm usually doing.
> 
> Regards
> 
> Andrzej Odyniec
> 
> -----------------------------------------------------------------------
> -------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

> -----Original Message-----
> From: Andrzej Odyniec [mailto:an...@ma...]
> Sent: Wednesday, December 30, 2009 10:27 AM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] DL compiled 28 dec kernel 2.6.31.9
> booting problem
> 
> Heiko Zuerker wrote:
> > Quoting Heiko Zuerker <he...@zu...>:
> >>I updated the loop-aes package and some other tools, maybe it's
> >>related to that.
> >>I'll check if my last test compile boots.
> > My version I compiled last night from the CVS sources started fine.
> > Make sure you got all the latest packages and update from CVS.
> 
> I updated again. I changed according to your changes in my testing
> scripts and
>   corrected "# Required-Start: ".
> 
> I did two compilation: for router and for VoIP (with Asterisk but
> without grsec).
> 
> In start phase I tried with old configuration and with configuration
> conversion.
> 
> There is no difference and I have not loop devices, so I can do not do
> run
> from ram or from usb. Maybe I need special Config settings?
> 
> For test on VM I need now another IDE disk with configuration on it,
> beacause
> now BusLogic is not supported in initrd as LSI Logic (only this two
> SCSII are
> supported in VMware Wks).
> 
> > I just checked in a couple of other changes. Let me know if the
> > 'buildorder' run is faster.
> 
> It seems, yes. Should be after Your changes. But exactly I don't know.
> I never
> meassured this phase time.
> 
> Now I try make another compilation from clean state without any changes
> to
> config files, as I'm usually doing.

Yes let's start with the 'default' config with no modifications.

Heiko

Heiko Zuerker wrote:
> Quoting Heiko Zuerker <he...@zu...>:
>>I updated the loop-aes package and some other tools, maybe it's
>>related to that.
>>I'll check if my last test compile boots.
> My version I compiled last night from the CVS sources started fine.
> Make sure you got all the latest packages and update from CVS.

I updated again. I changed according to your changes in my testing scripts and 
  corrected "# Required-Start: ".

I did two compilation: for router and for VoIP (with Asterisk but without grsec).

In start phase I tried with old configuration and with configuration conversion.

There is no difference and I have not loop devices, so I can do not do run 
from ram or from usb. Maybe I need special Config settings?

For test on VM I need now another IDE disk with configuration on it, beacause 
now BusLogic is not supported in initrd as LSI Logic (only this two SCSII are 
supported in VMware Wks).

> I just checked in a couple of other changes. Let me know if the  
> 'buildorder' run is faster.

It seems, yes. Should be after Your changes. But exactly I don't know. I never 
meassured this phase time.

Now I try make another compilation from clean state without any changes to 
config files, as I'm usually doing.

Regards

Andrzej Odyniec

Quoting Heiko Zuerker <he...@zu...>:

> Quoting Andrzej Odyniec <an...@ma...>:
>
>> Hi,
>>
>> I compilled as usually, starting from clean system.
>>
>> There is no loop devices, so run from ram is not working and boot from USB
>> device too. After boot from CD there is ofcourse no possibility to
>> install-on-usb old image.
>
> I updated the loop-aes package and some other tools, maybe it's
> related to that.
> I'll check if my last test compile boots.

My version I compiled last night from the CVS sources started fine.
Make sure you got all the latest packages and update from CVS.

I just checked in a couple of other changes. Let me know if the  
'buildorder' run is faster.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Quoting Andrzej Odyniec <an...@ma...>:

> Hi,
>
> I compilled as usually, starting from clean system.
>
> There is no loop devices, so run from ram is not working and boot from USB
> device too. After boot from CD there is ofcourse no possibility to
> install-on-usb old image.

I updated the loop-aes package and some other tools, maybe it's  
related to that.
I'll check if my last test compile boots.

-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Hi,

I compilled as usually, starting from clean system.

There is no loop devices, so run from ram is not working and boot from USB 
device too. After boot from CD there is ofcourse no possibility to 
install-on-usb old image.

Regards

Andrzej Odyniec

Hello,

On 12/28/2009 06:44 PM, warptrosse wrote:
...
> 
> as I'm using Fedora 12, the solution for
> 
> *as: error while loading shared libraries: /usr/lib/libz.so.1: cannot
> restore segment prot after reloc: Permission denied*
> 
> is
> 
> */usr/sbin/setenforce 0*
> 
...

Actually we suggest disabling SELinux as the first step of DL compilation :)

Serge

Hi all!, when trying to compile Linux-PAM from last svn revision, I got the
following error:

============================================================================================
executing libungif with option build (in /build/tmp/libungif-4.1.4)

executing libusb with option build (in /build/tmp/libusb-0.1.12)

executing lzo with option build (in /build/tmp/lzo-2.03)

executing mhash with option build (in /build/tmp/mhash-0.9.9)

executing mktemp with option build (in /build/tmp/mktemp-1.5)

executing ncurses with option build (in /build/tmp/ncurses-5.6)

executing pax-utils with option build (in /build/tmp/pax-utils-0.1.15)

executing paxctl with option build (in /build/tmp/paxctl-0.5)

executing pcre with option build (in /build/tmp/pcre-7.9)

executing popt with option build (in /build/tmp/popt-1.7)

executing readline with option build (in /build/tmp/readline-5.2)

executing tcp_wrappers with option build (in /build/tmp/tcp_wrappers_7.6)

executing uClibc with option build (in /build/tmp/uClibc-0.9.19)

executing which with option build (in /build/tmp/which-2.14)

executing zlib with option build (in /build/tmp/zlib-1.2.3)

executing Linux-PAM with option build (in /build/tmp/Linux-PAM-1.0.4)
ERROR
/build/scripts/Linux-PAM build failed
check log file /build/tmp/LOGS/build/Linux-PAM for details
make: *** [build] Error 1
============================================================================================

============================================================================================
root:/build# cat /build/tmp/LOGS/build/Linux-PAM
configure: WARNING: unrecognized options: --enable-static-libpam,
--with-cracklib
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i686-pc-linux-gnuoldld
checking host system type... i686-pc-linux-gnuoldld
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name...
configure: error: in `/build/tmp/Linux-PAM-1.0.4':
configure: error: C compiler cannot create executables
See `config.log' for more details.
make[1]: Entering directory `/build/tmp/Linux-PAM-1.0.4'
make[1]: *** No targets specified and no makefile found.  Stop.
make[1]: Leaving directory `/build/tmp/Linux-PAM-1.0.4'
============================================================================================

============================================================================================
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.63.  Invocation command line was

  $ ./configure --enable-static-libpam --with-mailspool=/var/mail
--enable-read-both-confs --sysconfdir=/etc --with-cracklib
--mandir=/usr/share/man --sbindir=/lib/security
--enable-securedir=/lib/security --disable-nls

## --------- ##
## Platform. ##
## --------- ##

hostname = etacarinae
uname -m = i686
uname -r = 2.6.31.9-174.fc12.i686
uname -s = Linux
uname -v = #1 SMP Mon Dec 21 05:33:33 UTC 2009

/usr/bin/uname -p = unknown
/bin/uname -X     =

/bin/arch              = i686
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /bin
PATH: /usr/bin
PATH: /sbin
PATH: /usr/sbin
PATH: /usr/local/bin
PATH: /tools/bin


## ----------- ##
## Core tests. ##
## ----------- ##

configure:2198: checking for a BSD-compatible install
configure:2266: result: /usr/bin/install -c
configure:2277: checking whether build environment is sane
configure:2320: result: yes
configure:2345: checking for a thread-safe mkdir -p
configure:2384: result: /bin/mkdir -p
configure:2397: checking for gawk
configure:2413: found /usr/bin/gawk
configure:2424: result: gawk
configure:2435: checking whether make sets $(MAKE)
configure:2457: result: yes
configure:2650: checking build system type
configure:2668: result: i686-pc-linux-gnuoldld
configure:2690: checking host system type
configure:2705: result: i686-pc-linux-gnuoldld
configure:2920: checking for style of include used by make
configure:2948: result: GNU
configure:3018: checking for gcc
configure:3034: found /usr/bin/gcc
configure:3045: result: gcc
configure:3277: checking for C compiler version
configure:3285: gcc --version >&5
gcc (GCC) 4.1.2
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:3289: $? = 0
configure:3296: gcc -v >&5
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.2/configure --prefix=/usr --localstatedir=/var
--enable-shared --enable-CONFIG_SHELL=/bin/bash --enable-threads=posix
--libexecdir=/usr/lib --enable-__cxa_atexit --enable-clocale=gnu
--enable-languages=c,c++,objc --disable-nls --with-gnu-ld --disable-werror
i686-pc-linux-gnu
Thread model: posix
gcc version 4.1.2
configure:3300: $? = 0
configure:3307: gcc -V >&5
gcc: '-V' option must have argument
configure:3311: $? = 1
configure:3334: checking for C compiler default output file name
configure:3356: gcc -mtune=i686 -march=i686   conftest.c  >&5
as: error while loading shared libraries: /usr/lib/libz.so.1: cannot restore
segment prot after reloc: Permission denied
configure:3360: $? = 1
configure:3398: result:
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "Linux-PAM"
| #define VERSION "1.0.4"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3404: error: in `/build/tmp/Linux-PAM-1.0.4':
configure:3407: error: C compiler cannot create executables
See `config.log' for more details.

## ---------------- ##
## Cache variables. ##
## ---------------- ##

ac_cv_build=i686-pc-linux-gnuoldld
ac_cv_env_CC_set=
ac_cv_env_CC_value=
ac_cv_env_CFLAGS_set=set
ac_cv_env_CFLAGS_value='-mtune=i686 -march=i686'
ac_cv_env_CPPFLAGS_set=
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=
ac_cv_env_CPP_value=
ac_cv_env_LDFLAGS_set=
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBS_set=
ac_cv_env_LIBS_value=
ac_cv_env_YACC_set=
ac_cv_env_YACC_value=
ac_cv_env_YFLAGS_set=
ac_cv_env_YFLAGS_value=
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_host=i686-pc-linux-gnuoldld
ac_cv_path_install='/usr/bin/install -c'
ac_cv_path_mkdir=/bin/mkdir
ac_cv_prog_AWK=gawk
ac_cv_prog_ac_ct_CC=gcc
ac_cv_prog_make_make_set=yes

## ----------------- ##
## Output variables. ##
## ----------------- ##

ACLOCAL='${SHELL} /build/tmp/Linux-PAM-1.0.4/missing --run aclocal-1.10'
AMDEPBACKSLASH='\'
AMDEP_FALSE='#'
AMDEP_TRUE=''
AMTAR='${SHELL} /build/tmp/Linux-PAM-1.0.4/missing --run tar'
AR=''
AUTOCONF='${SHELL} /build/tmp/Linux-PAM-1.0.4/missing --run autoconf'
AUTOHEADER='${SHELL} /build/tmp/Linux-PAM-1.0.4/missing --run autoheader'
AUTOMAKE='${SHELL} /build/tmp/Linux-PAM-1.0.4/missing --run automake-1.10'
AWK='gawk'
BROWSER=''
CC='gcc'
CCDEPMODE=''
CFLAGS='-mtune=i686 -march=i686'
CPP=''
CPPFLAGS=''
CYGPATH_W='echo'
DEFS=''
DEPDIR='.deps'
DSYMUTIL=''
DUMPBIN=''
ECHO_C=''
ECHO_N='-n'
ECHO_T=''
EGREP=''
ENABLE_GENERATE_PDF_FALSE=''
ENABLE_GENERATE_PDF_TRUE=''
ENABLE_REGENERATE_MAN_FALSE=''
ENABLE_REGENERATE_MAN_TRUE=''
EXEEXT=''
FGREP=''
FO2PDF=''
GMSGFMT=''
GMSGFMT_015=''
GREP=''
HAVE_AUDIT_TTY_STATUS_FALSE=''
HAVE_AUDIT_TTY_STATUS_TRUE=''
HAVE_KEY_MANAGEMENT=''
HAVE_KEY_MANAGEMENT_FALSE=''
HAVE_KEY_MANAGEMENT_TRUE=''
HAVE_LIBCRACK_FALSE=''
HAVE_LIBCRACK_TRUE=''
HAVE_LIBDB_FALSE=''
HAVE_LIBDB_TRUE=''
HAVE_LIBSELINUX_FALSE=''
HAVE_LIBSELINUX_TRUE=''
HAVE_UNSHARE_FALSE=''
HAVE_UNSHARE_TRUE=''
HAVE_VERSIONING_FALSE=''
HAVE_VERSIONING_TRUE=''
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
INSTALL_STRIP_PROGRAM='$(install_sh) -c -s'
INTLLIBS=''
INTL_MACOSX_LIBS=''
LD=''
LDFLAGS=''
LEX=''
LEXLIB=''
LEX_OUTPUT_ROOT=''
LIBAUDIT=''
LIBCRACK=''
LIBCRYPT=''
LIBDB=''
LIBDL=''
LIBICONV=''
LIBINTL=''
LIBNSL=''
LIBOBJS=''
LIBPRELUDE_CFLAGS=''
LIBPRELUDE_CONFIG=''
LIBPRELUDE_CONFIG_PREFIX=''
LIBPRELUDE_LDFLAGS=''
LIBPRELUDE_LIBS=''
LIBPRELUDE_PREFIX=''
LIBPRELUDE_PTHREAD_CFLAGS=''
LIBS=''
LIBSELINUX=''
LIBTOOL=''
LIPO=''
LN_S=''
LTLIBICONV=''
LTLIBINTL=''
LTLIBOBJS=''
MAKEINFO='${SHELL} /build/tmp/Linux-PAM-1.0.4/missing --run makeinfo'
MKDIR_P='/bin/mkdir -p'
MSGFMT=''
MSGFMT_015=''
MSGMERGE=''
NM=''
NMEDIT=''
OBJDUMP=''
OBJEXT=''
OTOOL64=''
OTOOL=''
PACKAGE='Linux-PAM'
PACKAGE_BUGREPORT=''
PACKAGE_NAME=''
PACKAGE_STRING=''
PACKAGE_TARNAME=''
PACKAGE_VERSION=''
PAM_READ_BOTH_CONFS=''
PATH_SEPARATOR=':'
PIE_CFLAGS=''
PIE_LDFLAGS=''
POSUB=''
RANLIB=''
SCONFIGDIR=''
SECUREDIR=''
SED=''
SET_MAKE=''
SHELL='/bin/sh'
STATIC_MODULES_FALSE=''
STATIC_MODULES_TRUE='#'
STRIP=''
USE_NLS=''
VERSION='1.0.4'
WITH_DEBUG=''
WITH_PAMLOCKING=''
XGETTEXT=''
XGETTEXT_015=''
XMLCATALOG=''
XMLLINT=''
XML_CATALOG_FILE=''
XSLTPROC=''
YACC=''
YFLAGS=''
ac_ct_CC='gcc'
ac_ct_DUMPBIN=''
am__fastdepCC_FALSE=''
am__fastdepCC_TRUE=''
am__include='include'
am__isrc=''
am__leading_dot='.'
am__quote=''
am__tar='${AMTAR} chof - "$$tardir"'
am__untar='${AMTAR} xf -'
bindir='${exec_prefix}/bin'
build='i686-pc-linux-gnuoldld'
build_alias=''
build_cpu='i686'
build_os='linux-gnuoldld'
build_vendor='pc'
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datarootdir}/doc/${PACKAGE}'
dvidir='${docdir}'
exec_prefix='NONE'
host='i686-pc-linux-gnuoldld'
host_alias=''
host_cpu='i686'
host_os='linux-gnuoldld'
host_vendor='pc'
htmldir='${docdir}'
includedir='/usr/include/security'
infodir='${datarootdir}/info'
install_sh='$(SHELL) /build/tmp/Linux-PAM-1.0.4/install-sh'
libc_cv_fpie=''
libdir='/lib'
libexecdir='${exec_prefix}/libexec'
localedir='${datarootdir}/locale'
localstatedir='/var'
lt_ECHO='echo'
mandir='/usr/share/man'
mkdir_p='/bin/mkdir -p'
oldincludedir='/usr/include'
pam_cv_ld_as_needed=''
pam_xauth_path=''
pdfdir='${docdir}'
prefix='/usr'
program_transform_name='s,x,x,'
psdir='${docdir}'
sbindir='/lib/security'
sharedstatedir='${prefix}/com'
sysconfdir='/etc'
target_alias=''

## ----------- ##
## confdefs.h. ##
## ----------- ##

#define PACKAGE_NAME ""
#define PACKAGE_TARNAME ""
#define PACKAGE_VERSION ""
#define PACKAGE_STRING ""
#define PACKAGE_BUGREPORT ""
#define PACKAGE "Linux-PAM"
#define VERSION "1.0.4"

configure: exit 77
============================================================================================


as I'm using Fedora 12, the solution for

*as: error while loading shared libraries: /usr/lib/libz.so.1: cannot
restore segment prot after reloc: Permission denied*

is

*/usr/sbin/setenforce 0*


regards

-- 
WARPTROSSE {The knowledge of a man belongs to all the humanity}

>> I see you are using a gmail account.
>> That is the expected behavior for gmail:
>> http://mail.google.com/support/bin/answer.py?hl=en&answer=6588
> thanks, I didn't know that...

A lot of people are confused by that behavior, including myself when I
first started using gmail for mailing lists a long time ago.  :-)

Another way to tell if your message made it to the list, is to check
the mailing list archives online and see if your message is there.

Just click the link on the bottom of each message, then click the
link:  "Devil-linux-develop Archives" and look for your email.

 - BS

On Monday 28 December 2009, Bruce Smith wrote:
> > I never got my reply with the attached postfix patches back over the
> > mailinglist, did someone get it or must I send it again?
>
> Your message came through on the list fine.
>
> I see you are using a gmail account.
> That is the expected behavior for gmail:
> http://mail.google.com/support/bin/answer.py?hl=en&answer=6588
thanks, I didn't know that...
Roland

> I never got my reply with the attached postfix patches back over the
> mailinglist, did someone get it or must I send it again?

Your message came through on the list fine.

I see you are using a gmail account.
That is the expected behavior for gmail:
http://mail.google.com/support/bin/answer.py?hl=en&answer=6588

 - BS

On Friday 25 December 2009, Heiko Zuerker wrote:
Hi,
I never got my reply with the attached postfix patches back over the 
mailinglist, did someone get it or must I send it again?
cu
Roland

On Friday 25 December 2009, Heiko Zuerker wrote:
> Can you create a bug report (well the postfix is a feature request) in
> Mantis, so we don't lose track of it?
> http://www.devil-linux.org/support/bugs.php
ok, you now have two new feature requests and a bug report (ifconfig not 
knowing about ipv6 is a bug independent of the networt scripts using it or 
not)

> Please provide a patch for the postfix one.
See the attached files. I changed the init script and tested that on my 
router, it ran fine. Now the database file has to be generated somewhere, I 
patched the postfix build script to create it when installing the package. 
Somebody needs to test it, I cannot run a complete build today (or probably 
this week), but it's just one line...
cu
Rolnad

Can you create a bug report (well the postfix is a feature request) in
Mantis, so we don't lose track of it?
http://www.devil-linux.org/support/bugs.php

Please provide a patch for the postfix one.

Thanks
 Heiko

> -----Original Message-----
> From: Roland Pabel [mailto:rp...@gm...]
> Sent: Friday, December 25, 2009 7:57 AM
> To: dev...@li...
> Subject: [Devil-linux-develop] ipv6/postfix in 1.4RC2
> 
> Hi,
> after running a 1.2.x version for over a year and a half, I finally
> switched to 1.4 (first RC1 a few weeks ago, now RC2) and I must say
> it's running great!
> I'm just having two suggestions:
> It looks like IPv6 is still disabled in net-tools, since ifconfig
> doesn't show me my IPv6 addresses. Consequently, static IPv6 addresses
> set in sysconfig/nic/ifcfg-eth0 cannot be setup, ifconfig gives me an
> error message like ifconfig eth0 inet6 add ...
> inet6: Unknown host
> but "ip -6 addr add ..." works fine. Since, as far as I understand it,
> "ip" is supposed to supersede "ifconfig", I made a patch that exchanges
> all "ifconfig" command in /etc/init.d/network to "ip" commands. It was
> all straightforward, except for the "ifconfig $DEVICE $IP $BCAST $NMASK
> up"
> command, which I separated into the "link set up" and the address
> setting part (couldn't find a line which does both at the same time). I
> copied my file to my router and rebooted, everything was fine as
> before...
> Secondly, my postfix has a few more databases which should get
> initialized with postmap whenever postfix restarts. The list is
> currently handled in the variable DBFILES in the postfix init script
> itself. That means I have to change the init.d script which is then
> save to etc-mods.tar.bz2 . I think it would be better to either move
> DBFILES to sysconfig/config, or maybe put the names all into a file,
> say /etc/postfix/dbfiles, and have that file read in and executed
> postmap upon each entry... I can make a patch if there are no
> objections...
> cu
> Roland

Hi,
after running a 1.2.x version for over a year and a half, I finally switched 
to 1.4 (first RC1 a few weeks ago, now RC2) and I must say it's running 
great!
I'm just having two suggestions:
It looks like IPv6 is still disabled in net-tools, since ifconfig doesn't show 
me my IPv6 addresses. Consequently, static IPv6 addresses set in 
sysconfig/nic/ifcfg-eth0 cannot be setup, ifconfig gives me an error message 
like
ifconfig eth0 inet6 add ...
inet6: Unknown host
but "ip -6 addr add ..." works fine. Since, as far as I understand it, "ip" is 
supposed to supersede "ifconfig", I made a patch that exchanges 
all "ifconfig" command in /etc/init.d/network to "ip" commands. It was all 
straightforward, except for the "ifconfig $DEVICE $IP $BCAST $NMASK up" 
command, which I separated into the "link set up" and the address setting 
part (couldn't find a line which does both at the same time). I copied my 
file to my router and rebooted, everything was fine as before...
Secondly, my postfix has a few more databases which should get initialized 
with postmap whenever postfix restarts. The list is currently handled in the 
variable DBFILES in the postfix init script itself. That means I have to 
change the init.d script which is then save to etc-mods.tar.bz2 . I think it 
would be better to either move DBFILES to sysconfig/config, or maybe put the 
names all into a file, say /etc/postfix/dbfiles, and have that file read in 
and executed postmap upon each entry... I can make a patch if there are no 
objections...
cu
Roland

Hello DL Community

 

the second Release Candidate of Devil-Linux 1.4 is available for download.

 

All known bugs of RC1 have been resolved, in addition to many software
updates.

 

Please report any problems on hour mailinglist.

 

Regards

  Heiko Zuerker

  http://www.devil-linux.org

 

Hi,

I, Andrzej Odyniec wrote:
> Shorewall configuration was this same, but probably interpretation has changed. 
> Maybe now is used source route (or other new) criterium?
> 
> I need read discussion on Shorewall list and look on counters in netfilter rules.

So I solved problem. First half was last kernel patch: 31.7. But the second 
half is changed interpretation of rp_filter interface parameter in kernels 
starting from 2.6.31. Now interface rp_filter setting has no precedence over 
/all/rp_filter but is used max of this two values.

Shorewall parameter ROUTEFILTER=No is not working with this kernels, but sets 
/all/rp_filter to 1 up to last Shorewall 4.4.5.2. So there is need to update 
Shorewall or set .../all/rp_filter manually in /etc/shorewall/start script adding:

	echo 0 >/proc/sys/net/ipv4/conf/all/rp_filter

ofcourse only, if we need not reverse path filtering (as with dual-homed bgp 
gate).

Andrzej Odyniec

Serge Leschinsky wrote:
> On 12/04/2009 07:42 AM, Andrzej Odyniec wrote:
>>The main difference, I think, is Quagga version -- now 0.99.15 patched for 
>>realms using diffs for 0.99.12.
>>I will try now to patch it (mainly bgpd) by newest accessible set of Adrian 
>>Ban patches based on Calin Velea patches for realms tested for 0.99.14.
> 
> Thanks for pointing to the problem - I've updated the patch in DL sources. Patch
> for 0.99.14 is completely compatible  with 0.99.15, the difference is only the
> line with version.

Thanks Serge,

Yes. I know about this compatibility. BTW. Pointing of incompatibility of 
Quagga and patches for realms was absolutely side-effect. Real problem is (I 
think now) in other place.

It is hard to test problems with routing on real company network. I can do it 
only immediately after midnight. But I tested this effect on all accessible 
version combinations of quagga with and without realms patch set: 13, 14 and 
15. All works on DL compilation from july and all is not correct working on 
last compiled DL. I think, there is no problem with quagga, but with Shorewall.

Tom Eastep changed Shorewall functionality in many places. Kernel was changed 
too. In July was Shorewall 4.2.6 and now is Shorewall 4.4.2. With last DL I 
see on border interfaces via tcpdump ping packets from my south Branches like 
from other Divisions, but there is no answers for this from south and is 
normal echo answer for rest of pings. There is no this effect when I load DL 
from July. I have open Shorewall for ping from all directions. Shorewall 
configuration was this same, but probably interpretation has changed. Maybe 
now is used source route (or other new) criterium?

I need read discussion on Shorewall list and look on counters in netfilter rules.

BTW. Thanks.

Regards

Andrzej

> -----Original Message-----
> From: Serge Leschinsky [mailto:fi...@in...]
> Sent: Monday, December 07, 2009 2:34 PM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] ipvsadm build fails
> 
> Heiko,
> 
> On 12/06/2009 05:51 AM, Heiko Zuerker wrote:
> > Serge,
> 
> > The ipvsadm compile fails and as far as I can tell it's because of
> the
> > missing libnl package.
> >
> > Did you already create a build script for it?
> >
> > http://www.infradead.org/~tgr/libnl/
> Oops. Sure, it was done. As it has been testing several months I
> completely
> forgot about this dependency. I'll fix it in a couple of minutes.
> 
> I'm sorry,
> Serge

No worries.

Thanks for updating it!

Heiko