astlinux-devel Mailing List for AstLinux

Kristian Kielhofner wrote:
> Hey Devs,
> 
>   Word is Pika support should be removed.  I'll get around to yanking
> it out of trunk soon...
> 

Too late... I got bored while waiting for the Dell tech to return to my 
online chat session.

I removed several other packages that are either no longer needed or 
never used.  There are at least another half-dozen that should go too.

Darrick

Lonnie Abelbeck wrote:
> On Dec 30, 2008, at 1:30 PM, Philip Prindeville wrote:
>
>   
>> Lonnie Abelbeck wrote:
>>     
>>> Devs,
>>>
>>> I thought it would be interesting to create a timeline of the startup
>>> process.
>>>
>>> This is on a net5501 512M/500MHz, trunk-2244.
>>> Default packages minus Rhino and Wanpipe
>>>
>>> Time    Action
>>> (secs)
>>>
>>> 000    POST
>>>
>>> 007    Runnix Starts
>>>
>>> 032    Verify Image - start
>>> 050    Done - 18 seconds
>>>
>>> 058    Copy Image - start
>>> 076    Done - 18 seconds
>>>
>>>       
>> Why not copy and verify at the same time? Worst case, the image  
>> doesn't
>> verify, and you delete the contents of the ramfs...
>>
>>
>>     
>>> 093    Start ntpd
>>>
>>>       
>> 13 seconds sounds a bit long. My NTP usually stabilizes within 3  
>> seconds
>> if it has less than 1 second of (hwclock) drift from the reference
>> clock. This is usually the case since we have both a driftfile and we
>> save the real-time back into the hwclock on shutdown...
>>     
>
> I just used 'Start ntpd' as a time-point, all the rest of the  
> packages.init account for the 13 seconds till 'login:'.
>
>
>   
>>> 106    login:
>>>
>>> Another interesting tidbit:
>>>
>>> pbx ~ # time sha1sum /oldroot/cdrom/os/astlinux-trunk-2244.run
>>> 6924da20d08ce508a60234d312987f864c21ecc6  /oldroot/cdrom/os/astlinux-
>>> trunk-2244.run
>>>
>>> real	0m14.476s
>>> user	0m0.568s
>>> sys	0m1.568s
>>>
>>> pbx ~ # time openssl sha1 /oldroot/cdrom/os/astlinux-trunk-2244.run
>>> SHA1(/oldroot/cdrom/os/astlinux-trunk-2244.run)=
>>> 6924da20d08ce508a60234d312987f864c21ecc6
>>>
>>> real	0m2.031s
>>> user	0m0.290s
>>> sys	0m0.011s
>>>
>>> Possibly a little hardware crypto helping out openssl here?
>>>
>>>       
>> We could make openssl mandatory, and define "openssl {" as a  
>> function in
>> the "functions" script as a wrapper for this.
>>     
>
> It appears that openssl uses assembler for the target platform to  
> increase its speed (and also hardware crypto).  Though adding openssl  
> to the runnix build would significantly add to it's size.
>
> sha1sum is a fairly simple busybox function.
>
> Alternatively, how about after a successful sha1sum calculation,  
> runnix deletes the .sha1 file (or initrd deletes it), and then the  
> next time gracefully boots with no .sha1 file?  The upgrade-run-image  
> routine could do the same so the reboot does not require the SHA1  
> calculation.
>   

That would make it very easy to subvert a box.


>>> But, on a 0.6 build a few months old:
>>>
>>> voip ~ # time sha1sum /oldroot/cdrom/os/astlinux-0.6-1976.run
>>> 7b5f7518950f21e40811d84ae21e73dc2fb0d111  /oldroot/cdrom/os/
>>> astlinux-0.6-1976.run
>>>
>>> real	0m3.977s
>>> user	0m3.814s
>>> sys	0m0.153s
>>>
>>>       
>> That's interesting. Why is the old checksum so much faster?
>>
>>     
>>> voip ~ # time openssl sha1 /oldroot/cdrom/os/astlinux-0.6-1976.run
>>> SHA1(/oldroot/cdrom/os/astlinux-0.6-1976.run)=
>>> 7b5f7518950f21e40811d84ae21e73dc2fb0d111
>>>
>>> real	0m1.683s
>>> user	0m1.528s
>>> sys	0m0.151s
>>>
>>> Possibly the SHA1 time depends on the data as much as how much data?
>>>
>>>       
>> No, sha1 is a shufflebox of Nth degree, so it's done as a lookup (same
>> as MD5). It's fixed time per byte.
>>
>> -Philip
>>     
>
> Interesting Philip, I don't understand why sha1sum's times jump around  
> so much, maybe it's implementation is not optimal.
>
> Lonnie
>
>   

Yeah, I don't get it either.

There are compiler flags that we set, by the way, that never seem to
make it into the compilation.

