devil-linux-develop — developer discussions

[Devil-linux-develop] [fmII] PostgreSQL 7.3.3 released (Stable branch)

[<no...@fr...>]

This email is to inform you about the release of version '7.3.3' of
'PostgreSQL' through freshmeat.net. All URLs and other useful information
can be found at

    http://freshmeat.net/projects/pgsql/

The changes in this release are as follows:
This version fixes many small bugs found since 7.3.2 was released, and
has improvements to the JDBC driver. 

Project description:
PostgreSQL is a robust, next-generation, Object-Relational DBMS
(ORDBMS), derived from the Berkeley Postgres database management
system. While PostgreSQL retains the powerful object-relational data
model, rich data types and easy extensibility of Postgres, it
replaces the PostQuel query language with an extended subset of SQL. 

If you would like to cancel subscription to releases of this project,
login to freshmeat.net and choose 'home' from the personal menubar at the
top of the page. You'll be presented with a list of projects you're
subscribed to in the right column, which you may cancel by highlighting
the project in question and clicking the 'delete' button.

Sincerely,
freshmeat.net 
 
____________________________| Advertising |____________________________
XML Parser for Java is a validating XML parser & 

processor written in 100% pure Java; it is a library for parsing &
generating XML documents. Easily enables an application to read and write
XML data. Free download:
 

http://www.alphaworks.ibm.com/tech/xml4j/?open&ca=dpi-frmeat 
____________________________| Advertising |____________________________

Re: [Devil-linux-develop] USB HostAP and code contribution (was Re: Embedded Devil Linux)

[John K. <jk...@sa...>]

On Sun, 2003-06-22 at 18:13, Friedrich Lobenstock wrote:
> Hi!
> 
> John Kiss wrote:
> > 	One other thing I have that you guys are probably not interested in but
> > I'll mention it anyways is a modified HostAP which supports PrismII USB
> > dongles.  
> 
> I'd know one who'd be longing for such a thing. Thomas wouldn't you?
> 
> 
> > The biggest disadvantage of using this, that I can think of, is 
> > disable ESSID broadcasts...
> 
> I would not call a security feature a disadvantage.

	Whoooops.. Should have said.. Disable Broadcast ESSID is not included..
But your right it not a disadvantage.. It's a hazard =)...
 
> 
> 
> > 	Anyways just let me know what you guys want, and a brief discription of
> > how to contribute patches to the group.
> 
> As said before if you change something then create a patch relative
> to the build directoy, eg. when you are at /data/build in the LFS
> chroot via "cvs diff -u [optinal single filename]".
> 
> New additions (scripts and sources) are better distributed as tar.gz/bz2
> as a patch is useless in this case. Also relative to the aformentioned
> path.
-- 
John Kiss <jk...@sa...>

[Devil-linux-develop] USB HostAP and code contribution (was Re: Embedded Devil Linux)

[Friedrich L. <fl...@fl...>]

Hi!

John Kiss wrote:
> 	One other thing I have that you guys are probably not interested in but
> I'll mention it anyways is a modified HostAP which supports PrismII USB
> dongles.  

I'd know one who'd be longing for such a thing. Thomas wouldn't you?


> The biggest disadvantage of using this, that I can think of, is 
> disable ESSID broadcasts...

I would not call a security feature a disadvantage.


> 	Anyways just let me know what you guys want, and a brief discription of
> how to contribute patches to the group.

As said before if you change something then create a patch relative
to the build directoy, eg. when you are at /data/build in the LFS
chroot via "cvs diff -u [optinal single filename]".

New additions (scripts and sources) are better distributed as tar.gz/bz2
as a patch is useless in this case. Also relative to the aformentioned
path.

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: Embedded Devil Linux (was Re: [Devil-linux-develop] Re: uClibc)

[John K. <jk...@sa...>]

On Sun, 2003-06-22 at 16:25, Heiko Zuerker wrote:
> I have nothing to add here, I fully agree with Friedrich.
> 
> Oh guys, I see such a bright future......
> 
> cya
>    Heiko
> 
> 
> Friedrich Lobenstock wrote:
> > Hello John!
> > 
> > John Kiss wrote:
> > 
> >>     Not really, Devil-Linux is already running on an embedded platform
> >> running an ELAN processor, a firewalled gateway. 
> > 
> > 
> > Sounds superb.
> > 
> > 
> >> The only problem is
> >> that a make iso doesn't work for this target and I have to do a manual
> >> conversion and put it on a disk space diet.  I just want to make life
> >> easier by adding an entry into the menuconfig that selects the target
> >> media, ISO, CF or JFFS2. This option would change certain build
> >> variables, eg. PACKAGEDIR. Also certain variable names may need to be
> >> changed or others added since CDDIR and ISODIR are very specific.
> > 
> > 
> > If you could convert your manual conversion into a script and finally
> > into a patch or just a tar.gz if it's a new addition this would be
> > very much appreciated.
> > 
> > 
> >>     There are lots of other items that need to be considered for embedded
> >> targets such as: not all will need to build individual packages or
> >> installing only required files to save disk space.. I can go on and on
> >> but we can save this for a more specific discussion when we're ready. 
> > 
> > 
> > May you could at first add a menu option target with the options 
> > "normal" and
> > "embedded" with the suboptions "CD" (only if normal), "compact flash", 
> > "...."
> > and then keep working on your stuff.
> > 
> > 
> >>     Also at some point in the future I'll be requesting a CVS account 
> >> (for
> >> R/W access) so I can check in. 
> > 
> > 
> > Of course, but first it would be good if you showed us your
> > competence and professionality via contribution of patches and your
> > contribution on the mailinglist.
> > 

	Not even a challenge to prove myself... I've been watching this mailing
