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

Serge Leschinsky wrote:
> Hi Andrzej,
> 
> this is my "hack":

Serge,

thanks for this idea. I entered it into my patches.

Maybe I should remove zic compilation from /root/.bash_profile for possibility
to parallel chrooting into currently building system from second screen?

BTW. why don't enter this linking into /root/.bash_profile ?

Regards

-- 
Andrzej Odyniec

Hi Andrzej,

this is my "hack":

RCS file: /cvsroot/devil-linux/build/scripts/glibc,v
retrieving revision 1.57
diff -u -r1.57 glibc
--- glibc       6 Jan 2010 15:20:24 -0000       1.57
+++ glibc       30 Mar 2010 00:37:16 -0000
@@ -145,7 +145,7 @@
                popd || exit 1

                rm -rf $TMPDIR || exit 1
-
+               rm -f /etc/localtime && ln -sf /usr/share/zoneinfo/EST
/etc/localtime || exit 1
                ;;

        install )

Serge

On 03/29/2010 04:25 AM, Andrzej Odyniec wrote:
> Hi,
> 
> Behavior I observed is typical, when timezone in build environment is not set 
> correctly. But As for now, I don't know, who (which package) is source of this.
> 
> Builds I'm doing on DL (without of grsec ofcourse). But i think, source of 
> problem is not in base system.
> 
> After chrooting, there is executed /root/.bash_profile and there is set 
> timezone by zic.
> 
> After chrooting command 'date' is working correctly.
> 
> But immediatelly before Linux kernel is to be build, "date" is working 
> incorrectly:
> 
>> root:/build# date
>> Mon Mar 29 11:05:40 Local time zone must be set--see zic manual page 2010
> 
> so version is set incorrectly as mkcompile_h script used in kernel build 
> process to create compile.h header with defined kernel version string uses 
> "date" command to insert date into kernel version string. Because of this 
> after booting built system I obtain:
> 
>> root:~ # uname -v
>> #1 SMP Sun Mar 28 02:06:17 Local time zone must be set--see zic
> 
> I don't know, who (which package in his build process) destroys settings of 
> timezone (/etc/timezone file?). TIMEZONE variable is set coorectly. And after 
> calling zic again all is coorect.
> 
> I patch for my needs linux script, setting here again timezone by zic. But 
> maybe You know better place to do it.
> 
> Best regards
> 

Hi,

Behavior I observed is typical, when timezone in build environment is not set 
correctly. But As for now, I don't know, who (which package) is source of this.

Builds I'm doing on DL (without of grsec ofcourse). But i think, source of 
problem is not in base system.

After chrooting, there is executed /root/.bash_profile and there is set 
timezone by zic.

After chrooting command 'date' is working correctly.

But immediatelly before Linux kernel is to be build, "date" is working 
incorrectly:

> root:/build# date
> Mon Mar 29 11:05:40 Local time zone must be set--see zic manual page 2010

so version is set incorrectly as mkcompile_h script used in kernel build 
process to create compile.h header with defined kernel version string uses 
"date" command to insert date into kernel version string. Because of this 
after booting built system I obtain:

> root:~ # uname -v
> #1 SMP Sun Mar 28 02:06:17 Local time zone must be set--see zic

I don't know, who (which package in his build process) destroys settings of 
timezone (/etc/timezone file?). TIMEZONE variable is set coorectly. And after 
calling zic again all is coorect.

I patch for my needs linux script, setting here again timezone by zic. But 
maybe You know better place to do it.

Best regards

-- 
Andrzej Odyniec

Heiko Zuerker wrote:
> Okay great, let us know as soon as you have some results. 

After some number of compilations with 2.6.32.9 I have clear, obvious relation 
between compilation with grsec and "unloadability" od codecs/librabies 
compiled with Intel IPP.

I had problem with DAHDI drivers and GRSECured kernel some months ago, mainly 
with unloading DAHDI drivers, but this was corrected in newer versions of DAHDI.

> If it is
> grsecurity/pax related, it may be a good idea to post something in their
> forum, maybe you can track down the issue and get the code fixed.

If result will be repetitive on 2.6.32.10, I will check all asterisk modules. 
If from asterisk distribution there will be "unloadable" modules, this should 
be submitted to asterisk forum. But if only IPP compiled modules will be 
"unloadable", submit should be addressed to Asterisk G.729 Google group. But 
from other side, they know problems with SELinux, so there can be permanent 
problems with securing i.e. stacks with IPP compiled modules.

In this situation maybe reasonable solution is to find proper grsec/PaX 
parameter and to relax it for compilation with asterisk if one want to use 
open g723.1 and g729 codecs.

