astlinux-devel Mailing List for AstLinux

Philip,

buildroot is a bit generic and has some different goals.  Kris 
implemented several patches to optimize things for our purpose.  Some of 
those patches need to be reviewed as we do updates to the kernel, uClibc 
and a few others.  The bottom line is, we can look to the other projects 
for ideas, but we've diverged so far in many cases that it would be 
difficult to completely sync back to the buildroot source.

Openwrt is an entirely different beast.  They've completely changed 
their implementation too and use ipkg to install individual packages.  I 
don't want to go down that route.

For trunk, we can look at removing some of the symlinks and relying more 
on unionfs.  The backup then would be of the unionfs partition and not 
of the '/mnt/kd' partition.  That's going to be a huge overhaul though 
and might be best tested in it's own branch separate of the other 
updates to trunk.

Darrick

Philip Prindeville wrote:
> I'd like for us to try to reconverge on the buildroot or openwrt 
> projects so that we can pick up their fixes and do less work ourselves 
> (or rather, spend the time on work that someone else hasn't already done).
> 
> We've diverged a bit from buildroot, of course.
> 
> A good deal of it having to do with our extensive use of the key-disk.
> 
> Now that we have unionfs abstracting a lot of this, can we get rid of 
> the hacked paths and just have the files be in place, like 
> "/etc/ppp/options.xxx" instead of this being a symlink to /tmp/etc/ppp/ 
> etc.?
> 
> I've brought this up a couple of times, but no one seems to want to 
> weigh in either for or against...
> 
> Thanks,
> 
> -Philip
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> 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....

-- 
Darrick Hartman
DJH Solutions, LLC
http://www.djhsolutions.com
Small Business IT Specialists

I'd like for us to try to reconverge on the buildroot or openwrt 
projects so that we can pick up their fixes and do less work ourselves 
(or rather, spend the time on work that someone else hasn't already done).

We've diverged a bit from buildroot, of course.

A good deal of it having to do with our extensive use of the key-disk.

Now that we have unionfs abstracting a lot of this, can we get rid of 
the hacked paths and just have the files be in place, like 
"/etc/ppp/options.xxx" instead of this being a symlink to /tmp/etc/ppp/ 
etc.?

I've brought this up a couple of times, but no one seems to want to 
weigh in either for or against...

Thanks,

-Philip

Well, now that we have unionfs working fairly solidly (including the 
/lib/modules copying issue being fixed... never understood what the root 
cause of that was, btw)...  I'm wondering if it's not a good time to try 
the magician-and-the-tablecloth trick and yank out all the symlink stuff 
that goes on with /etc/ and the config files.

I did a quick count: there's about 50+ files that have "/tmp/etc" in 
them.  That's not too many.

I could do a build of a system with all of those links yanked out.  Who 
would like to test it?

The only thing is that certain files get created every time at reboot, 
and perhaps those should continue to exist in /tmp?

On the other hand, having them exist on CF would make them persistent, 
so that if a box crashed and we rebooted single-user, we could look at 
the files before they got rewritten and try to figure out what happened...

Of course, rewriting a file once-per-reboot shouldn't wear out flash 
anyway... so it's perhaps a moot point.

Thoughts?

Would anyone volunteer to test images built without /tmp/etc and symlink 
madness?

-Philip

target/generic/skel.tar.gz
target/generic/target_skeleton/usr/sbin/genkd
target/generic/target_skeleton/usr/sbin/genunion
target/generic/target_skeleton/usr/sbin/gen-rc-conf
target/generic/target_skeleton/stat/etc/rc.conf
target/generic/target_skeleton/etc/rc
target/generic/target_skeleton/etc/init.d/nfsd
target/generic/target_skeleton/etc/init.d/inetd
target/generic/target_skeleton/etc/init.d/misc
target/generic/target_skeleton/etc/init.d/network
target/generic/target_skeleton/etc/udhcpc.script
package/dnsmasq/dnsmasq.mk
package/dnsmasq/dnsmasq.init
package/openssh/openssh.mk
package/openssh/sshd.init
package/radvd/radvd.mk
package/asterisk/asterisk.mk
package/asterisk/asterisk.init
package/wanpipe/wanpipe.mk
package/wanpipe/wanrouter.init
package/ntp/ntp.mk
package/ntp/ntpd.init
package/stunnel/stunnel.init
package/stunnel/stunnel.mk
package/lmsensors/lmsensors.init
package/openser/openser.init
package/openser/openser.mk
package/apcupsd/apcupsd.mk
package/apcupsd/apcupsd.init
package/inadyn/inadyn.mk
package/inadyn/inadyn.init
package/minihttpd/minihttpd.mk
package/minihttpd/mini_httpd.init
package/zabbix/zabbix.init
package/wireless-tools/wireless-tools.mk
package/zaptel/zaptel.mk
package/zaptel/zaptel.init
package/ipsec-tools/ipsec-tools.mk
package/ipsec-tools/racoon.init
package/msmtp/msmtp.mk
package/iptables/iptables.init
package/hostap/hostapd.init
package/hostap/hostap.mk
package/iaxmodem/iaxmodem.init
package/vsftpd/vsftpd.init
package/vsftpd/vsftpd.mk
package/openntpd/openntpd.mk
package/openntpd/ntpd.init
package/pppd/pppd.mk
package/openvpn/openvpn.init
package/openvpn/openvpn.mk
package/netsnmp/netsnmp.mk
package/netsnmp/netsnmp.init

Well, I noticed there are about 10 packages that could use readline but 
don't.

I worked over the weekend on getting it to build and install headers, 
and shared and archival libraries into staging_dir (headers in 
staging_dir/usr/include/readline, libraries into staging_dir/lib), and 
shared libraries into root (root/lib).

However, getting bash to link against it proved non-trivial...  I tried 
adding:

--with-installed-readline=$(STAGING_DIR)

to Bash's ./configure in the package makefile (package/bash/bash.mk), 
but that didn't do it... it can't detect the version number apparently 
when cross-compiling.  So I added:

  ac_cv_rl_version=5.2

to the environment vars passed into configure, but that didn't work either.

It silently fails, and uses the builtin version.

If someone wants to look at this (or ntp, or php, any of the other 
packages that can link against readline), I can work with them...  in 
the meantime, I'm going to be breaking uClibc, the kernel, wifi, IPSec, 
Arno's firewall...

Thanks,

-Philip

Kristian,

I can revert it, but it builds fine and has built fine on my personal 
box.  I'll leave it in trunk, but remove it from 0.6.

Darrick

Kristian Kielhofner wrote:
> On Mon, Sep 8, 2008 at 12:02 AM,  <dha...@us...> wrote:
>> Revision: 1941
>>          http://astlinux.svn.sourceforge.net/astlinux/?rev=1941&view=rev
>> Author:   dhartman
>> Date:     2008-09-08 04:02:05 +0000 (Mon, 08 Sep 2008)
>>
>> Log Message:
>> -----------
>> add support for zabbix agent daemon
>>
> 
> I don't think zabbix should be in 0.6:
> 
> - It's a new feature
> - It's not widely tested (doesn't get past ./configure on my machine)
> - It doesn't appear to support cross-compiling very well.  The
> autoconf script makes several assumptions about the host and target
> and will (probably) need several ac_* style overrides from us to
> properly support AstLinux.
> 
>   I think parts of 1939 and 1941 should be reverted.
> 

-- 
Darrick Hartman
DJH Solutions, LLC
http://www.djhsolutions.com
Small Business IT Specialists
Office:  920.547.4535
   Cell:  920.901.3113

On Mon, Sep 8, 2008 at 12:02 AM,  <dha...@us...> wrote:
> Revision: 1941
>          http://astlinux.svn.sourceforge.net/astlinux/?rev=1941&view=rev
> Author:   dhartman
> Date:     2008-09-08 04:02:05 +0000 (Mon, 08 Sep 2008)
>
> Log Message:
> -----------
> add support for zabbix agent daemon
>

I don't think zabbix should be in 0.6:

- It's a new feature
- It's not widely tested (doesn't get past ./configure on my machine)
- It doesn't appear to support cross-compiling very well.  The
autoconf script makes several assumptions about the host and target
and will (probably) need several ac_* style overrides from us to
properly support AstLinux.

  I think parts of 1939 and 1941 should be reverted.