list for about a month now and just like you'll be watching me, I've
already been watching you ;-).. No I'm not a coding pervert, I'm just
careful where I spend my time.

	The only patches I can think of to add right away are:

	*BOA 		- embedded web server
	*SHOREWALL	- IPTABLES Firewall
	
	* And of course eventually a script that would convert the ISO
directory to a Compact Flash media.

	A few other things I'll be working on in the weeks to come.

	* APACHE
	* PHP 4.3.x

	When these are added I wanted to start work on a generic GPL'ed Web UI
for Devil Linux, with lots of input of course, unless someone is already
working on one?

	One other thing I have that you guys are probably not interested in but
I'll mention it anyways is a modified HostAP which supports PrismII USB
dongles.  It's based on the May 2002 release of HostAP and not the
lastest, last I checked was November 2002. Jouni, maintainer of HostAP,
has been given the patches, but has not released it yet.  The biggest
disadvantage of using this, that I can think of, is disable ESSID
broadcasts... Doesn't effect what I'm doing now but it will soon.  Test
usb dongles are ZCOM and the old LinkSys 2.5, not the 2.6.

	Anyways just let me know what you guys want, and a brief discription of
how to contribute patches to the group.

> > As of now I would very much consider you as one of our next
> > additions to our team ;-)
> > 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
-- 
John Kiss <jk...@sa...>

Re: [Devil-linux-develop] Re: uClibc

[Heiko Z. <he...@zu...>]

John Kiss wrote:
> 	Not really, Devil-Linux is already running on an embedded platform
> running an ELAN processor, a firewalled gateway.  The only problem is
> that a make iso doesn't work for this target and I have to do a manual
> conversion and put it on a disk space diet.  I just want to make life
> easier by adding an entry into the menuconfig that selects the target
> media, ISO, CF or JFFS2. This option would change certain build
> variables, eg. PACKAGEDIR. Also certain variable names may need to be
> changed or others added since CDDIR and ISODIR are very specific.

It probably would be a good idea to change those variable names in 
general, e.g. CDDIR = MEDIADIR

cya
   Heiko

Re: Embedded Devil Linux (was Re: [Devil-linux-develop] Re: uClibc)

[Heiko Z. <he...@zu...>]

I have nothing to add here, I fully agree with Friedrich.

Oh guys, I see such a bright future......

cya
   Heiko


Friedrich Lobenstock wrote:
> Hello John!
> 
> John Kiss wrote:
> 
>>     Not really, Devil-Linux is already running on an embedded platform
>> running an ELAN processor, a firewalled gateway. 
> 
> 
> Sounds superb.
> 
> 
>> The only problem is
>> that a make iso doesn't work for this target and I have to do a manual
>> conversion and put it on a disk space diet.  I just want to make life
>> easier by adding an entry into the menuconfig that selects the target
>> media, ISO, CF or JFFS2. This option would change certain build
>> variables, eg. PACKAGEDIR. Also certain variable names may need to be
>> changed or others added since CDDIR and ISODIR are very specific.
> 
> 
> If you could convert your manual conversion into a script and finally
> into a patch or just a tar.gz if it's a new addition this would be
> very much appreciated.
> 
> 
>>     There are lots of other items that need to be considered for embedded
>> targets such as: not all will need to build individual packages or
>> installing only required files to save disk space.. I can go on and on
>> but we can save this for a more specific discussion when we're ready. 
> 
> 
> May you could at first add a menu option target with the options 
> "normal" and
> "embedded" with the suboptions "CD" (only if normal), "compact flash", 
> "...."
> and then keep working on your stuff.
> 
> 
>>     Also at some point in the future I'll be requesting a CVS account 
>> (for
>> R/W access) so I can check in. 
> 
> 
> Of course, but first it would be good if you showed us your
> competence and professionality via contribution of patches and your
> contribution on the mailinglist.
> 
> As of now I would very much consider you as one of our next
> additions to our team ;-)
> 

Re: [Devil-linux-develop] Suggestion for better compiling.

[Bruce S. <bw...@ar...>]

