> sysvinit checks its own PID to determine wether it's being run as init or
> as userland utility. FWIW, there's also a -i option that overrides this.
It can probably do getpid () == 1 || getppid () == 1.
On Tue, Jun 15, 2004 at 03:14:45PM -0400, Roland McGrath wrote:
> > The two main problem now are the runtime errors that will come
> > from needing a Linux like /proc, this could be solved "easily"
> > porting libps from the Hurd and adding to it kFreeBSD and Linux
> > kernel support, so it can be
> The two main problem now are the runtime errors that will come
> from needing a Linux like /proc, this could be solved "easily"
> porting libps from the Hurd and adding to it kFreeBSD and Linux
> kernel support, so it can be used at large on all Debian packages
> needing to access this kind of in
Now there is nothing to replace it.
I can think of two things that can replace it, the current system wich
is far nicer then the sysvinit crap, and DMD.
GNU/Hurd needs Debian GNU/Hurd, if you like it or not.
No it does not; GNU/Hurd needs a user base; Debian GNU/Hurd happens to
be the majo
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>GNU/Hurd absolutely needs sysvinit, it is really important to us.
>
> Bollocks, it isn't important to GNU/Hurd nor does it _need_ it, since
> it doesn't follow the philosophy of GNU. It might be important to
> Debian GNU/Hurd, but if you meant t
Hi Miquel,
On Wed, Jun 09, 2004 at 07:08:19PM +0200, Robert Millan wrote:
> Miquel: IIRC, sysvinit now works perfectly on GNU/Hurd with the exception
> of a PID conflict (/hurd/init is pid 1 also).
Well it does not work at all. It now builds though, that was what I
promised to Jeff as the first s
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> Bollocks, it isn't important to GNU/Hurd nor does it _need_ it, since
> it doesn't follow the philosophy of GNU. It might be important to
> Debian GNU/Hurd, but if you meant that then say so.
I'm not suce which "philosophy of GNU" you mean. It is
> Bollocks, it isn't important to GNU/Hurd nor does it _need_ it,
> since it doesn't follow the philosophy of GNU. It might be
> important to Debian GNU/Hurd, but if you meant that then say so.
I'm not suce which "philosophy of GNU" you mean.
The one that implies "things should be do
> As I said, alpha.gnu.org in the good old days was just a
> temporary dump site for quick hacks. The less it is supported
> the better infact. On a "perfectly" working Debian system you
> should only need to have ftp.debian.org in your sources.list,
> nothing else.
This still
On Thu, Jun 10, 2004 at 05:43:13PM +0200, Alfred M. Szmidt wrote:
>A while ago, a couple of base packages were only available on
>ftp.gnuab.org and crosshurd needed ftp.gnuab.org to work
>properly. I haven't checked lately, perhaps matters have changed.
> As I said, alpha.gnu.org in t
A while ago, a couple of base packages were only available on
ftp.gnuab.org and crosshurd needed ftp.gnuab.org to work
properly. I haven't checked lately, perhaps matters have changed.
As I said, alpha.gnu.org in the good old days was just a temporary
dump site for quick hacks. The less
You should know this list is about the Debian GNU/Hurd port, not
GNU in general.
Then you should also know that saying "GNU/Hurd" means GNU/Hurd in
general, not just Debian GNU/Hurd.
On Thu, Jun 10, 2004 at 04:35:52PM +0200, Alfred M. Szmidt wrote:
>GNU/Hurd absolutely needs sysvinit, it is really important to us.
>
> Bollocks, it isn't important to GNU/Hurd nor does it _need_ it, since
> it doesn't follow the philosophy of GNU. It might be important to
> Debian GNU/Hurd,
GNU/Hurd absolutely needs sysvinit, it is really important to us.
Bollocks, it isn't important to GNU/Hurd nor does it _need_ it, since
it doesn't follow the philosophy of GNU. It might be important to
Debian GNU/Hurd, but if you meant that then say so.
On Wed, Jun 09, 2004 at 06:49:20PM +0200, Marco Gerards wrote:
>
> You are partially right. GNU/Hurd doesn't use sysvinit *yet*. If I
> understand it correctly, people are porting sysvinit to GNU/Hurd.
> Perhaps it was already done.
>
> The bug report you showed us seems to confirm this. In th
Miquel van Smoorenburg <[EMAIL PROTECTED]> writes:
>> Since Debian GNU/Hurd doesn't use sysvinit, just depending on libc0.3
>> seems like a good enough solution I think, or just not listing libc0.3
>> at all (as it is now AFAIK).
>
> Wait, the Hurd doesn't use sysvinit at all ? I do get regular bu
On Wed, Jun 09, 2004 at 02:32:11PM +0200, Alfred M. Szmidt wrote:
>But on the other hand, ftp.gnuab.org is well known in the Debian
>GNU/Hurd community and supported.
>
> The intention of alpha.gnu.org at least was to have it not known, and
> supported as little as possible.
A while ago,
On 2004.06.09 13:01, Alfred M. Szmidt wrote:
>> Miquel, could you please briefly explain what kind of features in
>> the new libc do you need, and what kind of breakage would happen
>> when using the old libc?
>
>Older versions of glibc included the /etc/init.d/mountkernfs and
>
In general, I think that we should of course try to have as much
packages on ftp.debian.org as possible.
We should try to have all packages in ftp.debian.org and try to
discourgae the use of any kind of secondary dump site (atleast, this
is how it was before).
But on the other hand, ftp.
Wait, the Hurd doesn't use sysvinit at all ?
Nope, no sysvinit in sight.
I do get regular bugreports saying "this needs to be fixed for the
hurd" and "hurd needs a hurd-specific inittab" and so on. Where
does that come from, then ? *confused* (see
e.g. http://bugs.debian.org/cgi-b
On Wed, Jun 09, 2004 at 12:39:56PM +0200, Michael Banck wrote:
> On Wed, Jun 09, 2004 at 12:02:43PM +0200, Santiago Vila wrote:
> > IMHO, I think it is highly desirable that all packages in ftp.debian.org
> > depend on packages in ftp.debian.org. There is at least one important
> > package in ftp.d
> Miquel, could you please briefly explain what kind of features in
> the new libc do you need, and what kind of breakage would happen
> when using the old libc?
Older versions of glibc included the /etc/init.d/mountkernfs and
/etc/init.d/devpts.sh scripts. The latest initscripts pa
On Wed, Jun 09, 2004 at 12:02:43PM +0200, Santiago Vila wrote:
> IMHO, I think it is highly desirable that all packages in ftp.debian.org
> depend on packages in ftp.debian.org. There is at least one important
> package in ftp.debian.org which depends on the libc0.3 in ftp.gnuab.org,
> which is new
On 2004.06.09 12:02, Santiago Vila wrote:
> On Wed, 9 Jun 2004, Alfred M. Szmidt wrote:
>
> >Currently libc0.1 is the official glibc version for the hurd in the
> >main archive.
> >
> > I suggest that you do your research a bit better; or maybe the Debian
> > GNU/*BSD people should make it
On Wed, 9 Jun 2004, Alfred M. Szmidt wrote:
>Currently libc0.1 is the official glibc version for the hurd in the
>main archive.
>
> I suggest that you do your research a bit better; or maybe the Debian
> GNU/*BSD people should make it clearer, the naming of the package
> isn't exactly wond
Currently libc0.1 is the official glibc version for the hurd in the
main archive.
I suggest that you do your research a bit better; or maybe the Debian
GNU/*BSD people should make it clearer, the naming of the package
isn't exactly wonderful. libc0.1 is a Debian GNU/*BSD package, it
isn't e
I am the maintainer of sysvinit.
Currently libc0.1 is the official glibc version for the hurd in
the main archive. So debian/control of sysvinit contains things like:
Package: initscripts
Replaces: sysvinit (<< 2.85-12), libc6, libc6.1, libc0.1
Now for initscripts I really need to depend on a gl
27 matches
Mail list logo