> I also started a new compile with a few updated packages, one of them
> the kernel 2.6.32.10, which also includes a newer grsecurity and pax.

So I start to try it

Best Regards

-- 
Andrzej Odyniec

<an...@ma...>
Rada Nadzorcza Macrologic SA
ul. Chrościckiego 49, 02-414 Warszawa
tel. +48-228637681, kom. +48-601276572
ul. Kłopotowskiego 22, 03-717 Warszawa
tel. +48-225118115, fax: +48-225118117
Rejestr: Sąd Rejonowy dla m.st. Warszawy,
          XIII Wydział Gospodarczy Krajowego
          Rejestru Sądowego, numer 0000045462
Numer identyfikacji podatkowej: PL 5220002825
Kapitał zakładowy: 1888719 zł opłacony w całości

I just uploaded my updates, see if the latest kernel + grsec behave
better for you.

Heiko

> -----Original Message-----
> From: Heiko Zuerker [mailto:he...@zu...]
> Sent: Sunday, March 28, 2010 9:00 AM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Dynamic linker behaviour
> 
> > -----Original Message-----
> > From: Andrzej Odyniec [mailto:an...@ma...]
> > Sent: Wednesday, March 24, 2010 9:34 AM
> > To: dev...@li...
> > Subject: Re: [Devil-linux-develop] Dynamic linker behaviour
> >
> > Heiko Zuerker wrote:
> > > not sure what would cause this behavior.
> > > Did you start with a completely new lfssystem when you compiled
> > > asterisk? If not, give that a try.
> >
> > Heiko,
> >
> > Ofcourse. I always start with new lfssysytem.
> >
> > Problem is with loading by Asterisk drivers (codecs, shared
> > libraries) built
> > out of DL (asterisk.hosting.lv). Asterisk ends on segfault. The
> > more, as
> > author of compilation, Arkadi Shishlov said, IPP library, used to
> > build this
> > codecs is little fussy.
> >
> > With this librabies in DL context problem is new. Always all
> codecs
> > was loaded
> > successfully. I suspected myself upgraded glibc, so I returned to
> > original
> > 2.5.1. Because strange ldd results I traced ldd script and
> > difference between
> > compilation from Feb and Mar is in result of command:
> >
> > /lib/ld-linux.so.2 --verify ./codec_g723-ast16-gcc4-glibc-
> core2.so
> >
> > which gives other return code. But ld-linux.so.2 (dynamic linker)
> > is binary
> > the same in both environments.
> >
> > I found another parameter to ld-linux.so.2 --list and now I have
> > description:
> >
> > > # /lib/ld-linux.so.2 --verify --list ./codec_g723-ast16-gcc4-
> > glibc-core2.so
> > > executable stack as shared object requires: Permission denied
> >
> > So I suspect, guilty is new kernel and new PAX. Now I started
> > compilation with
> > PAX switched off as grsecurity. Probably now kernel with PAX
> don't
> > want to
> > give rights for stack reservation as this library requires.
> >
> > I will report my results.
> >
> > Andrzej Odyniec
> 
> Okay great, let us know as soon as you have some results. If it is
> grsecurity/pax related, it may be a good idea to post something in
> their
> forum, maybe you can track down the issue and get the code fixed.
> 
> I also started a new compile with a few updated packages, one of
> them
> the kernel 2.6.32.10, which also includes a newer grsecurity and
> pax.
> 
> Heiko
> 
> 
> -------------------------------------------------------------------
> -----------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> 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, March 24, 2010 9:34 AM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Dynamic linker behaviour
> 
> Heiko Zuerker wrote:
> > not sure what would cause this behavior.
> > Did you start with a completely new lfssystem when you compiled
> > asterisk? If not, give that a try.
> 
> Heiko,
> 
> Ofcourse. I always start with new lfssysytem.
> 
> Problem is with loading by Asterisk drivers (codecs, shared
> libraries) built
> out of DL (asterisk.hosting.lv). Asterisk ends on segfault. The
> more, as
> author of compilation, Arkadi Shishlov said, IPP library, used to
> build this
> codecs is little fussy.
> 
> With this librabies in DL context problem is new. Always all codecs
> was loaded
> successfully. I suspected myself upgraded glibc, so I returned to
> original
> 2.5.1. Because strange ldd results I traced ldd script and
> difference between
> compilation from Feb and Mar is in result of command:
> 
> /lib/ld-linux.so.2 --verify ./codec_g723-ast16-gcc4-glibc-core2.so
> 
> which gives other return code. But ld-linux.so.2 (dynamic linker)
> is binary
> the same in both environments.
> 
> I found another parameter to ld-linux.so.2 --list and now I have
> description:
> 
> > # /lib/ld-linux.so.2 --verify --list ./codec_g723-ast16-gcc4-
> glibc-core2.so
> > executable stack as shared object requires: Permission denied
> 
> So I suspect, guilty is new kernel and new PAX. Now I started
> compilation with
> PAX switched off as grsecurity. Probably now kernel with PAX don't
> want to
> give rights for stack reservation as this library requires.
> 
> I will report my results.
> 
> Andrzej Odyniec