> > We could find out for sure if there was some way to determine what arch
> > a pre-compiled binary was compiled for.  (I could check my i686 compiled
> > DL and see).  Except I don't know of any way to tell.  Does anyone know
> > of a way to tell?
> 
> 	I thought that using readelf would do it but it's displaying the same
> machine info for DL compiled binaries for a 486 and binaries compiled on
> my Mandrake which is compiled for i586.
> 
> 	If you do a readelf -a <binary name> you'll see at the very top of the
> listing elf header information.  One of the lines has.
> 
> "Machine : Intel 80386"
> 
> I would assume that this is where the -march=???? should go but doesn't
> appear to. It's always 80386.

Yes, that doesn't work.   I tried it on the same program I compiled two
different ways.  It displays the same for both.

I suppose we could specifically compile one with -march=i686 and again
without any -march options, and compare the two binaries.

> > For some applications it would make no difference.  But it can make a
> > big difference for some packages.  For example almost all programs use
> > glibc extensively, so it will help a lot there.  And it can help
> > stand-alone programs which are CPU intensive, like OpenSSL.
> > 
> > We could go through and modify the few packages it would help and forget
> > the rest (like Redhat does on their distribution).  Or do everything.
> > 
> 	I agree that it would affect some applications. If we do some packages
> then when lets keep in mind that one day all of them would be done too..
> Obviously starting with the packages that would have the most affect,
> can you think of any others packages other then glibc and openssl?

I used those two as examples because Redhat supplies multiple arch's for
those RPM's.

I suppose anything that does encryption or a lot of math could use it. 
OpenSSH, all the VPN packages, gnupg, ...

 - BS

Embedded Devil Linux (was Re: [Devil-linux-develop] Re: uClibc)

[Friedrich L. <fl...@fl...>]

Hello John!

John Kiss wrote:
> 	Not really, Devil-Linux is already running on an embedded platform
> running an ELAN processor, a firewalled gateway. 

Sounds superb.


> The only problem is
> that a make iso doesn't work for this target and I have to do a manual
> conversion and put it on a disk space diet.  I just want to make life
> easier by adding an entry into the menuconfig that selects the target
> media, ISO, CF or JFFS2. This option would change certain build
> variables, eg. PACKAGEDIR. Also certain variable names may need to be
> changed or others added since CDDIR and ISODIR are very specific.

If you could convert your manual conversion into a script and finally
into a patch or just a tar.gz if it's a new addition this would be
very much appreciated.


> 	There are lots of other items that need to be considered for embedded
> targets such as: not all will need to build individual packages or
> installing only required files to save disk space.. I can go on and on
> but we can save this for a more specific discussion when we're ready. 

May you could at first add a menu option target with the options "normal" and
"embedded" with the suboptions "CD" (only if normal), "compact flash", "...."
and then keep working on your stuff.


> 	Also at some point in the future I'll be requesting a CVS account (for
> R/W access) so I can check in. 

Of course, but first it would be good if you showed us your
competence and professionality via contribution of patches and your
contribution on the mailinglist.

As of now I would very much consider you as one of our next
additions to our team ;-)

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

[Devil-linux-develop] out of town

[Heiko Z. <he...@zu...>]

Hey folks,

I'll be out of town until June 30th. I'll checking my mail as often as 
possible.

cya
   Heiko

Re: [Devil-linux-develop] Re: uClibc

[John K. <jk...@sa...>]

On Sun, 2003-06-22 at 14:22, Heiko Zuerker wrote:
> John Kiss wrote:
> > 	Hey John,
> > 
> > 	I've already started on a uClibc verson of Devil Linux. And when I mean
> > started, it just means I've worked out the best way to start this
> > adventure and keeping it compatible with the big daddy distro of Devil
> > Linux.  I've scheduled this to start July 15th. I was also planning to
> > call this uDL or Micro Devil Linux. It will target not only PC's but
> > embedded targets and cross compilation for other micro processors as
> > well, eg. ARM.  Media types will include ISO, CompactFlash, SmartMedia
> > and JFFS2.
> > 
> > Steps Involved
> > 
> > 	1) Create a branch off of the main Devil Linux.
> > 		Of course after approval from the head DL developers
> > 	2) Create a new LFS system, build around uClibc and not glibc
> > 		* Also would be configured for cross compilation
> > 	3) Add the uClibc package into the source tree.
> > 	4) Compile Packages against uClibc and make any changes to 
> > 		build and source.
> > 		**** This is the hardest part.
> > 
> > 	I'll be putting together a project proposal to share with everyone on
> > the mailing list.
> > 
> > 	One question that may be asked is why, why start with Devil Linux? 
> > 	The answer is simple, the people/developers resonsible for putting
> > together the /build system have done an excellent job. It's simple, easy
> > to configure and change without huge structual changes.  The other
> > reason, last but not least, is the documentation on the website, that in
> > my opinion is what really makes DL progress.
> 
> I think it would make a lot of sense to incorporate those changes into 
> the main build system, you just select glibc or uclibc via "make 
> menuconfig". I'm pretty confident that it should be easy to incorporate 
> all those changes into our build system.
	Ohh for sure, why maintain two main branchs?? The only reason why I