target/device/*/Makefile.in should be setting BR2_TARGET_OPTIMIZATION,
but it never makes its way into TARGET_CFLAGS:

$ make BR2_TARGET_NET5501= BR2_TARGET_GUMSTIX_BASIXCONNEX=y var.BR2_TARGET_OPTIMIZATION var.TARGET_OPTIMIZATION var.TARGET_CFLAGS
target/device/net5501/linux.mk:137: warning: overriding commands for target `/home/philipp/trunk/build_i586/staging_dir/include/linux/version.h'
target/device/Gumstix/basix-connex/linux.mk:124: warning: ignoring old commands for target `/home/philipp/trunk/build_i586/staging_dir/include/linux/version.h'
target/device/net5501/linux.mk:163: warning: overriding commands for target `linuxclean'
target/device/Gumstix/basix-connex/linux.mk:137: warning: ignoring old commands for target `linuxclean'
target/device/net5501/linux.mk:167: warning: overriding commands for target `linux-dirclean'
target/device/Gumstix/basix-connex/linux.mk:141: warning: ignoring old commands for target `linux-dirclean'
BR2_TARGET_OPTIMIZATION="-Os -pipe -Os -march=armv5te -mtune=xscale -Wa,-mcpu=xscale"
TARGET_OPTIMIZATION="-Os -pipe -fomit-frame-pointer"
TARGET_CFLAGS="-Os -pipe -fomit-frame-pointer "
$ 


and some platforms like the net5501 should be setting their compiler flags for Geode, but don't.


Quoting an email from AMD:

> 'Internal testing with EEMBC Benchmarks have shown, that the overall
> best performing CFLAGS (compile time flags) used were "-march=k6-2 -O3
> -fno-align-functions -fno-align-loops -fno-align-jumps -fno-align-labels
> -finline-functions".'
>
> Newer versions of gcc include thee march of geode and it does pretty
> well over all

I've not had a chance to troubleshoot this.

I tried setting this for net5501 (target/device/net5501/Makefile.in)

BR2_TARGET_OPTIMIZATION=-march=k6-2 -O3 -fno-align-functions
-fno-align-loops -fno-align-jumps -fno-align-labels

but the line:


TARGET_OPTIMIZATION:=$(strip $(subst ",, $(BR2_TARGET_OPTIMIZATION)))

in toolchain/gcc/Makefile.in doesn't seem to be hit... oh, hang on. It
does get hit... but since the include order is:

include toolchain/*/*.mk
include package/*/*.mk
include target/*/*.mk

BR2_TARGET_OPTIMIZATION has the default value, not the platform (target)
value.

I've never understood why target gets included last. It should be first.

Changing the above line to:

TARGET_OPTIMIZATION=$(strip $(subst ",, $(BR2_TARGET_OPTIMIZATION)))

fixes this...

$ make BR2_TARGET_NET5501=y var.BR2_TARGET_OPTIMIZATION var.TARGET_OPTIMIZATION var.TARGET_CFLAGS
BR2_TARGET_OPTIMIZATION="-march=k6-2 -O3 -fno-align-functions -fno-align-loops -fno-align-jumps -fno-align-labels"
TARGET_OPTIMIZATION="-march=k6-2 -O3 -fno-align-functions -fno-align-loops -fno-align-jumps -fno-align-labels"
TARGET_CFLAGS="-march=k6-2 -O3 -fno-align-functions -fno-align-loops -fno-align-jumps -fno-align-labels "
$ 

Maybe.  But we don't know what other variables do a := of BR2_TARGET_OPTIMIZATION or TARGET_OPTIMIZATION before it's been set.

One solutions is to have target/device/net5501/Makefile.in do:

BR2_TARGET_OPTIMIZATION+= ...

Looking in package/Makefile.in, it seems to be safe (it does a
"deferred" evaluation):

TARGET_CFLAGS=$(TARGET_OPTIMIZATION) $(TARGET_DEBUGGING)


-Philip


Index: toolchain/gcc/Makefile.in
===================================================================
--- toolchain/gcc/Makefile.in   (revision 2240)
+++ toolchain/gcc/Makefile.in   (working copy)
@@ -6,7 +6,7 @@
 
 GCC_VERSION:=$(strip $(subst ",, $(BR2_GCC_VERSION)))
 #"))
-TARGET_OPTIMIZATION:=$(strip $(subst ",, $(BR2_TARGET_OPTIMIZATION)))
+TARGET_OPTIMIZATION=$(strip $(subst ",, $(BR2_TARGET_OPTIMIZATION)))
 #"))
 EXTRA_GCC_CONFIG_OPTIONS:=$(strip $(subst ",, $(BR2_EXTRA_GCC_CONFIG_OPTIONS)))
 #"))
Index: target/device/net5501/Makefile.in
===================================================================
--- target/device/net5501/Makefile.in   (revision 2240)
+++ target/device/net5501/Makefile.in   (working copy)
@@ -8,6 +8,7 @@
 TARGET_SKEL2_DIR=$(SOEKRIS_NET5501_PATH)/target_skeleton
 BR2_PACKAGE_BUSYBOX_CONFIG:=$(SOEKRIS_NET5501_PATH)/busybox.config
 TARGET_RUNNIX_DIR=$(SOEKRIS_NET5501_PATH)/runnix
+BR2_TARGET_OPTIMIZATION+=-march=k6-2 -O3 -fno-align-functions -fno-align-loops -fno-align-jumps -fno-align-labels
 
 ifeq ($(strip $(BR2_PACKAGE_LINUX)),y)
 TARGETS+=linux

On Dec 30, 2008, at 1:30 PM, Philip Prindeville wrote:

> Lonnie Abelbeck wrote:
>> Devs,
>>
>> I thought it would be interesting to create a timeline of the startup
>> process.
>>
>> This is on a net5501 512M/500MHz, trunk-2244.
>> Default packages minus Rhino and Wanpipe
>>
>> Time    Action
>> (secs)
>>
>> 000    POST
>>
>> 007    Runnix Starts
>>
>> 032    Verify Image - start
>> 050    Done - 18 seconds
>>
>> 058    Copy Image - start
>> 076    Done - 18 seconds
>>
>
> Why not copy and verify at the same time? Worst case, the image  
> doesn't
> verify, and you delete the contents of the ramfs...
>
>
>> 093    Start ntpd
>>
>
> 13 seconds sounds a bit long. My NTP usually stabilizes within 3  
> seconds
> if it has less than 1 second of (hwclock) drift from the reference
> clock. This is usually the case since we have both a driftfile and we
> save the real-time back into the hwclock on shutdown...

I just used 'Start ntpd' as a time-point, all the rest of the  
packages.init account for the 13 seconds till 'login:'.


>> 106    login:
>>
>> Another interesting tidbit:
>>
>> pbx ~ # time sha1sum /oldroot/cdrom/os/astlinux-trunk-2244.run
>> 6924da20d08ce508a60234d312987f864c21ecc6  /oldroot/cdrom/os/astlinux-
>> trunk-2244.run
>>
>> real	0m14.476s
>> user	0m0.568s
>> sys	0m1.568s
>>
>> pbx ~ # time openssl sha1 /oldroot/cdrom/os/astlinux-trunk-2244.run
>> SHA1(/oldroot/cdrom/os/astlinux-trunk-2244.run)=
>> 6924da20d08ce508a60234d312987f864c21ecc6
>>
>> real	0m2.031s
>> user	0m0.290s
>> sys	0m0.011s
>>
>> Possibly a little hardware crypto helping out openssl here?
>>
>
> We could make openssl mandatory, and define "openssl {" as a  
> function in
> the "functions" script as a wrapper for this.

It appears that openssl uses assembler for the target platform to  
increase its speed (and also hardware crypto).  Though adding openssl  
to the runnix build would significantly add to it's size.

sha1sum is a fairly simple busybox function.

Alternatively, how about after a successful sha1sum calculation,  
runnix deletes the .sha1 file (or initrd deletes it), and then the  
next time gracefully boots with no .sha1 file?  The upgrade-run-image  
routine could do the same so the reboot does not require the SHA1  
calculation.


>> But, on a 0.6 build a few months old:
>>
>> voip ~ # time sha1sum /oldroot/cdrom/os/astlinux-0.6-1976.run
>> 7b5f7518950f21e40811d84ae21e73dc2fb0d111  /oldroot/cdrom/os/
>> astlinux-0.6-1976.run
>>
>> real	0m3.977s
>> user	0m3.814s
>> sys	0m0.153s
>>
>
> That's interesting. Why is the old checksum so much faster?
>
>> voip ~ # time openssl sha1 /oldroot/cdrom/os/astlinux-0.6-1976.run
>> SHA1(/oldroot/cdrom/os/astlinux-0.6-1976.run)=
>> 7b5f7518950f21e40811d84ae21e73dc2fb0d111
>>
>> real	0m1.683s
>> user	0m1.528s
>> sys	0m0.151s
>>
>> Possibly the SHA1 time depends on the data as much as how much data?
>>
>
> No, sha1 is a shufflebox of Nth degree, so it's done as a lookup (same
> as MD5). It's fixed time per byte.
>
> -Philip

Interesting Philip, I don't understand why sha1sum's times jump around  
so much, maybe it's implementation is not optimal.

Lonnie

Lonnie Abelbeck wrote:
> Devs,
>
> I thought it would be interesting to create a timeline of the startup  
> process.
>
> This is on a net5501 512M/500MHz, trunk-2244.
> Default packages minus Rhino and Wanpipe
>
> Time    Action
> (secs)
>
> 000    POST
>
> 007    Runnix Starts
>
> 032    Verify Image - start
> 050    Done - 18 seconds
>
> 058    Copy Image - start
> 076    Done - 18 seconds
>   

Why not copy and verify at the same time? Worst case, the image doesn't
verify, and you delete the contents of the ramfs...


> 093    Start ntpd
>   

13 seconds sounds a bit long. My NTP usually stabilizes within 3 seconds
if it has less than 1 second of (hwclock) drift from the reference
clock. This is usually the case since we have both a driftfile and we
save the real-time back into the hwclock on shutdown...


> 106    login:
>
> Another interesting tidbit:
>
> pbx ~ # time sha1sum /oldroot/cdrom/os/astlinux-trunk-2244.run
> 6924da20d08ce508a60234d312987f864c21ecc6  /oldroot/cdrom/os/astlinux- 
> trunk-2244.run
>
> real	0m14.476s
> user	0m0.568s
> sys	0m1.568s
>
> pbx ~ # time openssl sha1 /oldroot/cdrom/os/astlinux-trunk-2244.run
> SHA1(/oldroot/cdrom/os/astlinux-trunk-2244.run)=  
> 6924da20d08ce508a60234d312987f864c21ecc6
>
> real	0m2.031s
> user	0m0.290s
> sys	0m0.011s
>
> Possibly a little hardware crypto helping out openssl here?
>   

We could make openssl mandatory, and define "openssl {" as a function in
the "functions" script as a wrapper for this.


> But, on a 0.6 build a few months old:
>
> voip ~ # time sha1sum /oldroot/cdrom/os/astlinux-0.6-1976.run
> 7b5f7518950f21e40811d84ae21e73dc2fb0d111  /oldroot/cdrom/os/ 
> astlinux-0.6-1976.run
>
> real	0m3.977s
> user	0m3.814s
> sys	0m0.153s
>   

That's interesting. Why is the old checksum so much faster?

> voip ~ # time openssl sha1 /oldroot/cdrom/os/astlinux-0.6-1976.run
> SHA1(/oldroot/cdrom/os/astlinux-0.6-1976.run)=  
> 7b5f7518950f21e40811d84ae21e73dc2fb0d111
>
> real	0m1.683s
> user	0m1.528s
> sys	0m0.151s
>
> Possibly the SHA1 time depends on the data as much as how much data?
>   

No, sha1 is a shufflebox of Nth degree, so it's done as a lookup (same
as MD5). It's fixed time per byte.

-Philip


> ---
> Lonnie
>
>   

Hey Devs,

  Word is Pika support should be removed.  I'll get around to yanking
it out of trunk soon...

-- 
Kristian Kielhofner
http://blog.krisk.org
http://www.submityoursip.com
http://www.astlinux.org
http://www.star2star.com

>Devs,
>
>I thought it would be interesting to create a timeline of the startup 
>process.
>
>This is on a net5501 512M/500MHz, trunk-2244.
>Default packages minus Rhino and Wanpipe
>
>Time    Action
>(secs)
>
>000    POST
>
>007    Runnix Starts
>
>032    Verify Image - start
>050    Done - 18 seconds
>
>058    Copy Image - start
>076    Done - 18 seconds
>
>093    Start ntpd
>
>106    login:
>
>Another interesting tidbit:
>
>pbx ~ # time sha1sum /oldroot/cdrom/os/astlinux-trunk-2244.run
>6924da20d08ce508a60234d312987f864c21ecc6  /oldroot/cdrom/os/astlinux-
>trunk-2244.run
>
>real	0m14.476s
>user	0m0.568s
>sys	0m1.568s
>
>pbx ~ # time openssl sha1 /oldroot/cdrom/os/astlinux-trunk-2244.run
>SHA1(/oldroot/cdrom/os/astlinux-trunk-2244.run)= 
>6924da20d08ce508a60234d312987f864c21ecc6
>
>real	0m2.031s
>user	0m0.290s
>sys	0m0.011s
>
>Possibly a little hardware crypto helping out openssl here?
>
>But, on a 0.6 build a few months old:
>
>voip ~ # time sha1sum /oldroot/cdrom/os/astlinux-0.6-1976.run
>7b5f7518950f21e40811d84ae21e73dc2fb0d111  /oldroot/cdrom/os/
>astlinux-0.6-1976.run
>
>real	0m3.977s
>user	0m3.814s
>sys	0m0.153s
>
>voip ~ # time openssl sha1 /oldroot/cdrom/os/astlinux-0.6-1976.run
>SHA1(/oldroot/cdrom/os/astlinux-0.6-1976.run)= 
>7b5f7518950f21e40811d84ae21e73dc2fb0d111
>
>real	0m1.683s
>user	0m1.528s
>sys	0m0.151s
>
>Possibly the SHA1 time depends on the data as much as how much data?
>---
>Lonnie

Hi Lonnie,

I tested that also on a 1 GHz PIII with 256 MB RAM:

I think you're right with that SHA1 depends on the data:

pbxrunnix os # time sha1sum astlinux-0.6.2.run    
fdd32688fb60dede38ffbbf4694e78652105bb27  astlinux-0.6.2.run

real	0m9.286s
user	0m1.342s
sys	0m4.712s

pbxrunnix os # time sha1sum astlinux-trunk-2246.run
6c9e64284a19fcac4fd6a727de7a6e36570eaede  astlinux-trunk-2246.run

real	0m1.264s
user	0m1.156s
sys	0m0.107s

pbxrunnix os # time openssl sha1 astlinux-0.6.2.run
SHA1(astlinux-0.6.2.run)= fdd32688fb60dede38ffbbf4694e78652105bb27

real	0m0.680s
user	0m0.582s
sys	0m0.097s

pbxrunnix os # time openssl sha1 astlinux-trunk-2246.run
SHA1(astlinux-trunk-2246.run)= 6c9e64284a19fcac4fd6a727de7a6e36570eaede

real	0m0.657s
user	0m0.571s
sys	0m0.085s
pbxrunnix os #

Michael

--
Email: mailto:mk...@we...

Devs,

I thought it would be interesting to create a timeline of the startup  
process.

This is on a net5501 512M/500MHz, trunk-2244.
Default packages minus Rhino and Wanpipe

Time    Action
(secs)

000    POST

007    Runnix Starts

032    Verify Image - start
050    Done - 18 seconds

058    Copy Image - start
076    Done - 18 seconds

093    Start ntpd

106    login:

Another interesting tidbit:

pbx ~ # time sha1sum /oldroot/cdrom/os/astlinux-trunk-2244.run
6924da20d08ce508a60234d312987f864c21ecc6  /oldroot/cdrom/os/astlinux- 
trunk-2244.run

real	0m14.476s
user	0m0.568s
sys	0m1.568s

pbx ~ # time openssl sha1 /oldroot/cdrom/os/astlinux-trunk-2244.run
SHA1(/oldroot/cdrom/os/astlinux-trunk-2244.run)=  
6924da20d08ce508a60234d312987f864c21ecc6

real	0m2.031s
user	0m0.290s
sys	0m0.011s

Possibly a little hardware crypto helping out openssl here?

But, on a 0.6 build a few months old:

voip ~ # time sha1sum /oldroot/cdrom/os/astlinux-0.6-1976.run
7b5f7518950f21e40811d84ae21e73dc2fb0d111  /oldroot/cdrom/os/ 
astlinux-0.6-1976.run

real	0m3.977s
user	0m3.814s
sys	0m0.153s

voip ~ # time openssl sha1 /oldroot/cdrom/os/astlinux-0.6-1976.run
SHA1(/oldroot/cdrom/os/astlinux-0.6-1976.run)=  
7b5f7518950f21e40811d84ae21e73dc2fb0d111

real	0m1.683s
user	0m1.528s
sys	0m0.151s

Possibly the SHA1 time depends on the data as much as how much data?
---
Lonnie

Several of the developers spent about 3 hours on a conference call today 
to discuss the current status of the project and plans for the next 
year.  I believe the last one of these was about 18 months ago (going 
from memory).

Here's a brief overview of the areas we touched:

1).  rc.conf will be cleaned up to remove unused variables.

2)  Variable separators should use ~ instead of : to prevent problems 
with IPV6

3).  AUTOMODS vs rc.modules.  we need to find a way for both to work or 
possibly remove/autogenerate the file.

4).  Add a 'functions' script in /etc/init.d to handle various 
non-script specific functions.

5).  Use the Bug Tracker on Source Forge to better track and manage 
requests and bugs

6).  Review DMZ support to verify that Arno's firewall handles all 
situations currently used in astfw.

7).  Remove obsolete/unnecessary packages (why would we ever need xorg 
or tinyx?)

8).  Darrick will continue to maintain the 0.6 stable branch and 
releases.  We need to establish a length of time that each branch will 
be maintained.

