Recent coreutils upstream has dropped su, which on debian was being
built (only) for hurd. Is there an alternative that coreutils can pull
in? For now I've left the (now broken) su logic in debian/rules for
coreutils, so it will just fail to build on hurd until I get some idea
of how to proceed
On Tue, Oct 14, 2003 at 06:16:46AM -0400, Michael Stone wrote:
On Fri, Oct 10, 2003 at 11:00:27AM +, Robert Millan wrote:
Are you sure we're suposed to port libacl and libattr, or should that
functionality just be deactivated in coreutils for non-Linux-based systems?
Send me a patc
On Fri, Oct 10, 2003 at 11:00:27AM +, Robert Millan wrote:
Are you sure we're suposed to port libacl and libattr, or should that
functionality just be deactivated in coreutils for non-Linux-based systems?
Send me a patch.
Mike Stone
On Tue, May 21, 2002 at 05:16:23PM +1000, Anthony Towns wrote:
> Firewalling tools are not available for Debian GNU/Hurd.
>
> Debian GNU/Hurd will not be released until they are available.
Then you should get consensus to have that in policy or step down as
release manager. It is entirely unreaso
On Tue, May 21, 2002 at 09:22:55AM +1000, Anthony Towns wrote:
> On Mon, May 20, 2002 at 05:13:55PM -0400, Michael Stone wrote:
> > I'm sure hurd has fundamental control: if they don't want someone
> > connecting to a hurd box, they won't run any network servers.
>
On Tue, May 21, 2002 at 06:12:00AM +1000, Anthony Towns wrote:
> On Mon, May 20, 2002 at 12:13:41PM -0700, Thomas Bushnell, BSG wrote:
> > 1. Debian does not have firewalling by default, so if firewalling is
> > necessary for security, then it is not secure by default.
>
> It does: it has spoof pr
On Mon, May 20, 2002 at 02:45:09AM +0200, Wolfgang Jährling wrote:
> No, as they are started by users. /libexec is for programs which are not
> started by users.
So they *should* be in /bin. Glad we cleared that up!
--
Mike Stone
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
On Mon, May 20, 2002 at 02:41:19AM +0200, Wolfgang Jährling wrote:
> Of course you do, because you don't understand what /hurd is about. It
> is about the Hurd server binaries, which are started by users and should
> not be hidden in a directory like /lib/you/cant/find/me/.
So they should be in /b
On Mon, May 20, 2002 at 01:56:05AM +0200, Marcus Brinkmann wrote:
> /lib/modules is completely wrong. Hurd servers are neither a library nor
> modules, nor non-executable architecture specific data or anything of that
> sort.
So they should go in this libexec thing y'all can't live without?
--
9 matches
Mail list logo