suggested a branch is for development purposes. Once it's at a stage
that can compile both ISO and other media targets then it can be merged
into the mainline. This way Devil-Linux V1.x versions can continue to be
built with out uClibc or V2.0 developers breaking the builds.

> I also don't think it is necessary to create a new LFS System, all the 
> important parts (gcc, glibc, binutils) are compiled by us anyway. 
> Probably we just have to add a few more programs.
> The thing you would have problems with is the cross-compile. Currently 
> (only theoratical) the only way to compile for a different plattform is 
> to work on that plattform. OK, in that cause you'll need a new LFS system.
> 
	Bingo ;-)

> By incorporating those changes into the main build system, we all 
> benefit from eachothers developments and progress much faster then others.
> 
> We could define those changes as a goal for v2.0, I'm sure it'll take a 
> while until you get everything running.
> 
	Not really, Devil-Linux is already running on an embedded platform
running an ELAN processor, a firewalled gateway.  The only problem is
that a make iso doesn't work for this target and I have to do a manual
conversion and put it on a disk space diet.  I just want to make life
easier by adding an entry into the menuconfig that selects the target
media, ISO, CF or JFFS2. This option would change certain build
variables, eg. PACKAGEDIR. Also certain variable names may need to be
changed or others added since CDDIR and ISODIR are very specific.

	There are lots of other items that need to be considered for embedded
targets such as: not all will need to build individual packages or
installing only required files to save disk space.. I can go on and on
but we can save this for a more specific discussion when we're ready. 
	Also at some point in the future I'll be requesting a CVS account (for
R/W access) so I can check in. 

> cya
>    Heiko
> 
> P.S. Devil-Linux on a Linksys or Netgear Router.... sounds cool!

	Or even better, on a QuickBane Kincora Secured Gateway =)....

	Cheers
	John
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
-- 
John Kiss <jk...@sa...>

Re: [Devil-linux-develop] usb

[Bruce S. <bw...@ar...>]

> > Nope.  This is a real PC, not VMware.  I just followed these steps:
> > 
> > Fresh reboot with config on USB. (loads fine).
> > ssh into the PC, run save-config, wants to save to floppy, ctrl-C
> > unplug USB, plug in USB memory stick.
> > run lsmod - no usb modules listed.
> > run save-config - still wants to save to floppy - ctrl-C.
> 
> It works for me in VMWare and on *real* PCs. Is this a fairly new computer?

It's a HP Celeron 500.

> > Maybe you need to leave the modules for the USB core/controller?
> > I _think_ that's how Redhat does it, and they use hotplug.
> 
> That was causing problems. Looks like I have to force a re-load of the 
> modules in the boot script.

What exactly is "hotplug"?  
Is it a process that should be running?  (it's not)

 - BS

[Devil-linux-develop] Re: uClibc

[Heiko Z. <he...@zu...>]

John Kiss wrote:
> 	Hey John,
> 
> 	I've already started on a uClibc verson of Devil Linux. And when I mean
> started, it just means I've worked out the best way to start this
> adventure and keeping it compatible with the big daddy distro of Devil
> Linux.  I've scheduled this to start July 15th. I was also planning to
> call this uDL or Micro Devil Linux. It will target not only PC's but
> embedded targets and cross compilation for other micro processors as
> well, eg. ARM.  Media types will include ISO, CompactFlash, SmartMedia
> and JFFS2.
> 
> Steps Involved
> 
> 	1) Create a branch off of the main Devil Linux.
> 		Of course after approval from the head DL developers
> 	2) Create a new LFS system, build around uClibc and not glibc
> 		* Also would be configured for cross compilation
> 	3) Add the uClibc package into the source tree.
> 	4) Compile Packages against uClibc and make any changes to 
> 		build and source.
> 		**** This is the hardest part.
> 
> 	I'll be putting together a project proposal to share with everyone on
> the mailing list.
> 
> 	One question that may be asked is why, why start with Devil Linux? 
> 	The answer is simple, the people/developers resonsible for putting
> together the /build system have done an excellent job. It's simple, easy
> to configure and change without huge structual changes.  The other
> reason, last but not least, is the documentation on the website, that in
> my opinion is what really makes DL progress.

I think it would make a lot of sense to incorporate those changes into 
the main build system, you just select glibc or uclibc via "make 
menuconfig". I'm pretty confident that it should be easy to incorporate 
all those changes into our build system.
I also don't think it is necessary to create a new LFS System, all the 
important parts (gcc, glibc, binutils) are compiled by us anyway. 
Probably we just have to add a few more programs.
The thing you would have problems with is the cross-compile. Currently 
(only theoratical) the only way to compile for a different plattform is 
to work on that plattform. OK, in that cause you'll need a new LFS system.

By incorporating those changes into the main build system, we all 
benefit from eachothers developments and progress much faster then others.

We could define those changes as a goal for v2.0, I'm sure it'll take a 
while until you get everything running.

cya
   Heiko

P.S. Devil-Linux on a Linksys or Netgear Router.... sounds cool!

Re: [Devil-linux-develop] usb

[Heiko Z. <he...@zu...>]

Bruce Smith wrote:
>>>I think I found a bug.  I manually created etc.tar.bz2 on my USB device,
>>>and it found and used it on boot without a problem.  (nice!)
>>>
>>>However save-config doesn't find it, and wants to save to floppy.
>>>
>>>I think the problem is you rmmod all the usb stuff in linuxrc after
>>>you're done with it, and save-config doesn't modprobe it.
>>>
>>>When I manually modprobe uhci & usb-storage, then save-config saves to
>>>my USB device as expected.
>>
>>I check with lsmod if usb-storage is loaded, if yes then I check for USB 
>>devices.
>>The hotplug driver is supposed to load the usb and usb-storage driver 
>>after the initrd.
>>Unfortunately I have to unload all the usb drivers, otherwise they cause 
>>problems with the hotplug system.
>>
>>What happens when you unplug the key and plug it back in? Are the 
>>drivers loaded?
> 
> 
> Nope.  This is a real PC, not VMware.  I just followed these steps:
> 
> Fresh reboot with config on USB. (loads fine).
> ssh into the PC, run save-config, wants to save to floppy, ctrl-C
> unplug USB, plug in USB memory stick.
> run lsmod - no usb modules listed.
> run save-config - still wants to save to floppy - ctrl-C.

It works for me in VMWare and on *real* PCs. Is this a fairly new computer?

> Maybe you need to leave the modules for the USB core/controller?
> I _think_ that's how Redhat does it, and they use hotplug.

That was causing problems. Looks like I have to force a re-load of the 
modules in the boot script.

cya
   Heiko

Re: [Devil-linux-develop] Suggestion for better compiling.

[Heiko Z. <he...@zu...>]

John Kiss wrote:
> 	The kernel is only being compiled for different CPU's, the applications
> are being compiled for 486.
> 
> 	Reason, the tool chain in the LFS system was built for 486 compilation
> and this will be the default -march. To fix this all build scripts will
> have to add to the gcc options a -march=<CPU>. Adding this would be
> easier during ./configure. eg.  CFLAGS= -march=686; ./configure
> <options>.  And of course it would be very nice if the 686 came from a
> shell variable set by the DL config file.


The build system includes the build of it's own gcc. When I check the 
build/tmp/gcc-build directory, I'll see a folder i686-pc-linux-gnu . I 
would expect that *this* gcc is for i686 and compiles everything which 
isn't specified differently for i686.
Long sentence short: the default -march should be (in this case) 686, 
correct?

> 	Now I could still be wrong about this, and someone coming back and
> calling me a moron ;-), but one thing that could be happening is an
> environment variable could be set that sets the default -march for
> gcc??? Maybe Heiko would know the answer to this? But in all the gnu
> toolchains that I've built I've never seen documented that the default
> arch can be controled by an enviornment variable, but the gcc manual is
> pretty thick.

We could define CFLAGS as an environment variable, but some programs 
just don't care about it.


> 	Now a comment that could make this entire discussion mute is compiling
> the kernel from a 486 to a 686 makes a huge difference on the system.
> But what are you really gaining by changing the applications from a 486
> to 686 compiles??? 

I agree with Bruce, just the Kernel is not enough.

cya
   Heiko

Re: [Devil-linux-develop] Suggestion for better compiling.

[John K. <jk...@sa...>]

On Sun, 2003-06-22 at 12:58, Bruce Smith wrote:
> > 	The kernel is only being compiled for different CPU's, the applications
> > are being compiled for 486.
> > 
> > 	Reason, the tool chain in the LFS system was built for 486 compilation
> > and this will be the default -march. To fix this all build scripts will
> > have to add to the gcc options a -march=<CPU>. Adding this would be
> > easier during ./configure. eg.  CFLAGS= -march=686; ./configure
> > <options>.  And of course it would be very nice if the 686 came from a
> > shell variable set by the DL config file.
> > 
> > 	Now I could still be wrong about this, and someone coming back and
> > calling me a moron ;-), but one thing that could be happening is an
> > environment variable could be set that sets the default -march for
> > gcc??? Maybe Heiko would know the answer to this? But in all the gnu
> > toolchains that I've built I've never seen documented that the default
> > arch can be controled by an enviornment variable, but the gcc manual is
> > pretty thick.
> 
> We could find out for sure if there was some way to determine what arch
> a pre-compiled binary was compiled for.  (I could check my i686 compiled
> DL and see).  Except I don't know of any way to tell.  Does anyone know
> of a way to tell?

	I thought that using readelf would do it but it's displaying the same
machine info for DL compiled binaries for a 486 and binaries compiled on
my Mandrake which is compiled for i586.

	If you do a readelf -a <binary name> you'll see at the very top of the
listing elf header information.  One of the lines has.

"Machine : Intel 80386"