Okay great, let us know as soon as you have some results. If it is
grsecurity/pax related, it may be a good idea to post something in their
forum, maybe you can track down the issue and get the code fixed.

I also started a new compile with a few updated packages, one of them
the kernel 2.6.32.10, which also includes a newer grsecurity and pax.

Heiko

Hey,

 

Just a quick note that I'd like to stay with 2.6.32.x for DL 1.4.x.

This kernel is supposed to be maintained for a long time period and will
make our life easier with patches.

 

Once we got a final DL 1.4, we can start playing with a newer kernel in
1.5.

 

Regards

  Heiko Zuerker

  http://www.devil-linux.org

 

Heiko Zuerker wrote:
> not sure what would cause this behavior.
> Did you start with a completely new lfssystem when you compiled  
> asterisk? If not, give that a try.

Heiko,

Ofcourse. I always start with new lfssysytem.

Problem is with loading by Asterisk drivers (codecs, shared libraries) built 
out of DL (asterisk.hosting.lv). Asterisk ends on segfault. The more, as 
author of compilation, Arkadi Shishlov said, IPP library, used to build this 
codecs is little fussy.

With this librabies in DL context problem is new. Always all codecs was loaded 
successfully. I suspected myself upgraded glibc, so I returned to original 
2.5.1. Because strange ldd results I traced ldd script and difference between 
compilation from Feb and Mar is in result of command:

/lib/ld-linux.so.2 --verify ./codec_g723-ast16-gcc4-glibc-core2.so

which gives other return code. But ld-linux.so.2 (dynamic linker) is binary 
the same in both environments.

I found another parameter to ld-linux.so.2 --list and now I have description:

> # /lib/ld-linux.so.2 --verify --list ./codec_g723-ast16-gcc4-glibc-core2.so
> executable stack as shared object requires: Permission denied

So I suspect, guilty is new kernel and new PAX. Now I started compilation with 
PAX switched off as grsecurity. Probably now kernel with PAX don't want to 
give rights for stack reservation as this library requires.

I will report my results.

Andrzej Odyniec

Andrzej,

not sure what would cause this behavior.
Did you start with a completely new lfssystem when you compiled  
asterisk? If not, give that a try.

Heiko

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