9).  ISDN support will likely remain using misdn v1 through the 0.7 
release cycle.  If someone who uses ISDN can assist/explain the 
benefits/risks of each of the different ISDN implementations it would 
greatly help the developers.  We'd like to make an informed decision, 
but need to know how the parts all fit together.  After 0.7 is branched 
from trunk, we can do a version bump on the kernel again to reach a 
version which will contain native ISDN kernel support (MISDNv2--I believe).

10).  We discussed several ideas related to speeding up the boot cycle. 
  Having runnix run in 'quiet' mode where no output is sent to the 
console, perhaps using md5sum instead of sha1sum

11).  We'll continue to monitor uClibc version upgrades.  It's likely 
we'll upgrade to 0.9.30 AFTER branching 0.7, but that's going to be a 
huge undertaking.

12).  Kristian is going to look at adding support to runnix for memtest 
and a 'rescue' mode which will drop to a shell to allow things like 
filesystem maintenance.

I'm sure there were other items mentioned that I may have missed.  3 
hours is a long time!

If Kristian's recording worked properly, we may be able to post part of 
the call at some point in the future.

Looks like we have a full year ahead of us in 2009.

Darrick

Michael Keuter wrote:
>>>>  > But all the trunk-images I build are named 
>>>> "astlinux-trunk-" without a number.
>>>>  >
>>>>
>>>> That might be a regression introduced in 2196 and fixed in 2239.
>>>>
>>>> Looking...
>>>>         
>>> Thanks, in 2239 it works well.
>>>       
>> But not for a long time. After a few new builds it's again  "astlinux-trunk-"
>> svn info shows the correct version:
>> ----------------
>> svn info
>> Pfad: .
>> URL: https://astlinux.svn.sourceforge.net/svnroot/astlinux/trunk
>> Basis des Projektarchivs: 
>> https://astlinux.svn.sourceforge.net/svnroot/astlinux
>> UUID des Projektarchivs: 57edc7d3-a90e-0410-b364-91459a37fc5a
>> Revision: 2241
>> Knotentyp: Verzeichnis
>> Plan: normal
>> Letzter Autor: abelbeck
>> Letzte geänderte Rev: 2241
>> Letztes Änderungsdatum: 2008-12-28 06:18:57 +0100 (So, 28 Dez 2008)
>> ---------------------
>>
>> Another thing I found out: if I disable  "Create 
>> bootable ISO" in Target Options (to save time) I 
>> get errors regarding Syslinux.
>>     
>
> I found this in in toolchain/astrelease/astrelease.mk
> --------------------------------
> ######################################################################
> #
> # Make a release for AstLinux
> #
> ######################################################################
>
> ASTURL= $(shell svn info | grep URL | cut -d" " -f2)
> ASTBASE= $(shell basename $(ASTURL))
> ASTREV= $(shell svn info | grep 'Last Changed Rev' | cut -d" " -f4)
> ----------------------------------
> My system language is "de_DE.UTF-8"
>
> I don't know how it's in other languages, but the 
> line "Revision: 2241" is in German the same as in 
> English.
>
> Michael
>
>   

