On Thu, Apr 27, 2006 at 11:38:17PM +0200, Michael Kerrisk wrote: > Justin, > > > > > Tags: upstream > > > > > > Any time you open a report like this you better make sure > > > that whatever you say holds against the latest upstream release. > > Do you mean of manpages? > > Yes. I mean, if you open a report and immedaitely tag it "upstream" means that the bug is not in the Debian .diff.gz, and the version indicates what version the bug was found in. IMO a "debian-diff" tag would've been much better than an "upstream" tag, since 1. only a small fraction of bugs are introduced in the .diff.gz (and are not feature requests), and 2. only a small fraction of upstream bugs are actually tagged as such, which makes the tag much less useful.
> > const int flags=0x0001ffff|0x00000200; /* CLONE_NEWNS|CLONE_FS; */ > > // 0x00000800; /* CLONE_SIGHAND */ > > // 0x00010000; /* CLONE_THREAD */ > > Why are you hard coding these constants? They are in sched.h. > If you had done that you would not have made the following blunder: I'm not allowed to include bits/sched.h directly, linux/sched.h gives pages of errors, and just sched.h causes bits/sched.h to include a "conflicting type for clone" (because it is using the libc definition, which wants 4 arguments). > /usr/include/bits/sched.h:# define CLONE_NEWNS 0x00020000 Good catch, although the source of my problem, I think, was checking for clone()==-1, instead of clone()<0: I just retried with the libc clone(), too, and the 3 things which are supposed to fail (and which *do* fail at the kernel level) do not fail at the libc level. Perhaps it is "fixing up" my flags before passing them on to the kernel? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