-- 
Kristian Kielhofner
http://blog.krisk.org

Let's see....

Bump Arno's firewall to 1.9.0

DSCP traffic queuing

Make wireless more automated/secure.


Darrick Hartman wrote:
> Here are a list of things that I can think of us wanting to change 
> shortly in trunk:
>
> busybox bump to latest stable (1.11.2 now--I'm testing now)  There are a 
> few new options including findfs which can be built into the initrd 
> version of busybox for sure and trim the size down again.
>
> Kernel bump to latest stable that works with zaptel
>
> Remain with Zaptel until Rhino and Sangoma support Dahdi--Rhino has 
> something in testing right now.
>
> Update kernel configs
>
> Update uClibc.  I believe there is a newer version which is stable.
>
> Update misdn code
>
> Upgrade openssl to 0.9.8 latest
>
> Add IP-Sec road warrior configuration
>
> I've noted these and a few more ideas on this page:
>
> http://www.astlinux.org/node/31
>
> Any other things we need to put on this list?
>
> Darrick
>   

Hi Darrick,

Personally, I would like to see jabber and curl support added. This 
would enable me to produce a version of astlinux that does not need any 
local conf files to be changed, as all the conf could be grabbed from a 
web server.

Being able to use a local disk (usb or internal) for voice recording 
would be useful.

Julian

Darrick Hartman wrote:
> Here are a list of things that I can think of us wanting to change 
> shortly in trunk:
> 
> busybox bump to latest stable (1.11.2 now--I'm testing now)  There are a 
> few new options including findfs which can be built into the initrd 
> version of busybox for sure and trim the size down again.
> 
> Kernel bump to latest stable that works with zaptel
> 
> Remain with Zaptel until Rhino and Sangoma support Dahdi--Rhino has 
> something in testing right now.
> 
> Update kernel configs
> 
> Update uClibc.  I believe there is a newer version which is stable.
> 
> Update misdn code
> 
> Upgrade openssl to 0.9.8 latest
> 
> Add IP-Sec road warrior configuration
> 
> I've noted these and a few more ideas on this page:
> 
> http://www.astlinux.org/node/31
> 
> Any other things we need to put on this list?
> 
> Darrick
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> 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....
> 

Here are a list of things that I can think of us wanting to change 
shortly in trunk:

busybox bump to latest stable (1.11.2 now--I'm testing now)  There are a 
few new options including findfs which can be built into the initrd 
version of busybox for sure and trim the size down again.

Kernel bump to latest stable that works with zaptel

Remain with Zaptel until Rhino and Sangoma support Dahdi--Rhino has 
something in testing right now.

Update kernel configs

Update uClibc.  I believe there is a newer version which is stable.

Update misdn code

Upgrade openssl to 0.9.8 latest

Add IP-Sec road warrior configuration

I've noted these and a few more ideas on this page:

http://www.astlinux.org/node/31

Any other things we need to put on this list?

Darrick