I would assume that this is where the -march=???? should go but doesn't
appear to. It's always 80386.



> 
> > 	Now a comment that could make this entire discussion mute is compiling
> > the kernel from a 486 to a 686 makes a huge difference on the system.
> > But what are you really gaining by changing the applications from a 486
> > to 686 compiles??? 
> 
> For some applications it would make no difference.  But it can make a
> big difference for some packages.  For example almost all programs use
> glibc extensively, so it will help a lot there.  And it can help
> stand-alone programs which are CPU intensive, like OpenSSL.
> 
> We could go through and modify the few packages it would help and forget
> the rest (like Redhat does on their distribution).  Or do everything.
> 
	I agree that it would affect some applications. If we do some packages
then when lets keep in mind that one day all of them would be done too..
Obviously starting with the packages that would have the most affect,
can you think of any others packages other then glibc and openssl?

> - BS
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
-- 
John Kiss <jk...@sa...>

Re: [Devil-linux-develop] Suggestion for better compiling. - uClibc

[John K. <jk...@sa...>]

	Hey John,

	I've already started on a uClibc verson of Devil Linux. And when I mean
started, it just means I've worked out the best way to start this
adventure and keeping it compatible with the big daddy distro of Devil
Linux.  I've scheduled this to start July 15th. I was also planning to
call this uDL or Micro Devil Linux. It will target not only PC's but
embedded targets and cross compilation for other micro processors as
well, eg. ARM.  Media types will include ISO, CompactFlash, SmartMedia
and JFFS2.

Steps Involved

	1) Create a branch off of the main Devil Linux.
		Of course after approval from the head DL developers
	2) Create a new LFS system, build around uClibc and not glibc
		* Also would be configured for cross compilation
	3) Add the uClibc package into the source tree.
	4) Compile Packages against uClibc and make any changes to 
		build and source.
		**** This is the hardest part.

	I'll be putting together a project proposal to share with everyone on
the mailing list.

	One question that may be asked is why, why start with Devil Linux? 
	The answer is simple, the people/developers resonsible for putting
together the /build system have done an excellent job. It's simple, easy
to configure and change without huge structual changes.  The other
reason, last but not least, is the documentation on the website, that in
my opinion is what really makes DL progress.

	Cheers
	John

	


On Tue, 2003-06-17 at 18:33, John van V. wrote:
> Well... I am not sure if this will help, but I am going to try to start
> developing inside the BOCHS emulator using DL and then moving onto a uClibc
> version that I will call SOY.  I am not sure if I will have success, but you
> guys have VMWare (jealous)
> 
> John
> 
> 
> --- Heiko Zuerker <he...@zu...> wrote:
> > Bruce Smith wrote:
> > >>>>Take a look at scripts/prepare and search for "uname" ( without the
> > >>>
> > >>>quotes
> > >>>
> > >>>>*lol*).  The complete DL System is build for the specific CPU.
> > >>>
> > >>>Are you sure it's working?  I was watching openssl & glibc both compile
> > >>>on my screen, and I never say anything that looked like:  -march i686
> > >>>or any gcc parameter containing "686" (except for the kernel).
> > >>
> > >>Hmmm.....checking...checking.....checking....executing: ./scripts/build.sh
> > >>build opt=openssh
> > >>Ok, the host-type and build-system-type in the configure part is correct,
> > >>but I don't see any -march=686 either.
> > >>Question: doesn't gcc use the architecture it was compiled for, when you
> > >>don't specify anything?
> > > 
> > > 
> > > I don't know.  I'm far from being a gcc expert.
> > 
> > same here
> > 
> > >>I'm getting a bit confused now....
> > > 
> > > 
> > > Welcome to the club!  :-)
> > > 
> > > I've been reading the gcc man page, looking at gcc.gnu.org docs, and
> > > searching the newsgroups.
> > > 
> > > The most useful thing I found so far is "gcc -v" tells what "spec" file
> > > it uses for default options.  I looked at that file, but all the fancy
> > > substitution stuff is over my head.
> > > 
> > > It may be using i686 optimization (in my case), but I don't know how to
> > > confirm or deny it.
> > 
> > Let's hope somebody on this list has the answer to this.
> > 
> > cya
> >    Heiko
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: INetU
> > Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> > _______________________________________________
> > Devil-linux-develop mailing list
> > Dev...@li...
> > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> > 
> > 
> 
> 
> =====
> CXN, Inc. Contact: jo...@th...
> President, The Linux Society
> http://groups.yahoo.com/group/linux-society
> linux society distro -> http://www.thinman.com/eLSD/readme
> ThinMan is a registered trademark of CXN, Inc
> 
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
-- 
John Kiss <jk...@sa...>

Re: [Devil-linux-develop] Suggestion for better compiling.

[Bruce S. <bw...@ar...>]

