headers
Hubert Feyrer | 1 Nov 2006 15:05
Picon
Favicon

makefs problem [was: Re: Enabling LFS in sysinst (and moving lfs_cleanerd)]

On Sun, 29 Oct 2006, Julio M. Merino Vidal wrote:
> Mmm, no.  I ran a full release build, then went to
> distrib/i386/cdroms/bootcd and ran this there:
>
> $ nbmake-i386 clean dependall release CDRELEASE=true
>
> Seeing the failure I recreated the image by running makefs manually as
> distrib/common/Makefile.bootcd's "image" target says and it failed the
> same way.  (That's where I added the 'rockridge' option, but haven't
> committed it because of the other problem that appeared.)

I've had a look, and it seems that indeed makefs seems to break things. :(

Who's our makefs/cd9660 hacker? (not me!)

  - Hubert
Permalink | Reply | 13 comments |
headers
Hubert Feyrer | 1 Nov 2006 17:32
Picon
Favicon

Re: makefs problem [was: Re: Enabling LFS in sysinst (and moving lfs_cleanerd)]

On Wed, 1 Nov 2006, Hubert Feyrer wrote:
>> $ nbmake-i386 clean dependall release CDRELEASE=true
...
> I've had a look, and it seems that indeed makefs seems to break things. :(

Er, wait... it may actually help to pass '-o rockridge' to makefs.
Investigating, stay tuned!

  - Hubert
Permalink | Reply | 11 comments |
headers
Hubert Feyrer | 1 Nov 2006 17:47
Picon
Favicon

Re: makefs problem [was: Re: Enabling LFS in sysinst (and moving lfs_cleanerd)]

On Wed, 1 Nov 2006, Hubert Feyrer wrote:
>>> $ nbmake-i386 clean dependall release CDRELEASE=true

Make sure you have rev. 1.4 of src/distrib/common/Makefile.bootcd and 
retry - I didn't enable rockridge extensions for the CDs. Lame...

  - Hubert
Permalink | Reply | 0 comments |
headers
Julio M. Merino Vidal | 1 Nov 2006 17:42
Picon

Re: makefs problem [was: Re: Enabling LFS in sysinst (and moving lfs_cleanerd)]

On 11/1/06, Hubert Feyrer <hubert <at> feyrer.de> wrote:
> On Wed, 1 Nov 2006, Hubert Feyrer wrote:
> >> $ nbmake-i386 clean dependall release CDRELEASE=true
> ...
> > I've had a look, and it seems that indeed makefs seems to break things. :(
>
> Er, wait... it may actually help to pass '-o rockridge' to makefs.
> Investigating, stay tuned!

Yes, it certainly helps.  But then the file names are normalized
somehow and therefore cannot be recognized by the installer.  For
example, kern-GENERIC.tgz becomes kern_generic.tgz, and similarly for
all other names that contain dashes or upper case letters.

--

-- 
Julio M. Merino Vidal <jmmv84 <at> gmail.com>
The Julipedia - http://julipedia.blogspot.com/
Permalink | Reply | 9 comments |
headers
Hubert Feyrer | 1 Nov 2006 17:52
Picon
Favicon

Re: makefs problem [was: Re: Enabling LFS in sysinst (and moving lfs_cleanerd)]

On Wed, 1 Nov 2006, Julio M. Merino Vidal wrote:
> Yes, it certainly helps.  But then the file names are normalized
> somehow and therefore cannot be recognized by the installer.  For
> example, kern-GENERIC.tgz becomes kern_generic.tgz, and similarly for
> all other names that contain dashes or upper case letters.

That "normalization" was what happened for me before I enabled rockridge 
extensions. Things seem to work for me now - I cannot really test it as I 
couldn't do a full build, but the kernels are found properly by sysinst.

  - Hubert
Permalink | Reply | 5 comments |
headers
Thor Lancelot Simon | 1 Nov 2006 18:32

Re: makefs problem [was: Re: Enabling LFS in sysinst (and moving lfs_cleanerd)]