Alas, it's using the line:

Letzte geänderte Rev: 2239

("Last Changed Rev") as you can see above.  I suggest building with LANG=C.

-Philip

>>>  > But all the trunk-images I build are named 
>>>"astlinux-trunk-" without a number.
>>>  >
>>>
>>>That might be a regression introduced in 2196 and fixed in 2239.
>>>
>>>Looking...
>>
>>Thanks, in 2239 it works well.
>
>But not for a long time. After a few new builds it's again  "astlinux-trunk-"
>svn info shows the correct version:
>----------------
>svn info
>Pfad: .
>URL: https://astlinux.svn.sourceforge.net/svnroot/astlinux/trunk
>Basis des Projektarchivs: 
>https://astlinux.svn.sourceforge.net/svnroot/astlinux
>UUID des Projektarchivs: 57edc7d3-a90e-0410-b364-91459a37fc5a
>Revision: 2241
>Knotentyp: Verzeichnis
>Plan: normal
>Letzter Autor: abelbeck
>Letzte geänderte Rev: 2241
>Letztes Änderungsdatum: 2008-12-28 06:18:57 +0100 (So, 28 Dez 2008)
>---------------------
>
>Another thing I found out: if I disable  "Create 
>bootable ISO" in Target Options (to save time) I 
>get errors regarding Syslinux.

I found this in in toolchain/astrelease/astrelease.mk
--------------------------------
######################################################################
#
# Make a release for AstLinux
#
######################################################################

ASTURL= $(shell svn info | grep URL | cut -d" " -f2)
ASTBASE= $(shell basename $(ASTURL))
ASTREV= $(shell svn info | grep 'Last Changed Rev' | cut -d" " -f4)
----------------------------------
My system language is "de_DE.UTF-8"

I don't know how it's in other languages, but the 
line "Revision: 2241" is in German the same as in 
English.

Michael

--
Email: mailto:mk...@we...

Asterisk-gui supports 1.6 also. 

 
Ron Byer Jr.
NetWeave Integrated Solutions, Inc.
+1.732.786.8830 x120
 
-----Original Message-----
From: Stephen Erisman [mailto:ser...@se...] 
Sent: Monday, December 29, 2008 12:06 PM
To: AstLinux Developers Mailing List
Subject: Re: [Astlinux-devel] Agenda?


> Philip Prindeville wrote:
>   
[snip]
> *** Release 0.8 ***
>
> Get rid of /mnt/kd, /stat, and /tmp/etc ...
>
> Bump to Asterisk 1.6
>   
I thought I read somewhere that the asterisk-gui web interface is only 
available for Asterisk 1.4.  Is that outdated information?  Or, assuming 
that is still correct, do we have a plan to use something else when 
upgrading to 1.6?

-Steve

----------------------------------------------------------------------------
--
_______________________________________________
Astlinux-devel mailing list
Ast...@li...
https://lists.sourceforge.net/lists/listinfo/astlinux-devel

Donations to support AstLinux are graciously accepted via PayPal to
pa...@kr....

No virus found in this incoming message.
Checked by AVG. 
Version: 7.5.552 / Virus Database: 270.10.1/1867 - Release Date: 12/28/2008
2:23 PM
 

Stephen Erisman wrote:
> Philip Prindeville wrote:
>   
>> On a somewhat related note...
>>
>> I have a Phenom 9950 quad proc (2.6GHz) w/ 8GB, and 2TB of disk...  I'm
>> installing a 3ware 9650SE 4-ch RAID controller (RAID 0, 1, or 5).
>>   
>>     
> How many physical disks?  What speed, etc?
>   

4X Seagate Barracuda's WD5000AAKS...

Plus a spare in a box...


>> I haven't finished setting up the RAID yet.
>>
>> I'm thinking we could use it as a communal build server.
>>
>> The downside is that I'm limited to 1.5Mb/s x 896Kb/s.
>>
>> Anyone want to help get the machine up and running production?
>>
>> -Philip
>>   
>>     
>
> What kind of help are you looking for on this machine?
>
> -Steve
>   

Just trying to get it configured for decent performance... tuning. I'm
not a power sysadmin any more.

-Philip

Philip Prindeville wrote:
> Here are some thoughts I had:
>
> *** Release 0.7 ***
>
> Fix targets in toolchain to depend on each other in proper order (i.e.
> kernel-headers or whatever)... this will speed up parallel builds (-j8)
> on multicores...
>
> Fix packages to depend on "toolchain" target.
>
> Populate "toolchain" target.
>
> Fix packages to compile using linux headers from STAGING_DIR (and set
> LINUX_HEADERS_DIR to this?)!
>
> Scrub $LINUX_DIR out of packages.
>
> Fix all makefiles to rely on have.<native-command> i.e. have.nasm, etc.
>
> Get hostapd working.
>
> Get road-warrior IPSec working.
>
> Bump to Arno's firewall 1.9.0 and kill off astfw and converge on common
> variable names?
>
> *** Release 0.8 ***
>
> Get rid of /mnt/kd, /stat, and /tmp/etc ...
>
> Bump to Asterisk 1.6
>
>   
One other thing to consider for one of these releases is adding some 
cpu/network graphs.  I sent an email about this a couple of days ago, 
and will be looking into it in the next couple of days (or next week at 
the latest).

-Steve

>>  > But all the trunk-images I build are named 
>>"astlinux-trunk-" without a number.
>>  >
>>
>>That might be a regression introduced in 2196 and fixed in 2239.
>>
>>Looking...
>
>Thanks, in 2239 it works well.

But not for a long time. After a few new builds it's again  "astlinux-trunk-"
svn info shows the correct version:
----------------
svn info
Pfad: .
URL: https://astlinux.svn.sourceforge.net/svnroot/astlinux/trunk
Basis des Projektarchivs: https://astlinux.svn.sourceforge.net/svnroot/astlinux
UUID des Projektarchivs: 57edc7d3-a90e-0410-b364-91459a37fc5a
Revision: 2241
Knotentyp: Verzeichnis
Plan: normal
Letzter Autor: abelbeck
Letzte geänderte Rev: 2241
Letztes Änderungsdatum: 2008-12-28 06:18:57 +0100 (So, 28 Dez 2008)
---------------------

Another thing I found out: if I disable  "Create 
bootable ISO" in Target Options (to save time) I 
get errors regarding Syslinux.

Michael

--
Email: mailto:mk...@we...

More grist for the mill...

Get memtest working.  :-)

Get a "recover" menu item working for syslinux to drop us into initrd
with a shell in single-user mode ("shell").

Philip Prindeville wrote:
> On a somewhat related note...
>
> I have a Phenom 9950 quad proc (2.6GHz) w/ 8GB, and 2TB of disk...  I'm
> installing a 3ware 9650SE 4-ch RAID controller (RAID 0, 1, or 5).
>   
How many physical disks?  What speed, etc?
> I haven't finished setting up the RAID yet.
>
> I'm thinking we could use it as a communal build server.
>
> The downside is that I'm limited to 1.5Mb/s x 896Kb/s.
>
> Anyone want to help get the machine up and running production?
>
> -Philip
>   

What kind of help are you looking for on this machine?

-Steve

> Philip Prindeville wrote:
>   
[snip]
> *** Release 0.8 ***
>
> Get rid of /mnt/kd, /stat, and /tmp/etc ...
>
> Bump to Asterisk 1.6
>   
I thought I read somewhere that the asterisk-gui web interface is only 
available for Asterisk 1.4.  Is that outdated information?  Or, assuming 
that is still correct, do we have a plan to use something else when 
upgrading to 1.6?

-Steve

Michael Keuter wrote:
>> Here are some thoughts I had:
>>
>> *** Release 0.7 ***
>>
>> Fix targets in toolchain to depend on each other in proper order (i.e.
>> kernel-headers or whatever)... this will speed up parallel builds (-j8)
>> on multicores...
>>
>> Fix packages to depend on "toolchain" target.
>>
>> Populate "toolchain" target.
>>
>> Fix packages to compile using linux headers from STAGING_DIR (and set
>> LINUX_HEADERS_DIR to this?)!
>>
>> Scrub $LINUX_DIR out of packages.
>>
>> Fix all makefiles to rely on have.<native-command> i.e. have.nasm, etc.
>>
>> Get hostapd working.
>>
>> Get road-warrior IPSec working.
>>
>> Bump to Arno's firewall 1.9.0 and kill off astfw and converge on common
>> variable names?
>>     
>
> Hi Philip,
>
> nice summary.
> What's about the latest busybox and uClibc (0.9.30) updates as on the 
> Astinux wishlist?
>
> Michael
>
>   

Darrick is tracking uClibc.

We're having our developer conference call right now.

-Philip

On a somewhat related note...

I have a Phenom 9950 quad proc (2.6GHz) w/ 8GB, and 2TB of disk...  I'm
installing a 3ware 9650SE 4-ch RAID controller (RAID 0, 1, or 5).

I haven't finished setting up the RAID yet.

I'm thinking we could use it as a communal build server.

The downside is that I'm limited to 1.5Mb/s x 896Kb/s.

Anyone want to help get the machine up and running production?

-Philip

Actually, I should have updated this list...

hostapd works, sort of...  WPA-PSK (WPA2) works...  I could add a little
code to handle WEP as well.

Adding additional SSIDs and VLANs doesn't work yet...  I've not seen a
working example of how to do this.

I've started to add some of the host.X prerequisites.

Also, do we want to stay on 2.6.26?  Or bump to 2.6.27 or 2.6.28?

Also, the 0.8 BOM could actually be a 0.7.2 or 0.7.3 release instead.