> Dears,
>
> In last compilations I see strange dynamic linker behaviour.
>
> Ofcourse, I see this when Asterisk dynamically loads and links modules,
> especially codecs compiled out of DL build process, but some driver built DL
> have this same problem.
>
> Asterisk run on compilation from begin of February (2.6.32.7) loads modules
> correctly. Asking with ldd about this modules gives correct result for all
> modules:
>> root@VoIP:/etc/asterisk/modules/bin162 # for f in $(ls *.so); do  
>> echo $f; ldd $f; done
>> codec_g723-ast16-gcc4-glibc-core2.so
>>         linux-gate.so.1 =>  (0xb775a000)
>>         /lib/libsafe.so.2 (0xb7715000)
>>         libc.so.6 => /lib/libc.so.6 (0xb75e8000)
>>         libdl.so.2 => /lib/libdl.so.2 (0xb75e4000)
>>         /lib/ld-linux.so.2 (0xb775b000)
>> codec_g723-ast16-gcc4-glibc-pentium4-sse3.so
>>         linux-gate.so.1 =>  (0xb770c000)
>>         /lib/libsafe.so.2 (0xb76cd000)
>>         libc.so.6 => /lib/libc.so.6 (0xb75a0000)
>>         libdl.so.2 => /lib/libdl.so.2 (0xb759c000)
>>         /lib/ld-linux.so.2 (0xb770d000)
>> codec_g729-ast16-gcc4-glibc-core2.so
>>         linux-gate.so.1 =>  (0xb76f1000)
>>         /lib/libsafe.so.2 (0xb7684000)
>>         libc.so.6 => /lib/libc.so.6 (0xb7557000)
>>         libdl.so.2 => /lib/libdl.so.2 (0xb7553000)
>>         /lib/ld-linux.so.2 (0xb76f2000)
>> codec_g729-ast16-gcc4-glibc-pentium4-sse3.so
>>         linux-gate.so.1 =>  (0xb778a000)
>>         /lib/libsafe.so.2 (0xb771e000)
>>         libc.so.6 => /lib/libc.so.6 (0xb75f1000)
>>         libdl.so.2 => /lib/libdl.so.2 (0xb75ed000)
>>         /lib/ld-linux.so.2 (0xb778b000)
>> root@VoIP:/etc/asterisk/modules/bin162 #
>
>
> But Asterisk built after i.e. yesterday (2.6.32.9) can't load this same
> modules. This same ask answers:
>> root@VoIP:/etc/asterisk/modules/bin162 # for f in $(ls *.so); do  
>> echo $f; ldd $f; done
>> codec_g723-ast16-gcc4-glibc-core2.so
>>         not a dynamic executable
>> codec_g723-ast16-gcc4-glibc-pentium4-sse3.so
>>         not a dynamic executable
>> codec_g729-ast16-gcc4-glibc-core2.so
>>         not a dynamic executable
>> codec_g729-ast16-gcc4-glibc-pentium4-sse3.so
>>         not a dynamic executable
>> root@VoIP:/etc/asterisk/modules/bin162 #
>
> I tried above ldd test on DL with standard build (without Asterisk and my
> upgrades) too. Result of lld differentiates in this same manner. Ofcourse on
> standard builds I can't check loadability by Asterisk, but if behavior of ldd
> listing of this this same modules differs between this builds in this same
> manner, problem in loading modules by Asterisk is probably because ot this
> same reason.
>
> So probably behavior of dynamic linker changed between this two version. But
> dynamic linker belongs to glibc and I checked this especially without any
> upgrades to glibc. Maybe anyone of You know source of problems? Between
> versions from Feb and from Mar was upgraded many packages and  
> patches to kernel.
>
> How do You think? What changed behavior ot dynamic linking? Can we  
> repair this
> (i.e. by downgrading any package)? Or this will be repaired with  
> next kernels?
> or This is not repairable and we must wait for compatible recompilation of
> this modules?
>
> Regards
>
> --
> Andrzej Odyniec
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>



-- 

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


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

Dears,

In last compilations I see strange dynamic linker behaviour.

Ofcourse, I see this when Asterisk dynamically loads and links modules, 
especially codecs compiled out of DL build process, but some driver built DL 
have this same problem.

Asterisk run on compilation from begin of February (2.6.32.7) loads modules 
correctly. Asking with ldd about this modules gives correct result for all 
modules:
> root@VoIP:/etc/asterisk/modules/bin162 # for f in $(ls *.so); do echo $f; ldd $f; done
> codec_g723-ast16-gcc4-glibc-core2.so
>         linux-gate.so.1 =>  (0xb775a000)
>         /lib/libsafe.so.2 (0xb7715000)
>         libc.so.6 => /lib/libc.so.6 (0xb75e8000)
>         libdl.so.2 => /lib/libdl.so.2 (0xb75e4000)
>         /lib/ld-linux.so.2 (0xb775b000)
> codec_g723-ast16-gcc4-glibc-pentium4-sse3.so
>         linux-gate.so.1 =>  (0xb770c000)
>         /lib/libsafe.so.2 (0xb76cd000)
>         libc.so.6 => /lib/libc.so.6 (0xb75a0000)
>         libdl.so.2 => /lib/libdl.so.2 (0xb759c000)
>         /lib/ld-linux.so.2 (0xb770d000)
> codec_g729-ast16-gcc4-glibc-core2.so
>         linux-gate.so.1 =>  (0xb76f1000)
>         /lib/libsafe.so.2 (0xb7684000)
>         libc.so.6 => /lib/libc.so.6 (0xb7557000)
>         libdl.so.2 => /lib/libdl.so.2 (0xb7553000)
>         /lib/ld-linux.so.2 (0xb76f2000)
> codec_g729-ast16-gcc4-glibc-pentium4-sse3.so
>         linux-gate.so.1 =>  (0xb778a000)
>         /lib/libsafe.so.2 (0xb771e000)
>         libc.so.6 => /lib/libc.so.6 (0xb75f1000)
>         libdl.so.2 => /lib/libdl.so.2 (0xb75ed000)
>         /lib/ld-linux.so.2 (0xb778b000)
> root@VoIP:/etc/asterisk/modules/bin162 #