On Wed, Nov 01, 2006 at 05:42:03PM +0100, Julio M. Merino Vidal wrote:
> On 11/1/06, Hubert Feyrer <hubert <at> feyrer.de> wrote:
> >On Wed, 1 Nov 2006, Hubert Feyrer wrote:
> >>> $ nbmake-i386 clean dependall release CDRELEASE=true
> >...
> >> I've had a look, and it seems that indeed makefs seems to break things. 
> >:(
> >
> >Er, wait... it may actually help to pass '-o rockridge' to makefs.
> >Investigating, stay tuned!
> 
> Yes, it certainly helps.  But then the file names are normalized
> somehow and therefore cannot be recognized by the installer.

If that's true, then it's a bug -- the whole point of the rockridge
extensions is that they are supposed to make such normalization *not*
happen.

It was the case at one time, though, that our sets were named so that
it would not matter.  It would be irritating to have to fix things now
so that they worked that way again, however...

Thor
Permalink | Reply | 0 comments |
headers
Chuck Cranor | 1 Nov 2006 19:11
Picon
Favicon

cscope

hi-

   I propose that we import cscope into our source tree.
It is open source and has a BSD license (see http://cscope.sourceforge.net/ ).
It is also an improvement over /usr/bin/ctags.

   I also think we should take advantage of being an open source project 
and look into providing better indexing of our source tree.  Our current
efforts on this front are broken (/var/db/libc.tags is not useful, see
PR 34913).  I would like to see us use better tools (e.g. cscope) and
provide more coverage (e.g. not just libc).

   Locally, I've been indexing the entire NetBSD "src" module with cscope
and I've found that quite useful.   It takes about 1 minute to index 3.0
on my 1.7GHz i386 desktop (the resulting index is ~400MB).

   It would also be nice to provide a web-based view into the source
tree, kind of like what open solaris does (but maybe without java and
all the baggage it brings).   see http://cvs.opensolaris.org/source/
for an example.

chuck
Permalink | Reply | 16 comments |
headers
M J Fleming | 1 Nov 2006 19:22
Picon

Re: cscope

On Wed, Nov 01, 2006 at 01:11:12PM -0500, Chuck Cranor wrote:
> hi-
> 
>    I propose that we import cscope into our source tree.
> It is open source and has a BSD license (see http://cscope.sourceforge.net/ ).
> It is also an improvement over /usr/bin/ctags.
>

I'm all for this. cscope is an invaluable tool.

Matt
Permalink | Reply | 0 comments |
headers
Hubert Feyrer | 1 Nov 2006 19:27
Picon
Favicon

Re: cscope


[here we go again...]

On Wed, 1 Nov 2006, Chuck Cranor wrote:
>   I also think we should take advantage of being an open source project
> and look into providing better indexing of our source tree.  Our current
> efforts on this front are broken (/var/db/libc.tags is not useful, see
> PR 34913).  I would like to see us use better tools (e.g. cscope) and
> provide more coverage (e.g. not just libc).

What would be the benefit of having this in-tree over installing it from 
pkgsrc?

(I agree that offering a fully indexed tree, possibly via the web, is a 
good thing. My concern here is bloat of the 'core' operating system)

  - Hubert
Permalink | Reply | 7 comments |
headers
Jason Thorpe | 1 Nov 2006 19:42

Re: cscope


On Nov 1, 2006, at 10:11 AM, Chuck Cranor wrote:

> hi-
>
>    I propose that we import cscope into our source tree.
> It is open source and has a BSD license (see http://cscope.sourceforge.net/ 
>  ).
> It is also an improvement over /usr/bin/ctags.

OS X has cscope built-in, and I find it useful.  I still like id-utils  
better for some things, but I have gotten quite used to cscope.

>    I also think we should take advantage of being an open source  
> project
> and look into providing better indexing of our source tree.  Our  
> current
> efforts on this front are broken (/var/db/libc.tags is not useful, see
> PR 34913).  I would like to see us use better tools (e.g. cscope) and
> provide more coverage (e.g. not just libc).

I think this is a good idea.

>    Locally, I've been indexing the entire NetBSD "src" module with  
> cscope
> and I've found that quite useful.   It takes about 1 minute to index  
> 3.0
> on my 1.7GHz i386 desktop (the resulting index is ~400MB).

Yah, cscope is pretty fast.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane