Hi,
A branch to develop the new XSL stylesheets has been justs created. To work
with that branch:
$ svn co svn+ssh://[EMAIL PROTECTED]/LFS/trunk/BOOK new-xsl
$ cd new-xsl/stylesheets
$ svn switch svn+ssh://[EMAIL PROTECTED]/LFS/branches/new-xsl .
>From now on, an "svn up" on the new-xsl/ dir wi
After quite a bit of analysis and other research, I have found that the
Linux Test Project mincore01 (memory-in-core) tests are invalid in that
they always expect a failure when a success is sometimes valid.
I learned a lot from this exercise as I had to instrument the kernel
with printk statement
I dunno if any of you have tried it, but we can use nobody for the Coreutils
tests. Add "nogroup" and "nobody" to /etc/group, and "nobody" in /etc/passwd
in the "nobody" group. For the src/su command, add '-s /bin/sh' so
that /bin/false won't be used.
I'd also like to suggest we use /sbin/nolog
On 3/25/07, Robert Connolly <[EMAIL PROTECTED]> wrote:
> I dunno if any of you have tried it, but we can use nobody for the Coreutils
> tests. Add "nogroup" and "nobody" to /etc/group, and "nobody" in /etc/passwd
> in the "nobody" group. For the src/su command, add '-s /bin/sh' so
> that /bin/false
Dan Nicholson wrote:
> On 3/25/07, Robert Connolly <[EMAIL PROTECTED]> wrote:
>> I dunno if any of you have tried it, but we can use nobody for the Coreutils
>> tests. Add "nogroup" and "nobody" to /etc/group, and "nobody" in /etc/passwd
>> in the "nobody" group. For the src/su command, add '-s /bi
On 3/21/07, Matthew Burgess <[EMAIL PROTECTED]> wrote:
> I'd be interested if you can reproduce your tens of failures using jhalfs, if
> only to rule out a) mistakes in any build scripts you might be using and/or
> b) mistakes made when copying/pasting/typing the commands from the book.
> scripts
On 3/25/07, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
> Dan Nicholson wrote:
> > On 3/25/07, Robert Connolly <[EMAIL PROTECTED]> wrote:
> >> I dunno if any of you have tried it, but we can use nobody for the
> >> Coreutils
> >> tests. Add "nogroup" and "nobody" to /etc/group, and "nobody" in
> >> /e
Dan Nicholson wrote:
> On 3/25/07, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
>> Dan Nicholson wrote:
>>> On 3/25/07, Robert Connolly <[EMAIL PROTECTED]> wrote:
I dunno if any of you have tried it, but we can use nobody for the
Coreutils
tests. Add "nogroup" and "nobody" to /etc/group,
Fix wrote:
> Nevertheless, now I've finished building a __pure__ 64-bit *LFS
> without use of the cross compilation, with slight deviations from the
> book. All the libraries now are 64-bit and they're placed in
> {,/usr}/lib instead of {,/usr}/lib64. In order to achieve this, six
> different patc
On 3/25/07, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
> Dan Nicholson wrote:
> > On 3/25/07, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
> >> I don't agree. The nobody user should never have a valid login shell or
> >> home directory. If a temporary user is needed for the Coreutils tests,
> >> add a temp
On Sunday March 25 2007 22:30, Dan Nicholson wrote:
> Also, I'm wondering if there would be problems running scripts, etc.,
> when HOME=/dev/null. The dummy user we create for coreutils is given
> /root as it's home directory. Robert, do you see any issues running
> the testsuites as nobody?
I use
Robert Connolly wrote:
> On Sunday March 25 2007 22:30, Dan Nicholson wrote:
>> Also, I'm wondering if there would be problems running scripts, etc.,
>> when HOME=/dev/null. The dummy user we create for coreutils is given
>> /root as it's home directory. Robert, do you see any issues running
>> the
On 3/26/07, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
>
> Some benchmarks against a 32-bit build would be interesting. My
> understanding is that 64-bit systems have larger binaries, use more ram,
> and are slower the equivalent 32-bit systems unless you are doing some
> fairly serious number crunch
Fix wrote:
> On 3/26/07, Bruce Dubbs <[EMAIL PROTECTED]> wrote:
>> Some benchmarks against a 32-bit build would be interesting. My
>> understanding is that 64-bit systems have larger binaries, use more ram,
>> and are slower the equivalent 32-bit systems unless you are doing some
>> fairly seriou
On Monday March 26 2007 01:11, Bruce Dubbs wrote:
> The use of 65534 for a uid or gid is not a good idea. It comes from old
> time usage in nfs and nowhere else. *If* nfs does not find a nobody
> user, it defaults to -2. Since the uid/gid are 16 bit numbers, this
> equates to 65534. There are t
On 3/25/07, Robert Connolly <[EMAIL PROTECTED]> wrote:
>
> Using 99 works, but I think 65534 is more widely understood as the 'nobody'
> ID... in that if you see a uid 65534 in a tar archive you automatically know
> it once belonged to 'nobody'. A group ID of 65533 would be easy to assume as
> a cl
Robert Connolly wrote:
> On Monday March 26 2007 01:11, Bruce Dubbs wrote:
>> The use of 65534 for a uid or gid is not a good idea. It comes from old
>> time usage in nfs and nowhere else. *If* nfs does not find a nobody
>> user, it defaults to -2. Since the uid/gid are 16 bit numbers, this
>> e
17 matches
Mail list logo