But Asterisk built after i.e. yesterday (2.6.32.9) can't load this same 
modules. This same ask answers:
> root@VoIP:/etc/asterisk/modules/bin162 # for f in $(ls *.so); do echo $f; ldd $f; done
> codec_g723-ast16-gcc4-glibc-core2.so
>         not a dynamic executable
> codec_g723-ast16-gcc4-glibc-pentium4-sse3.so
>         not a dynamic executable
> codec_g729-ast16-gcc4-glibc-core2.so
>         not a dynamic executable
> codec_g729-ast16-gcc4-glibc-pentium4-sse3.so
>         not a dynamic executable
> root@VoIP:/etc/asterisk/modules/bin162 #

I tried above ldd test on DL with standard build (without Asterisk and my 
upgrades) too. Result of lld differentiates in this same manner. Ofcourse on 
standard builds I can't check loadability by Asterisk, but if behavior of ldd 
listing of this this same modules differs between this builds in this same 
manner, problem in loading modules by Asterisk is probably because ot this 
same reason.

So probably behavior of dynamic linker changed between this two version. But 
dynamic linker belongs to glibc and I checked this especially without any 
upgrades to glibc. Maybe anyone of You know source of problems? Between 
versions from Feb and from Mar was upgraded many packages and patches to kernel.

How do You think? What changed behavior ot dynamic linking? Can we repair this 
(i.e. by downgrading any package)? Or this will be repaired with next kernels? 
or This is not repairable and we must wait for compatible recompilation of 
this modules?

Regards

-- 
Andrzej Odyniec

Dears,

As I declared earlier, I was build Asterisk into DL.
IMHO VoIP routing is very important for routers today and
Asterisk is MHB in DL (if DL is to be router).

Now this compilation is working in real environment.

As for now, only Dominic Raferd officially voted
for Asterisk. :)

I think, that inserting new thing into 1.4 RC3 is
maybe risky, the more, that I compiled *newest* Asterisk.
So decision about permanent insert of Asterisk is
in hands of Developers Team.

Because, I prepared scripts to automatically insert
all things needed by Asterisk into clean lfssystem
just before chrooting. So anyone compiling DL can try
to compile it with Asterisk. As it will be needed and
possible, I will keep updated this set of scripts.

There is short intro.

Installing Asterisk on DL system just before build process
==========================================================

Prepare, as usually, tree to build DL system. I assume, all is in
directory named lfssystem/ and is prepared as in Devil-Linux
documentation. Just before chrooting!

In parent directory of lfssystem/ unpack file from
http://home.macrologic.pl/~guru/asterisk/asterisk.tar.gz.

tar -xzf asterisk.tar.gz

After this just beside lfssystem/ You should have directory
named asterisk/ . Enter into this directory:

cd asterisk

Here, in this directory You have many scripts. You should use only
this, beginning from All. You need do three steps:

1. Download sources from Internet. This will be done by script:

./Alldownload

If process will be broken, there is need to do it again. All wgets are
with -c option, so in next run present files will not be downloaded
again or will be continued. If there is need to download all files
again from null, You can remove all downloaded using script ./Allcleanfiles

In this step, from many places on Internet will be downloaded about 150MB.

2. If all is downloaded correctly, You can upgrade ../lfssystem/ tree by
unpacked from .tar.gz and downloaded files, using script:

./Allinstall

Process will copy files, patch another files (backing up original ones
before patching) and modifying Makefiles. You can (I hope ;-) ) safely
repeat this process again and again, because before patching, original
files are restored from backup (if backup exists). There can be need
to clean backed up files (i.e. after rebuild clean ../lfssystem/)
using ./Allcleanbackup

3. If all is installed correctly, there is need to change default
settings in configuration files (especially in
lfssystem/build/.config). This You can do using script

./Allsetup

This script should not be repeated, as it appends some settings at end
of files. If You will repeat, as effect You can see repeated setting of
this same parameter. This should not ruin build process.

This script transfers resolver settings into build system. In time of
build Asterisk and DAHDI need to download something from Digium sites.

-------------

After this You can chroot to build system (as in documentation of DL)
and do proper make. You needn't do make menuconfig, as build/.config is
created by ./Allsetup above. But You can change configuration.

If in time of menuconfig You will switch off something needed by
Asterisk, there can be problems in compilation, because all
dependencies are not implemented in .config files.

Asterisk configuration as standard is done using 'make menuselect'
interactively just after ./configure and before make. In script
/build/scripts/asterisk we write result of 'make menuselect' statically
to configuration file.

=============

Best regards

-- 
Andrzej Odyniec

Go for it.

- BS

On Mar 1, 2010 2:39 PM, "Serge Leschinsky" <fi...@in...> wrote:

On 03/01/2010 06:43 AM, Heiko Zuerker wrote:
> Are we ready to release RC3 or does anyone have somet...
My queue is empty.

Serge


------------------------------------------------------------------------------
Download Intel&#174;...