> 	The kernel is only being compiled for different CPU's, the applications
> are being compiled for 486.
> 
> 	Reason, the tool chain in the LFS system was built for 486 compilation
> and this will be the default -march. To fix this all build scripts will
> have to add to the gcc options a -march=<CPU>. Adding this would be
> easier during ./configure. eg.  CFLAGS= -march=686; ./configure
> <options>.  And of course it would be very nice if the 686 came from a
> shell variable set by the DL config file.
> 
> 	Now I could still be wrong about this, and someone coming back and
> calling me a moron ;-), but one thing that could be happening is an
> environment variable could be set that sets the default -march for
> gcc??? Maybe Heiko would know the answer to this? But in all the gnu
> toolchains that I've built I've never seen documented that the default
> arch can be controled by an enviornment variable, but the gcc manual is
> pretty thick.

We could find out for sure if there was some way to determine what arch
a pre-compiled binary was compiled for.  (I could check my i686 compiled
DL and see).  Except I don't know of any way to tell.  Does anyone know
of a way to tell?

> 	Now a comment that could make this entire discussion mute is compiling
> the kernel from a 486 to a 686 makes a huge difference on the system.
> But what are you really gaining by changing the applications from a 486
> to 686 compiles??? 

For some applications it would make no difference.  But it can make a
big difference for some packages.  For example almost all programs use
glibc extensively, so it will help a lot there.  And it can help
stand-alone programs which are CPU intensive, like OpenSSL.

We could go through and modify the few packages it would help and forget
the rest (like Redhat does on their distribution).  Or do everything.

- BS

Re: [Devil-linux-develop] Suggestion for better compiling.

[John K. <jk...@sa...>]

	The kernel is only being compiled for different CPU's, the applications
are being compiled for 486.

	Reason, the tool chain in the LFS system was built for 486 compilation
and this will be the default -march. To fix this all build scripts will
have to add to the gcc options a -march=<CPU>. Adding this would be
easier during ./configure. eg.  CFLAGS= -march=686; ./configure
<options>.  And of course it would be very nice if the 686 came from a
shell variable set by the DL config file.

	Now I could still be wrong about this, and someone coming back and
calling me a moron ;-), but one thing that could be happening is an
environment variable could be set that sets the default -march for
gcc??? Maybe Heiko would know the answer to this? But in all the gnu
toolchains that I've built I've never seen documented that the default
arch can be controled by an enviornment variable, but the gcc manual is
pretty thick.


	Now a comment that could make this entire discussion mute is compiling
the kernel from a 486 to a 686 makes a huge difference on the system.
But what are you really gaining by changing the applications from a 486
to 686 compiles??? 


On Tue, 2003-06-17 at 18:18, Heiko Zuerker wrote:
> Bruce Smith wrote:
> >>>>Take a look at scripts/prepare and search for "uname" ( without the
> >>>
> >>>quotes
> >>>
> >>>>*lol*).  The complete DL System is build for the specific CPU.
> >>>
> >>>Are you sure it's working?  I was watching openssl & glibc both compile
> >>>on my screen, and I never say anything that looked like:  -march i686
> >>>or any gcc parameter containing "686" (except for the kernel).
> >>
> >>Hmmm.....checking...checking.....checking....executing: ./scripts/build.sh
> >>build opt=openssh
> >>Ok, the host-type and build-system-type in the configure part is correct,
> >>but I don't see any -march=686 either.
> >>Question: doesn't gcc use the architecture it was compiled for, when you
> >>don't specify anything?
> > 
> > 
> > I don't know.  I'm far from being a gcc expert.
> 
> same here
> 
> >>I'm getting a bit confused now....
> > 
> > 
> > Welcome to the club!  :-)
> > 
> > I've been reading the gcc man page, looking at gcc.gnu.org docs, and
> > searching the newsgroups.
> > 
> > The most useful thing I found so far is "gcc -v" tells what "spec" file
> > it uses for default options.  I looked at that file, but all the fancy
> > substitution stuff is over my head.
> > 
> > It may be using i686 optimization (in my case), but I don't know how to
> > confirm or deny it.
> 
> Let's hope somebody on this list has the answer to this.
> 
> cya
>    Heiko
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
-- 
John Kiss <jk...@sa...>

Re: [Devil-linux-develop] usb

[Bruce S. <bw...@ar...>]

> > I think I found a bug.  I manually created etc.tar.bz2 on my USB device,
> > and it found and used it on boot without a problem.  (nice!)
> > 
> > However save-config doesn't find it, and wants to save to floppy.
> > 
> > I think the problem is you rmmod all the usb stuff in linuxrc after
> > you're done with it, and save-config doesn't modprobe it.
> > 
> > When I manually modprobe uhci & usb-storage, then save-config saves to
> > my USB device as expected.
> 
> I check with lsmod if usb-storage is loaded, if yes then I check for USB 
> devices.
> The hotplug driver is supposed to load the usb and usb-storage driver 
> after the initrd.
> Unfortunately I have to unload all the usb drivers, otherwise they cause 
> problems with the hotplug system.
> 
> What happens when you unplug the key and plug it back in? Are the 
> drivers loaded?

Nope.  This is a real PC, not VMware.  I just followed these steps:

Fresh reboot with config on USB. (loads fine).
ssh into the PC, run save-config, wants to save to floppy, ctrl-C
unplug USB, plug in USB memory stick.
run lsmod - no usb modules listed.
run save-config - still wants to save to floppy - ctrl-C.

Maybe you need to leave the modules for the USB core/controller?
I _think_ that's how Redhat does it, and they use hotplug.

 - BS

Re: [Devil-linux-develop] usb

[Heiko Z. <he...@zu...>]

Bruce Smith wrote:
>>I just checked in the changes for save-config to support USB devices.
>>Have fun and bug reports are welcome, as usual. ;-)
> 
> 
> I think I found a bug.  I manually created etc.tar.bz2 on my USB device,
> and it found and used it on boot without a problem.  (nice!)
> 
> However save-config doesn't find it, and wants to save to floppy.
> 
> I think the problem is you rmmod all the usb stuff in linuxrc after
> you're done with it, and save-config doesn't modprobe it.
> 
> When I manually modprobe uhci & usb-storage, then save-config saves to
> my USB device as expected.

I check with lsmod if usb-storage is loaded, if yes then I check for USB 
devices.
The hotplug driver is supposed to load the usb and usb-storage driver 
after the initrd.
Unfortunately I have to unload all the usb drivers, otherwise they cause 
problems with the hotplug system.

What happens when you unplug the key and plug it back in? Are the 
drivers loaded?

cya
   Heiko

[Devil-linux-develop] [fmII] MySQL Database Server 3.23.57 released (Recent (3.23.x) branch)

[<no...@fr...>]

This email is to inform you about the release of version '3.23.57' of
'MySQL Database Server' through freshmeat.net. All URLs and other useful
information can be found at

    http://freshmeat.net/projects/mysql/

The changes in this release are as follows:
Various bugfixes were made.  

Project description:
MySQL is a widely used and fast SQL database server. It is a
client/server implementation that consists of a server daemon
(mysqld) and many different client programs/libraries.  

If you would like to cancel subscription to releases of this project,
login to freshmeat.net and choose 'home' from the personal menubar at the
top of the page. You'll be presented with a list of projects you're
subscribed to in the right column, which you may cancel by highlighting
the project in question and clicking the 'delete' button.

Sincerely,
freshmeat.net 

Re: [Devil-linux-develop] usb

[Bruce S. <bw...@ar...>]

> I just checked in the changes for save-config to support USB devices.
> Have fun and bug reports are welcome, as usual. ;-)

I think I found a bug.  I manually created etc.tar.bz2 on my USB device,
and it found and used it on boot without a problem.  (nice!)

However save-config doesn't find it, and wants to save to floppy.

I think the problem is you rmmod all the usb stuff in linuxrc after
you're done with it, and save-config doesn't modprobe it.

When I manually modprobe uhci & usb-storage, then save-config saves to
my USB device as expected.

 - BS

Re: [Devil-linux-develop] setup

[Heiko Z. <hz...@pr...>]

On 06/20/2003 02:41:28 PM Bruce Smith wrote:
>> I did some (quick) testing of the new setup program, here my list:
>> - Timezone: when you just hit [enter] , timezone is empty
>> - Timezone: you should display the subdirectories: instead of Easter=
n
>->
>>    US/Eastern (could cause problem above)
>> - You should make a comment, that using SYSLOG instead of SYSLOG-NG
>will
>> brake a few things
>> - Packages: the dialog box is too high, I also see no help
>> - Services: same as above
>> - save: you do not need to give USB as an option
>>
>> That's it for now. Otherwise I like it, good job!
>
>I addressed all of your issues.  Changes are committed.
>Run:  "make clean install iso"  and look again.  Thanks!

Cool! I hope I get a chance tomorrow, to test it.

Heiko
=

Re: [Devil-linux-develop] setup

[Bruce S. <bw...@re...>]

> I did some (quick) testing of the new setup program, here my list:
> - Timezone: when you just hit [enter] , timezone is empty
> - Timezone: you should display the subdirectories: instead of Eastern -> 
>    US/Eastern (could cause problem above)
> - You should make a comment, that using SYSLOG instead of SYSLOG-NG will 
> brake a few things
> - Packages: the dialog box is too high, I also see no help
> - Services: same as above
> - save: you do not need to give USB as an option
> 
> That's it for now. Otherwise I like it, good job!

I addressed all of your issues.  Changes are committed.
Run:  "make clean install iso"  and look again.  Thanks!

 - BS

Re: [Devil-linux-develop] setup

[Bruce S. <bw...@ar...>]

> >Should I move the "software-help" file out of /etc so we don't have this
> >problem in the future?  If so, where should I put it?
> 
> /usr/share/devillinux/software-help would be cool, or?
> This folder is actually under $CDDIR and will not eat up any ramdisk space.

Sounds good.  I checked in my changes.  It should be there now.

 - BS