Philip Prindeville wrote:
> Here are some thoughts I had:
>
> *** Release 0.7 ***
>
> Fix targets in toolchain to depend on each other in proper order (i.e.
> kernel-headers or whatever)... this will speed up parallel builds (-j8)
> on multicores...
>
> Fix packages to depend on "toolchain" target.
>
> Populate "toolchain" target.
>
> Fix packages to compile using linux headers from STAGING_DIR (and set
> LINUX_HEADERS_DIR to this?)!
>
> Scrub $LINUX_DIR out of packages.
>
> Fix all makefiles to rely on have.<native-command> i.e. have.nasm, etc.
>
> Get hostapd working.
>
> Get road-warrior IPSec working.
>
> Bump to Arno's firewall 1.9.0 and kill off astfw and converge on common
> variable names?
>
> *** Release 0.8 ***
>
> Get rid of /mnt/kd, /stat, and /tmp/etc ...
>
> Bump to Asterisk 1.6
>
>
>   

>Here are some thoughts I had:
>
>*** Release 0.7 ***
>
>Fix targets in toolchain to depend on each other in proper order (i.e.
>kernel-headers or whatever)... this will speed up parallel builds (-j8)
>on multicores...
>
>Fix packages to depend on "toolchain" target.
>
>Populate "toolchain" target.
>
>Fix packages to compile using linux headers from STAGING_DIR (and set
>LINUX_HEADERS_DIR to this?)!
>
>Scrub $LINUX_DIR out of packages.
>
>Fix all makefiles to rely on have.<native-command> i.e. have.nasm, etc.
>
>Get hostapd working.
>
>Get road-warrior IPSec working.
>
>Bump to Arno's firewall 1.9.0 and kill off astfw and converge on common
>variable names?

Hi Philip,

nice summary.
What's about the latest busybox and uClibc (0.9.30) updates as on the 
Astinux wishlist?

Michael

--
Email: mailto:mk...@we...

Here are some thoughts I had:

*** Release 0.7 ***

Fix targets in toolchain to depend on each other in proper order (i.e.
kernel-headers or whatever)... this will speed up parallel builds (-j8)
on multicores...

Fix packages to depend on "toolchain" target.

Populate "toolchain" target.

Fix packages to compile using linux headers from STAGING_DIR (and set
LINUX_HEADERS_DIR to this?)!

Scrub $LINUX_DIR out of packages.

Fix all makefiles to rely on have.<native-command> i.e. have.nasm, etc.

Get hostapd working.

Get road-warrior IPSec working.

Bump to Arno's firewall 1.9.0 and kill off astfw and converge on common
variable names?

*** Release 0.8 ***

Get rid of /mnt/kd, /stat, and /tmp/etc ...

Bump to Asterisk 1.6

Well, in addition to the fact that high-resolution timers work better in
2.6.26, I also noticed that with DID and no voice menus, the one-way
voice issue I was experiencing on incoming calls has gone away...

Though I still get one-way voice on incoming calls if there's a
voice-menu before ringing to a handset.

This is with Asterisk (astlinux) running on the border gateway, SIP
trunking to the PSTN, and NATted handsets.

I'll stare at this some more and see if I can add code (in the form of a
stand-alone feature or app) to add NAT-snooping (via libnetfilter) to
Asterisk.

One other issue is that the 2.6.26 kernel seems to have repackaged how
wireless works.

There's CONFIG_CFG80211 and CONFIG_MAC80211, which we haven't enabled...
in addition to CONFIG_IEEE80211.

I've not had a chance to look into that.  Anyone know what the scoop is,
and if we can further optimize our kernel?  I'd like to not have
separate configurations in the hostapd stuff (like driver=) depending on
whether we're using madwifi drivers or not.

0.7 is shaping up nicely so far, and we should try to get it out soon
(no later than the end of February, hopefully).

The amount of functionality it will offer over 0.6.2 makes it worth the
push to get that out quickly.

-Philip

Philip Prindeville wrote:
> Darrick Hartman wrote:
>> Michael Keuter wrote:
>>> /* the folder should be not "linux" but "linux-2.6.26.8-astlinux" */
>>>     
>> Actually, there should be a symbolic link pointing "linux" to the 
>> specific kernel version.  If this was removed, it should be replaced--If 
>> it was removed, it was only removed in trunk and probably unintentionally
>>   
> 
> Actually, it was intentional.  Makefiles should pass in the path to
> their Linux environment explicitly.
> 
> Assuming it's in ~/build_i586/linux (or /usr/src/linux or anywhere else)
> is wrong.

I agree with you, however, if you look at most linux distributions, they 
will almost always link /usr/src/linux to the current version of the 
linux source.  I really don't see the harm in the symbolic link, 
especially since some packages rely on it.  Unless you're going to fix 
the packages, don't remove the link (although I know you had to remove 
the link to see what breaks).

I have no problem with you leaving the symbolic link out IF you can 
prove that all packages can work with the explicit version AND all 
packages are fixed to show that change.

Darrick

>  > But all the trunk-images I build are named "astlinux-trunk-" 
>without a number.
>>  
>
>That might be a regression introduced in 2196 and fixed in 2239.
>
>Looking...

Thanks, in 2239 it works well.

Michael

--
Email: mailto:mk...@we...