On 03/01/2010 06:43 AM, Heiko Zuerker wrote:
> Are we ready to release RC3 or does anyone have something still in the queue?
> 
My queue is empty.

Serge

Heiko Zuerker wrote:
> Are we ready to release RC3 or does anyone have something still in the queue?
> 
Go :-)

-- 
_______________________________________________
 Centre de Technologie de l'Education
 29 avenue John F. Kennedy
 L-1855 Luxembourg-Kirchberg
 email: Fra...@ct...
 tél.: +352 247-85973
 fax: +352 333797
_______________________________________________

Are we ready to release RC3 or does anyone have something still in the queue?

-- 

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


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

Done.

Serge

On 02/28/2010 12:53 PM, Heiko Zuerker wrote:
>> -----Original Message-----
>> From: Serge Leschinsky [mailto:fi...@in...]
>>
>> In parted 2.2 and util-linux-ng-2.17.1 was improved support of
>> harddrives with
>> 4k blocks. What do you think about updates? After libdevmapper
>> updating to the
>> latest one, parted is build correctly. The patch for loop-aes is
>> also available.
> 
> Go for it.
> 
> Heiko

> -----Original Message-----
> From: Serge Leschinsky [mailto:fi...@in...]
> 
> In parted 2.2 and util-linux-ng-2.17.1 was improved support of
> harddrives with
> 4k blocks. What do you think about updates? After libdevmapper
> updating to the
> latest one, parted is build correctly. The patch for loop-aes is
> also available.

Go for it.

Heiko

Heiko,

In parted 2.2 and util-linux-ng-2.17.1 was improved support of harddrives with
4k blocks. What do you think about updates? After libdevmapper updating to the
latest one, parted is build correctly. The patch for loop-aes is also available.

Sincerely,
Serge

On 02/26/2010 04:52 AM, Heiko Zuerker wrote:
...
> I personally don't use IMQ, but there's a newer patch:
> http://www.linuximq.net/
> We usually use the one from openwrt, since they keep it up-to-date. It
> may be worth trying out the official version.
> I'm planning to stay with 2.6.32 for 1.4 anyway, since this kernel will
> be maintained for a long time.
Hm.. I have to check if it works with the new patch. I suppose it's a good idea
to update kernel patch - at least for backward compatibility with old
configurations.


> I disavbled the make check for coreutils, not sure if you want to
> re-enable it. I personally think it's not worth the effort running those
> checks in our build system.
OK.

Serge

I know. :)

But don't use IMQ in production, please
It may cause crash kernel ( and it will with very high probability)

PS. I have managed to reach some progress with IFB and I'm ready to share my
scripts.

Serge

On 02/26/2010 07:55 AM, Andrzej Odyniec wrote:
> Serge Leschinsky wrote:
> 
>> Fixed.
> 
> All compiled correctly with new IMQ patch. :)
> 
> Rgds
> 

Serge Leschinsky wrote:

> Fixed.

All compiled correctly with new IMQ patch. :)

Rgds

-- 
Andrzej Odyniec

Quoting Serge Leschinsky <fi...@in...>:

