guitarlynn wrote:
I'm working on a script that generates Dachstein compliant /etc/modules
and /etc/network.conf files and is used as an install option on the
lrcfg menu. It is all working at this point _except_ the generated
network.conf file. Using the dhcp and firewall options, I get this
Matt Schalit wrote:
guitarlynn wrote:
I'm working on a script that generates Dachstein compliant /etc/modules
and /etc/network.conf files and is used as an install option on the
lrcfg menu. It is all working at this point _except_ the generated
network.conf file. Using the dhcp and firewall
Feature Requests item #506946, was opened at 2002-01-22 04:29
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=363751aid=506946group_id=13751
Category: Dachstein
Group: None
Status: Open
Priority: 5
Submitted By: Ewald Wasscher (ewaldw)
Assigned to: Charles
I'm working on a script that generates Dachstein compliant /etc/modules
and /etc/network.conf files and is used as an install option on the
lrcfg menu. It is all working at this point _except_ the generated
network.conf file. Using the dhcp and firewall options, I get this error
on svi
KP Kirchdörfer wrote:
snip
Long Term:
I'd also like to see the configuration directory approach taken to
logrotate (similar to my RedHat distributions, which already do
this), and even inetd (switch to xinetd?). Using files in a
configuration directory makes the seperation of configuration
Am Montag, 21. Januar 2002 16:54 schrieb Ewald Wasscher:
Charles Steinkuehler wrote:
Let's start with a wish list, then folks can start working on
whatever pieces interest them.
Good idea!
- Boot-strap code modified to use features available in unpatched
kernel (ie no more
KP Kirchdörfer wrote:
snip
Anyway, I could think of a core that boots without glibc and loads
glibc 2.0.7 for floppy releases and glibc whatever for CD, HD et
al...
I think supporting 3 different c-libraries at a time will cause lots of
problems for users, and for the developers
Anyway, I could think of a core that boots without glibc and loads
glibc 2.0.7 for floppy releases and glibc whatever for CD, HD et
al...
I think supporting 3 different c-libraries at a time will cause lots of
problems for users, and for the developers supporting them. I'd prefer
to drop
Luis.F.Correia wrote:
Anyway, I could think of a core that boots without glibc and loads
glibc 2.0.7 for floppy releases and glibc whatever for CD, HD et
al...
I think supporting 3 different c-libraries at a time will cause lots of
problems for users, and for the developers supporting them.
Anyway, I could think of a core that boots without glibc and loads
glibc 2.0.7 for floppy releases and glibc whatever for CD, HD et
al...
I think supporting 3 different c-libraries at a time will cause lots of
problems for users, and for the developers supporting them. I'd prefer
to drop
Charles Steinkuehler wrote:
For instance, just because your /var/cache maybe full, do you want to
arbitrarily purge /var/log files?
Not for an instant do I suggest that such complexity is insurmountable;
rather, it should be clear that this is far more involved and requires a
new
See below.
At 07:11 PM 1/22/02 +0100, Ewald Wasscher wrote:
Luis.F.Correia wrote:
[...]
If we drop support for the ancient glibc-2.0.7, will we still able to
use the floppy versions?
That will become a bit more difficult. I don't have any exact numbers,
but I estimate that glibc 2.2.x will
Comments below:
Luis.F.Correia wrote:
Anyway, I could think of a core that boots without glibc and loads
glibc 2.0.7 for floppy releases and glibc whatever for CD, HD et
al...
I think supporting 3 different c-libraries at a time will
cause lots of
problems for users, and for the
And to raise another old issue:
Will we work with a cvs repository?
I think this is a must. If we're ever going to get out of the one man
distribution era, we need an effective way to replicate build environments,
and propogate updates. CVS was made to do exactly this.
The big question is
I've seen problems of this sort caused by unpaired quotes and
improper end-of-lines (ie DOS CRLF instead of unix LF).
Ah so, got it!
I eliminated some whitespace I added and found a missing semi-colon on
~line 737. Works now!!!
Going to do some connection testing and add a prompt for portfw
I will at least apply the one line fix in the next release. For the
future,
I'd like to see support for a configuration directory. There would be
some
default entries, while add-on packages could drop entries into the
/etc/purge.d (or whatever) directory, with customizations for any
Hello all; due to reported mailing-list problems, please CC, as done,
to me.
And forgive, if I confuse private mail with list-mail... thanks.
Am Dienstag, 22. Januar 2002 19:18 schrieb Charles Steinkuehler:
Anyway, I could think of a core that boots without glibc and
loads glibc 2.0.7 for
At 2002-01-22 12:36 -0600, Charles Steinkuehler wrote:
And to raise another old issue:
Will we work with a cvs repository?
I think this is a must. If we're ever going to get out of the one man
distribution era, we need an effective way to replicate build
environments, and propogate
Am Dienstag, 22. Januar 2002 19:39 schrieb Michael D. Schleif:
KP Kirchdörfer wrote:
Am Dienstag, 22. Januar 2002 19:21 schrieben Sie:
KP Kirchdörfer wrote:
Am Montag, 21. Januar 2002 15:54 schrieb Charles Steinkuehler:
I will at least apply the one line fix in the next release.
Charles Steinkuehler wrote:
I will at least apply the one line fix in the next release. For the
future,
I'd like to see support for a configuration directory. There would be
some
default entries, while add-on packages could drop entries into the
/etc/purge.d (or whatever)
Luis.F.Correia wrote:
That will become a bit more difficult. I don't have any exact
numbers, but I estimate that glibc 2.2.x will take around
225-250 kb more diskspace than glibc 2.0.7.
For Oxygen-1.8.0 (the current release):
libc.lrp takes 522285 bytes on the floppy.
libc-2.1.3.so
Everyone,
I created phpWS admin/author accounts for all of our developers. Send me
email off list for login instructions. Note: our phpWebSite doesn't share
authentication with SourceForge.
I backed up our MySQL database, and performed the following modifications.
mysql ALTER TABLE developer
I think ideally, checkfreespace would have to determine which filesystem
the
purge-able files reside on. One of my major goals for a new
distribution is
to gracefully support flexible mount-points. While the purge-able files
may
not change, and so could be included as part of the
Build a single sed command to delete any un-desired file specs, and strip
off the purge-level...start with /^1/!d (where one is the desired purge
level), add delete commands for each sub-mount point (ie
\:var/log/httpd:d),
and end with a substute command to strip the leading field ( s/^[0-9
24 matches
Mail list logo
