C != Java
Which is to say, a null pointer is not a valid argument to unlink, and the
Hurd's use of a signal instead of an error is allowed by Posix.
Thomas
On Jan 14, 2012 8:48 AM, "Steven McDonald"
wrote:
> Hi,
>
> I've been looking at the problems with visudo as tracked on alioth[1].
> I've a
A hurd ioctl has to also have something which documents the exact structure
layout in a way that the library can use to reformat it into a Mach
message. That's what the _IOT_foo thing would be. Since it's missing, the
_IOW call fails.
Some ioctls can't be represented, for various reasons, and requ
Cheroot isn't supposed to change the namespace of Unix domain sockets in the
case where the chroot shares a file with the main system.
On Jun 2, 2011 6:56 PM, wrote:
> Hi,
>
> On Tue, May 31, 2011 at 09:35:32AM +0200, Samuel Thibault wrote:
>
>> You just need another partition, run debootstrap in
Yes. Timers do create new threads to wait for the event in question, and
then they send the signal in the normal way.
On May 10, 2011 11:18 AM, "Richard Braun" wrote:
But it would be a nice feature to add. Each filesystem could report the
filesystems mounted on it, and df could walk that tree.
On Mon, Apr 11, 2011 at 1:06 PM, Patrik Olsson wrote:
> On 11/04/11 21:40, startx wrote:
> > hello.
> >
> > as another long time reader on this list (several years) i g
On Mon, Aug 9, 2010 at 1:55 PM, wrote:
>
> Originally the Hurd was meant to be binary compatible with BSD BTW; but
> this is no longer relevant...
>
>
That idea died so long ago the ashes aren't even visible.
Thomas
On Thu, 2008-08-14 at 18:35 +0200, Joerg Jaspert wrote:
> As both of your architectures are affected by the first rule (m68k
> missed etch and will miss lenny, hurd never had a release), it is time
> for us to think about the best possible way for you to move elsewhere,
> like debian-ports.org. We
On Tue, 2008-01-01 at 04:10 +, Samuel Thibault wrote:
> Thomas Bushnell BSG, le Thu 27 Dec 2007 18:06:39 -0800, a écrit :
> > > Now, that said, we'd have to modify libc's to also include
> > > a provided by the hurd's libpthread.
> >
> > Yes,
On Fri, 2007-12-28 at 02:04 +, Samuel Thibault wrote:
> Actually, it happens that in the pike7.6 case, it doesn't, because its
> configure.in doesn't use AC_CHECK_FUNCS for that function. Yes, that's
> evil, but that's unfortunately what people do.
So then they get what they deserve. :)
> N
On Fri, 2007-12-28 at 01:14 +, Samuel Thibault wrote:
> Thomas Bushnell BSG, le Mon 24 Dec 2007 15:45:17 -0500, a écrit :
> > On Sun, 2007-12-23 at 21:53 +0100, Samuel Thibault wrote:
> > > Thomas Bushnell BSG, le Fri 21 Dec 2007 21:10:12 -0500, a écrit :
> > > >
On Sun, 2007-12-23 at 21:53 +0100, Samuel Thibault wrote:
> Hi,
>
> Thomas Bushnell BSG, le Fri 21 Dec 2007 21:10:12 -0500, a écrit :
> > We are supposed to gave libc #defines that say that a function is a stub
> > when it just returns ENOSYS, which configure checks for.
On Sat, 2007-12-22 at 01:35 +, Samuel Thibault wrote:
> Hello,
>
> At least in pike7.6, ./configure detects pthread_atfork() and then the
> resulting program uses it, and fails because for now our implementation
> is
>
> return ENOSYS;
>
> If we weren't providing the function, pike would ma
On Mon, 2007-08-20 at 10:38 +0200, Samuel Thibault wrote:
> Hi,
>
> Thomas Bushnell BSG, le Mon 20 Aug 2007 00:26:47 -0400, a écrit :
> > 1: I think it should be raised in gnumach itself, not just in the Debian
> > version.
>
> Well, it's the same for THREAD_
On Mon, 2007-08-20 at 02:52 +0200, Samuel Thibault wrote:
> Samuel Thibault, le Mon 20 Aug 2007 02:18:44 +0200, a écrit :
> > Samuel Thibault, le Mon 20 Aug 2007 02:06:18 +0200, a écrit :
> > > int vm_object_cached_max = 200;/* may be patched*/
> > >
> > > We should probably raise
On Sat, 2007-01-20 at 12:40 -0500, Stephen Liebbe wrote:
> Package: gnumach
> Version: 2:1.3.99.dfsg.1-1+b1
> Severity: important
> Justification: fails to build from source
That's at best a wishlist bug. DEB_BUILD_OPTIONS isn't even mandatory,
fwiw.
Thomas
signature.asc
Description: This is
Philip Charles <[EMAIL PROTECTED]> writes:
> Once sarge is released could we get the d-i team to start looking at
> incorporating Debian GNU/Hurd into the installer?
My expectation is that members of the debian-hurd team will be
expected to do the lion's share of the actual work, but that the d-i
Thread moved over to bug-hurd since it's about design and not Debian
GNU/Hurd per se. Alfred Szmidt had pointed out that a dpkg
installation translator (one where you copy a .deb into a directory to
install it into the system) cannot be easily written, because Debian
package installation scripts
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> *wink* how do you purpose to somehow get some kind of interactive
> input from the user when you do a file-system call?
This is a shortcoming in the design of the Hurd (gasp!). What works
is a "user interaction context" widget, passed to servers s
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> My sentence was unclear, what I meant was why change from /usr -> /
> (which has been long in use) and then back again to /usr -> / when the
> plan has always been to have that symlink or atleast have a translator
> sitting there. Removing the syml
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>And as I said, we need shadow translators. Once we have them, we
>could create /usr->/ with little fuss.
>
> We already have a read-only (write support is flakey) implementation
> of unionfs. But why change _back_ to /usr -> / when that wa
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>It would be easy to change /usr; we would need to have shadow
>translators, make existing packages install (which is trivial with
>the /usr->/ symlink), and so forth.
>
> We don't have a /usr -> / symlink anymore. It is optional, and th
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>I see no reason to think that Debian GNU/Hurd cant do all of these.
>
> /usr is now by default a seperate directory I think, people bitch
> about obviously compliant FHS directories. These are small things
> compared to using translators for /s
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> Top of the head: managing configuration files using a translators by
> default. Using unionfs to eliminate /usr. Redesining the package
> format so one can use a translator to install/remove packages.
> /share/info/dir managed by a translator. I c
Pierre THIERRY <[EMAIL PROTECTED]> writes:
> Scribit Michael Banck dies 19/03/2005 hora 02:59:
> > Bad idea.
>
> Why?
Because a better way is to support negative archs. Listing all archs
but one in Architecture: lines is a Bad Thing in Debian, it's a last
possible resort. It's much better, for
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> I dislike these kind of silly questions since they serve no point.
> Ask a DD or the DPL if the point of Debian is to create Debian
> GNU/Hurd or Debian GNU/Linux. Look around www.debian.org.
They've already created Debian GNU/Linux. The point of
Pierre THIERRY <[EMAIL PROTECTED]> writes:
> > /lib is for libraries, and is on the linkers library search path. It
> > was a mistake for FHS to use it as broadly as it does, because that
> > slows down linking and makes filesystem arrangement harder.
>
> If the current use of /lib in the FHS is
Pierre THIERRY <[EMAIL PROTECTED]> writes:
> > I think I can speak for all who care about the Hurd here, be it within
> > Debian or not: We will NOT change /hurd to be somewhere else.
>
> OK. If you have decided to be stubborn, just don't try to argue that
> /hurd is FHS compliant. Just say you d
Pierre THIERRY <[EMAIL PROTECTED]> writes:
> It would just be very comfortable to newcomers in Hurd if things were in
> standard places they have already learned about.
Nobody has any settled expectation of where Hurd translators will be
found, well, sort of. Those who know about them expect to
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> I have considered a "Debian port outside of Debian" a couple of years
> ago very carefully, for some reasons. And it is not an easy task, if
> you want to do it properly. There is a major difference between
> having a couple of extra packages on a s
Marco Gerards <[EMAIL PROTECTED]> writes:
> But doing this because the bureaucracy wants it seems like a silly
> reason to me. I am considering writing a new pfinet from scratch
> because the current one really sucks, in my opinion. If we want
> firewall support it should be in the new pfinet, I
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> What Debian GNU/Hurd will be is Debian GNU/Linux + translator support,
> and a easy way for people to try the Hurd, without all the nice
> things. Debian is not interested in creating a new operating system.
That's fine. I'm not out here to say t
Philip Charles <[EMAIL PROTECTED]> writes:
> Generally agree, but I think that the decision about GNU/Hurd should be
> made on the basis of it being a new os under development, and not the
> criteria set up for mature os's and their ports.
Can you offer specific criteria that will ease their fear
Philip Charles <[EMAIL PROTECTED]> writes:
> There is a major difference between the GNU/Hurd and all the Linux and
> BSD ports. We are creating a new os.
Right, but it wouldn't be unfair for Debian to say that the purpose of
Debian is something else. So we can use the Debian infrastructure,
bu
Here's one fellow's interpretation of that requirement.
--- Begin Message ---
On Mar 17, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> > > One of the conditions for SCC is "fully functioning Unix, including
> > > DNS and firewall support."
Michael Banck <[EMAIL PROTECTED]> writes:
> To be precise, we were a 'second class citizen' for all the time. So in
> case we manage to stay at that level for the time being, we might even
> profit from it. E.g. unstable snapshots look very much like what Philip
> Charles did with the CD release
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> I am not even trying to comprehend where these rules come from, or
> what their sanity is. I am just going to accept whatever comes out of
> the Debian cabal as long as I can morally accept it.
See debian-devel.
> Does this mean eternally, or only
Marc DequÃnes (Duck) <[EMAIL PROTECTED]> writes:
> Asking for having one of the autobuilder's pool always up should be a
> sufficient criteria ; we could acheive that and push this modified
> criteria to the release-team draft.
Ok, I'll see if I can get that going.
Pierre THIERRY <[EMAIL PROTECTED]> writes:
> > [Hurd servers] are totally useles to have in PATH
>
> But /lib/hurd is not in PATH, and the Hurd servers would perfectly fit
> in there.
They would "fit" in /usr/share/unrelated too. But we chose /hurd as
being more descriptive. /lib is for librar
"Barry deFreese" <[EMAIL PROTECTED]> writes:
> >> We do? Guillem and Michael are active DDs. Who else? Thomas is I
> >> think. What about Marcus and Neal, are they both DDs?
> >
> > I am, and Marcus is.
>
> There's 4. I would like to throw my name in the NM queue but that
> might take a while
"Barry deFreese" <[EMAIL PROTECTED]> writes:
> Yes, that is going to be a tough one. I was hoping to use my new box
> with an 80Gb drive but it has been very unstable.
So what we need then are bug fixes. :) What are the crashes? I saw
messages about crashing during libc, but the talk was all a
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> How is one supposed to demonstrate that a port has atleast 50 users by
> the way?
Popularity-contest is one way. Another is just asking them.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL
"Barry deFreese" <[EMAIL PROTECTED]> writes:
> "WE"??? Does that mean you are joining us again??
Hrm.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Pierre THIERRY <[EMAIL PROTECTED]> writes:
> Scribit Thomas Bushnell BSG dies 16/03/2005 hora 09:45:
> > > does it harm to respect FHS and put what is in /hurd in /sbin and
> > > /usr/sbin?
> > We are not disrespecting FHS, and yes, it does harm.
>
> OK,
Pierre THIERRY <[EMAIL PROTECTED]> writes:
> As the Hurd works with a Â-kernel, the Hurd servers do precisely what,
> in Linux, the loadable modules do, and they are in /lib.
No, they don't. Kernel modules are very close to shared libraries,
which is why they are in that directory.
> It's not a
Some changes to the way Debian manages its archive and releases
architectures may be in the works. Most of this doesn't affect Debian
Hurd because we aren't a release architecture anyway.
Architectures which are not released or have low download rates will
be hosted on a separate archive; this m
Pierre Gillmann <[EMAIL PROTECTED]> writes:
> What is with /lib/hurd or /lib/servers? GNU/Linux has it modules
> in /lib/modules/$kernel-version, so why you do not the same for Hurd?
They are not libraries.
> In fact /hurd is very easy to use, but if there are same problems with
> the FHS, it wi
Pierre THIERRY <[EMAIL PROTECTED]> writes:
> > What the FHS calls "binaries" are only some executables on the Hurd;
> > we have other executables that don't work like FHS "binaries", gotcha?
>
> Sincerely, I'm not sure I see why it is needed to make a difference. I
> may ask the question from a d
Pierre THIERRY <[EMAIL PROTECTED]> writes:
> But they are binaries that make the system work, so they would fit in
> /sbin:
>
> ``/sbin contains binaries essential for booting, restoring,
> recovering, and/or repairing the system''
>
> As I don't have (yet) a working Hurd system on one of my
Pierre THIERRY <[EMAIL PROTECTED]> writes:
> I was wondering why the /hurd directory exists. I googlized a bit about
> Hurd and the FHS, and didn't found really enlighting documentation about
> that particular point.
>
> Why don't Hurd servers are in /sbin or /usr/sbin? If I understand
> correctl
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Oh, sure. The insanity starts if you talk about using "UTF-8" for
> things like filenames without being very exact in what you mean by
> that. The implications of putting the complex system UTF-8 into a
> POSIX-like operating systems as they exist t
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> UTF-8 is an insanely complex standard, if you start to look down its
> depths.
UTF-8 is a complex standard. It is not insanely so. It is complex
because it is representing a very complex problem.
It is a standard computer programmer's disease
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Irregardless of what you think about it - the
> western world doesn't need it (where ISO 8859-1 or 15 is enough).
If only this were true. There is no encoding which will include all
of the Latin character sets I want. This occurs for me in tagging
"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
Ron Graves <[EMAIL PROTECTED]> writes:
> > Still, why would you want to turn it off, since we may in the future
> > take it as some kind of VM preferencing hint?
>
> I can't 'startx' as an unprivileged user. Not knowing the purpose
> of 's', and comparing permissions of my working Debian GNU/Lin
Ron Graves <[EMAIL PROTECTED]> writes:
> -rwsr-sr-x1 root root 7828 Apr 28 11:23 X
> The 's' is a 'stickybit', right? Is this something Hurd needs? Can I chmod
> +x X, without causing any grief.
Right now it's ignored, but we may well in the future have VM handling
pay attentio
[EMAIL PROTECTED] writes:
>> So, should "settrans" refuse to set a translator if the
>> translating program (in this case /dev/hd1s1) is not executable
>> or is there any reason not to do this?
>
>It seems reasonable to make it refuse unless you give it a -f
>option; or perhap
Wolfgang Jaehrling <[EMAIL PROTECTED]> writes:
> So, should "settrans" refuse to set a translator if the translating
> program (in this case /dev/hd1s1) is not executable or is there any
> reason not to do this?
It seems reasonable to make it refuse unless you give it a -f option;
or perhaps prom
Jonathan Daugherty <[EMAIL PROTECTED]> writes:
> That's interesting; is it some kind of FIFO, which fills with messages
> but whose contents are not maintained internally?
Yes; that's standard. It's supposed to be read by syslog under normal
circumstances.
Thomas
Marco Gerards <[EMAIL PROTECTED]> writes:
> Perhaps this has something to do with forgetting to put swap in
> /etc/fstab after installing this system, but it should not happen
> because I have 390MB RAM. Please test this. I have used bonnie++ for
> this (it is in debian).
You can only make that
Georg Lehner <[EMAIL PROTECTED]> writes:
> - One promise of the microkernel architecture is better performance on
> multiprocessor systems, or multicomputer systems. What is the status
> of Gnu Mach with respect to these.
This may or may not be true. The Hurd is built around a microkernel
ar
Johannes Rohr <[EMAIL PROTECTED]> writes:
> "Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>
> >How do you access this `login' shell from remote?
> >
> > See the login> prompt when you login? That is the login shell, it is
> > just a normal shell that is running as an anonymous user (see the
[EMAIL PROTECTED] writes:
> > tcpdump needs live packet capture, and whatever that is, we don't have it.
>
> Yes, Marcus, I realized it from the error message.
> But my question is:
>
> - > tcpdump: live packet capture not supported on this system
> what does this term "live packet capture" me
[EMAIL PROTECTED] (Neal H. Walfield) writes:
> > If our only alternatives are
> >
> > 1) no ssh
> > 2) ssh with no security
>
> Wrong, which just proves that you have not read this thread: we are
> arguing about entropy; ssh is only a side argument.
*IF*. Can you read the word *IF*?
The propo
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>If our only alternatives are
>
>1) no ssh
>2) ssh with no security
>
>you have advocated (2), right? It is that statement which I am
>arguing against.
>
> No, I have advocated against including a unsecure random translator.
>
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> Please, could you bother reading my mails even for a small amount of
> time? I have _not_, I repeat, _not_ suggested the removal of Open SSH!
If our only alternatives are
1) no ssh
2) ssh with no security
you have advocated (2), right? It is tha
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>>Telnet has worse security than even a buggy miserably fake ssh.
>>
>> Telnet has _no_ security. It doesn't have fake security, which you
>> get by using crappy random bits and Open SSH. That is a huge
>> difference. Open
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>> I think that we can all accept that there are currently a variety of
>> security holes in the Hurd. The type of security holes which would be
>> introduced by using bad random data, however, is far worse as it has
>> the potential
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>Telnet has worse security than even a buggy miserably fake ssh.
>
> Telnet has _no_ security. It doesn't have fake security, which you
> get by using crappy random bits and Open SSH. That is a huge
> difference. Open SSH was designed for secu
[EMAIL PROTECTED] (Neal H. Walfield) writes:
> > > Why do I feel like repeating this old mantra: Bad security is worse
> > > than no security.
> >
> > Sez you. Many disagree. Especially for a system in development, with
> > already has bad security.
>
> I think that we can all accept that ther
[EMAIL PROTECTED] (Niels Möller) writes:
> The argument is really simple. Programs that use /dev/urandom
> generally expect to get numbers that are not only uniform, but numbers
> which are actually *useful* for *cryptographic* purposes. Creating a
> /dev/urandom that does something different is b
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>> Why do I feel like repeating this old mantra: Bad security is worse
>> than no security.
>
>Sez you. Many disagree. Especially for a system in development, with
>already has bad security.
>
> Fine, would you like to work on this
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>Ssh should provide a non-cryptographically secure mode (such as
>using hashes of the low time bits, for example) for use on systems
>without a real random bit source.
>
> What Open SSH should do and not do, should be discussed on the Ope
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> Why do I feel like repeating this old mantra: Bad security is worse
> than no security.
Sez you. Many disagree. Especially for a system in development, with
already has bad security.
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>I agree that we should not have a fictitious /dev/urandom, but we
>should support ssh even so.
>
> Open SSH is supported, in an insecure way, by either a random
> translator, or the copying hack.
Ssh should provide a non-cryptographically s
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
>Really, I don't think we delete packages just because we have bugs.
>We have *lots* of bugs, and it's inappopriate to remove packages as
>if we were a production system.
>
> Delete what exactly? We were talking about _adding_ a package.
Jeff Bailey <[EMAIL PROTECTED]> writes:
> On Tue, Dec 17, 2002 at 11:07:35AM -0800, Thomas Bushnell, BSG wrote:
>
> > > Without ext2fs the system is completly unusable, without random the
> > > system is quite usable. Without GNU Mach you don't even have a
&
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes:
> Without ext2fs the system is completly unusable, without random the
> system is quite usable. Without GNU Mach you don't even have a
> working system.
But you said that "bad security is worse than no security". So better
no GNU Mach than an insec
Moritz Schulte <[EMAIL PROTECTED]> writes:
> Michal 'hramrach' Suchanek <[EMAIL PROTECTED]> writes:
>
> > - the separation of partitions should be solved by union(shadow)fs
> > and not directories
>
> I have one doubt about using a unionfs as root filesystem:
> performance.
Why do you think i
Philip Charles <[EMAIL PROTECTED]> writes:
> The typescript of an fsck. A mild corruption. A full scale corruption
> means that the floppy cannot be mounted or the network setup. The
> typescript itself is rather scrambled.
You mention a floppy. Are you popping the floppy out in mid-write?
Th
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> On Mon, Dec 16, 2002 at 08:32:18PM -0500, Neal H. Walfield wrote:
> > > Disk hardware guarantees that a sector write can always be completed
> > > even if the power goes out partway through. That means that writing a
> > > single sector *is* always a
[EMAIL PROTECTED] (Neal H. Walfield) writes:
> > Disk hardware guarantees that a sector write can always be completed
> > even if the power goes out partway through. That means that writing a
> > single sector *is* always atomic.
>
> The size of a single sector does not necessarily equal the siz
[EMAIL PROTECTED] (Neal H. Walfield) writes:
> > ext2fs should be quite robust: Even pulling the plug at any time should not
> > corrupt the filesystem beyond what e2fsck can repair.
>
> Let us assume that ext2fs writes a block of metadata to disk. In the
> kernel, in the middle of the DMA opera
Jeff Bailey <[EMAIL PROTECTED]> writes:
> In fact, I think I presented clearly that *I* thought that there might
> be value in eliminating sbin iff it could be shown that a very high
> percentage of the utilities were useful to a competent user.
I think that consistency with GNU/Linux systems is
Robert Millan <[EMAIL PROTECTED]> writes:
> On Sat, Nov 09, 2002 at 01:57:31PM -0500, Richard Kreuter wrote:
> >
> > Also, unfortunately, at the moment, the body of FHS requires mkfs,
> > fsck, et al. in /sbin, if these files exist on a system (section
> > 3.14.2), so Debian GNU/Hurd may need t
Jeff Bailey <[EMAIL PROTECTED]> writes:
> My point was that if we can reasonably show that on a GNU/Hurd system
> that most (say 90-95%?) of the commands in sbin would be reasonable for
> a power user to use there is probably value in just having that in the
> general users path.
You seem to be a
Jeff Bailey <[EMAIL PROTECTED]> writes:
> It's questionable that they should be artificially hidden in the first
> place, but hey. =)
The purpose of /sbin is not to "hide" anything, but to avoid
cluttering users' command namespace with commands they can't usefully
ever use.
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> The only "standard" that is applicable here is that of the IA32
> architecture and the peripherial devices, not all of those latter are well
> standardized. As the Hurd certainly runs on an IA32 machine (it runs on
> mine!), any problem of running it
[EMAIL PROTECTED] (Alfred M. Szmidt) writes:
> I really would like to know who everyone is here, there are already a
> couple questions about Daniel's response to me on the FHS list about
> not a distribution is not allowed to add root-level directories.
Sorry, I can't even parse that.
> For exa
[EMAIL PROTECTED] (Alfred M. Szmidt) writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > 1) What gets added to the FHS is not a Debian decision,
> > 2) Debian released architectures need to conform to FHS, and
> > 3) Ports still being worked on don't n
[EMAIL PROTECTED] (Alfred M. Szmidt) writes:
> Jeff Bailey <[EMAIL PROTECTED]> writes:
> > Debian's glibc package currently defines $(prefix)/libexec to
> > $(prefix)/lib everywhere except on hurd-i386. I would like to correct
> > this so that we're the same as other arch's. (There should be no
Roger Leigh <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > Jeff Bailey <[EMAIL PROTECTED]> writes:
> >
> > > The issues is that by Debian policy, all Debian ports must follow the
> > > FHS. The same is true
Jeff Bailey <[EMAIL PROTECTED]> writes:
> I didn't really follow the earlier discussions on this - Can you
> remind me what mailing list it was on? The idea of libexec being in a
> Hurd annex seems silly (and something a committee would be unlikely to
> accept if we were storing anything other th
Jeff Bailey <[EMAIL PROTECTED]> writes:
> The issues is that by Debian policy, all Debian ports must follow the
> FHS. The same is true of the FreeBSD and NetBSD ports (I only noticed
> this because of the patch to support FreeBSD).
>
> Certainly after */libexec is added into the FHS, we can add
"Yantis Green" <[EMAIL PROTECTED]> writes:
> The rapture is coming soon!! Where are you headed!!
Geez, if it's that much an emergency, you'd think you'd help us finish
our software project before time runs out.
"Niklas Höglund" <[EMAIL PROTECTED]>"@MIT.EDU writes:
> Users can maintain the groups themselves, so one member in the "club" can
> maintain that group if it is named "user_a:club", but I don't think the
> group management can be shared, and one user would "own" the group.
A group can own another
Guillem Jover <[EMAIL PROTECTED]> writes:
> While porting util-linux i've found that in the Hurd there is no define
> for TABDLY and TAB3 when including . I've looked the SUSv2 and
> SUSv3 drafts and it mentions this two defines. Also XTABS is defined, but not
> mentioned in the drafts.
XTABS ca
Anthony Towns writes:
> I'm sorry, but you simply do not get to have it both ways. Either Linux
> systems are an implementation of the GNU system that happens to have a
> Linux kernel, or "GNU/Linux" is an entirely unjust publicity stunt to
> promote a completely separate system.
What are "Linux
Yann Forget <[EMAIL PROTECTED]> writes:
> So, I managed to install it alright, ... but I can't boot it !!!
Do you have a bug report to give?
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
HAESSIG Jean-Christophe <[EMAIL PROTECTED]> writes:
> This is all about modifying the FHS...
Yes, but not on this list. This is not the appropriate place to
discuss FHS modifications.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTE
Is anyone going to Debconf 2? I'm planning my travel schedule for
July, and I need to decide.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
1 - 100 of 362 matches
Mail list logo