> oops. Too many faults :(
>
> I disabled IMQ because it crashes kernels if I use traffic control  
> mechanisms...
> and  disabled it both for kernel and iptables.
>
> I can submit a patch for that (but it looks like very dangerous to  
> use IMQ with
> recent kernels) or disable it.

I personally don't use IMQ, but there's a newer patch:  
http://www.linuximq.net/
We usually use the one from openwrt, since they keep it up-to-date. It  
may be worth trying out the official version.
I'm planning to stay with 2.6.32 for 1.4 anyway, since this kernel  
will be maintained for a long time.

> PS. I deleted ipcals script from cvs and I realize that it was premature. I'm
> ready to resubmit it back - just let me know.
>
> PPS. I've attached the patch for coreutils - actually only one test fails and
> it's a bug of coreutils.

I disavbled the make check for coreutils, not sure if you want to  
re-enable it. I personally think it's not worth the effort running  
those checks in our build system.

-- 

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


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

Fixed.

Serge

On 02/25/2010 11:55 AM, Heiko Zuerker wrote:
> Serge,
> 
> my iptables compile keeps failing, do you have a patch for it?
> 
>    CC       libxt_IMQ.oo
> libxt_IMQ.c: In function 'IMQ_parse':
> libxt_IMQ.c:42: error: too few arguments to function 'xtables_check_inverse'
> make[2]: *** [libxt_IMQ.oo] Error 1
> make[2]: Leaving directory `/data/build/tmp/iptables-1.4.6/extensions'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/data/build/tmp/iptables-1.4.6'
> 

Cool.

ipcalc included the "BROADCAST=" part, hence the "eval".

 - BS


On Thu, Feb 25, 2010 at 21:17, Serge Leschinsky <fi...@in...> wrote:
> Bruce,
>
> thank you.
>
> BROADCAST=$(sipcalc $IP $NETMASK 2> /dev/null | grep Broadcast | cut -d'-' -f2 |
> tr -d [:space:])
>
> It works. I'm going to submit the patch
>
> Serge
>
>
> On 02/25/2010 05:26 PM, Bruce Smith wrote:
>> the ipcalc should return the broadcast address, so there appears to be
>> something wrong with your setup fix.
>>
>> Try this instead (untested):
>>
>> BROADCAST=$(sipcalc $IP $NETMASK 2> /dev/null | grep Broadcast | cut -d'-' -f2)
>>
>>  - BS
>>
>> On Thu, Feb 25, 2010 at 20:18, Serge Leschinsky <fi...@in...> wrote:
>>> Bruce,
>>>
>>> sorry for my hasty decision. I need your help. I'm not sure that I've completely
>>> understood how it works...
>>>
>>> Is it correct change?
>>> -  eval $(ipcalc -b $IP $NETMASK 2> /dev/null)
>>> +  eval $(sipcalc $IP $NETMASK 2> /dev/null | grep Broadcast | cut -d'-' -f2)
>>>
>>> If I configure NIC by setup I get the following config
>>> -----------------------------
>>> DEVICE=eth0
>>> ONBOOT=yes
>>> MODULE=autoselect
>>> DHCP=no
>>> IP="192.168.1.2"
>>> NETMASK="255.255.255.224"
>>> BROADCAST=""
>>> -----------------------------
>>>
>>> Broadcast is empty and I don't understand if it's improper sipcalc usage or not.
>>>
>>> Serge
>>>
>>> On 02/25/2010 05:00 AM, Bruce Smith wrote:
>>>> Either way is fine with me.
>>>>
>>>> If you decide to delete ipcalc, please make the change to setup.
>>>>
>>>>  - BS
>>>>
>>>>
>>>> On Wed, Feb 24, 2010 at 23:07, Serge Leschinsky <fi...@in...> wrote:
>>>>> Bruce,
>>>>>
>>>>> I see this line in setup
>>>>> eval $(ipcalc -b $IP $NETMASK 2> /dev/null)
>>>>>
>>>>> Do we need to calculate broadcast?
>>>>>
>>>>> sipcalc 192.168.1.4 255.255.255.224 | grep Broadcast | cut -d'-' -f2
>>>>>
>>>>> does the same.
>>>>>
>>>>> PS. We can have the both program of course if you prefer to use ipcalc
>>>>>
>>>>> Serge
>>>>>
>>>>>
>>>>> On 02/24/2010 06:52 PM, Bruce Smith wrote:
>>>>>> The main "setup" program uses ipcalc, so removing it will break setup.
>>>>>>
>>>>>> Is there any reason we can't have both programs?
>>>>>>
>>>>>> Or how much difference is there in the syntax (how much work to fix setup)?
>>>>>>
>>>>>>  - BS
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 24, 2010 at 21:38, Heiko Zuerker <he...@zu...> wrote:
>>>>>>>> -----Original Message-----
>>>>>>>> From: Andrzej Odyniec [mailto:an...@ma...]
>>>>>>>> Sent: Wednesday, February 24, 2010 8:37 PM
>>>>>>>> To: dev...@li...
>>>>>>>> Subject: Re: [Devil-linux-develop] sipcalc?
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Serge Leschinsky wrote:
>>>>>>>>> I'm very sorry for inconvenience with broken makefiles.
>>>>>>>> Absolutely no problem. :)
>>>>>>>>
>>>>>>>>> So, if we are agree that sipcalc is better than ipcalc, I'll
>>>>>>>> upload the package
>>>>>>>>> and script (and remove ipcalc)
>>>>>>>>
>>>>>>>> As for me ipcalc is practically unusable. I found and I'm using
>>>>>>>> perl script
>>>>>>>> known as:
>>>>>>>>> #  IPv4 Calculator
>>>>>>>>> #  Copyright (C) Krischan Jodies 2000 - 2004
>>>>>>>>> #  krischan()jodies.de, http://jodies.de/ipcalc
>>>>>>>>
>>>>>>>> But sipcalc has near this same functionality. This is nice.
>>>>>>>
>>>>>>> I'm good with it too.
>>>>>>>
>>>>>>> Heiko
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Download Intel&#174; Parallel Studio Eval
>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>> _______________________________________________
>>>>>>> Devil-linux-develop mailing list
>>>>>>> Dev...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel&#174; Parallel Studio Eval
>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> _______________________________________________
>>>>>> Devil-linux-develop mailing list
>>>>>> Dev...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

Bruce,

thank you.

BROADCAST=$(sipcalc $IP $NETMASK 2> /dev/null | grep Broadcast | cut -d'-' -f2 |
tr -d [:space:])

It works. I'm going to submit the patch

Serge


On 02/25/2010 05:26 PM, Bruce Smith wrote:
> the ipcalc should return the broadcast address, so there appears to be
> something wrong with your setup fix.
> 
> Try this instead (untested):
> 
> BROADCAST=$(sipcalc $IP $NETMASK 2> /dev/null | grep Broadcast | cut -d'-' -f2)
> 
>  - BS
> 
> On Thu, Feb 25, 2010 at 20:18, Serge Leschinsky <fi...@in...> wrote:
>> Bruce,
>>
>> sorry for my hasty decision. I need your help. I'm not sure that I've completely
>> understood how it works...
>>
>> Is it correct change?
>> -  eval $(ipcalc -b $IP $NETMASK 2> /dev/null)
>> +  eval $(sipcalc $IP $NETMASK 2> /dev/null | grep Broadcast | cut -d'-' -f2)
>>
>> If I configure NIC by setup I get the following config
>> -----------------------------
>> DEVICE=eth0
>> ONBOOT=yes
>> MODULE=autoselect
>> DHCP=no
>> IP="192.168.1.2"
>> NETMASK="255.255.255.224"
>> BROADCAST=""
>> -----------------------------
>>
>> Broadcast is empty and I don't understand if it's improper sipcalc usage or not.
>>
>> Serge
>>
>> On 02/25/2010 05:00 AM, Bruce Smith wrote:
>>> Either way is fine with me.
>>>
>>> If you decide to delete ipcalc, please make the change to setup.
>>>
>>>  - BS
>>>
>>>
>>> On Wed, Feb 24, 2010 at 23:07, Serge Leschinsky <fi...@in...> wrote:
>>>> Bruce,
>>>>
>>>> I see this line in setup
>>>> eval $(ipcalc -b $IP $NETMASK 2> /dev/null)
>>>>
>>>> Do we need to calculate broadcast?
>>>>
>>>> sipcalc 192.168.1.4 255.255.255.224 | grep Broadcast | cut -d'-' -f2
>>>>
>>>> does the same.
>>>>
>>>> PS. We can have the both program of course if you prefer to use ipcalc
>>>>
>>>> Serge
>>>>
>>>>
>>>> On 02/24/2010 06:52 PM, Bruce Smith wrote:
>>>>> The main "setup" program uses ipcalc, so removing it will break setup.
>>>>>
>>>>> Is there any reason we can't have both programs?
>>>>>
>>>>> Or how much difference is there in the syntax (how much work to fix setup)?
>>>>>
>>>>>  - BS
>>>>>
>>>>>
>>>>> On Wed, Feb 24, 2010 at 21:38, Heiko Zuerker <he...@zu...> wrote:
>>>>>>> -----Original Message-----
>>>>>>> From: Andrzej Odyniec [mailto:an...@ma...]
>>>>>>> Sent: Wednesday, February 24, 2010 8:37 PM
>>>>>>> To: dev...@li...
>>>>>>> Subject: Re: [Devil-linux-develop] sipcalc?
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Serge Leschinsky wrote:
>>>>>>>> I'm very sorry for inconvenience with broken makefiles.
>>>>>>> Absolutely no problem. :)
>>>>>>>
>>>>>>>> So, if we are agree that sipcalc is better than ipcalc, I'll
>>>>>>> upload the package
>>>>>>>> and script (and remove ipcalc)
>>>>>>>
>>>>>>> As for me ipcalc is practically unusable. I found and I'm using
>>>>>>> perl script
>>>>>>> known as:
>>>>>>>> #  IPv4 Calculator
>>>>>>>> #  Copyright (C) Krischan Jodies 2000 - 2004
>>>>>>>> #  krischan()jodies.de, http://jodies.de/ipcalc
>>>>>>>
>>>>>>> But sipcalc has near this same functionality. This is nice.
>>>>>>
>>>>>> I'm good with it too.
>>>>>>
>>>>>> Heiko
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel&#174; Parallel Studio Eval
>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> _______________________________________________
>>>>>> Devil-linux-develop mailing list
>>>>>> Dev...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel&#174; Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Devil-linux-develop mailing list
>>>>> Dev...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>>>>
>>>>
>>>>
>>>
>>
>>
>