Re: [Leaf-devel] dcd: cleanup issues ???

[Michael D. Schleif]

guitarlynn wrote:
> 
> On Wednesday 10 July 2002 20:06, Michael D. Schleif wrote:
> 
> > Also, in standard dcd v1.0.2, what program uses /etc/rpc?
> 
> NFS and SUN login. I think a few people are using this style
> of access on LEAF boxes.

O, now I see it:

/etc/init.d/mountnfs.sh

OK, /etc/rpc needs to stay . . .

-- 

Best Regards,

mds
mds resource
888.250.3987

Dare to fix things before they break . . .

Our capacity for understanding is inversely proportional to how much we
think we know.  The more I know, the more I know I don't know . . .


---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] dcd: cleanup issues ???

[guitarlynn]

On Wednesday 10 July 2002 20:06, Michael D. Schleif wrote:

> Also, in standard dcd v1.0.2, what program uses /etc/rpc?

NFS and SUN login. I think a few people are using this style
of access on LEAF boxes.

-- 

~Lynn Avants
aka Guitarlynn

guitarlynn at users.sourceforge.net
http://leaf.sourceforge.net

If linux isn't the answer, you've probably got the wrong question!


---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[guitarlynn]

On Wednesday 10 July 2002 19:41, Michael D. Schleif wrote:

> Yes, these are our (leaf) _cvs_ versions.  However, how can a user
> select net-snmp v4.2.4 when my net-snmp version is 1.1?

Well, the editor session that pops up during a commit can be avoided
with the -m "text" switch added to the commit command... I use for
notes based on the change(s) from earlier CVS versions of the same
package. You can use this to differeniate between net-snmp v4.2.4, 
4.2.5, and 5.0.1 (not to mention any other notables you would like
to add). As I am working on doing, if you would like certain versions
of the same CVS file(s) presented in a clear and special manner, simply
link them from a web page that presents this information. 

> > > What should I, joe-leaf-user, expect to find while perusing
> > > ViewCVS?
> >

Joe-User is usually looking for an exact package in CVS rather than
aimlessly attempting to find something random. I think most major
software groups use CVS from linked web pages as well.


> Right now, I'm only thinking about what goes under my devel/helices
> tree.  How that gets tied into dcd, bering, or whatever, is another
> issue, which I've decided to ignore for the moment.  Remember, this
> all started with your request to me to commit my net-snmp packages. 
> I committed the LRP's only, and since I've begun to plan committing
> several other items.  It's this planning that has me hung now; but,
> I'd really like to put that behind me ;>

I think you are doing the smartest thing by planning you tree. A good
plan will save tons of time and effort at a later date by foreseeable
circumstances.
-- 

~Lynn Avants
aka Guitarlynn

guitarlynn at users.sourceforge.net
http://leaf.sourceforge.net

If linux isn't the answer, you've probably got the wrong question!


---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] dcd: cleanup issues ???

[Michael D. Schleif]

"Michael D. Schleif" wrote:
> 

[ snip ]

> One thing that Charles and I want to do is remove all user configurable
> parameters from all init scripts.  To that end, I have reviewed all
> /var/lib/lrpkg/*.conf, based on this list of packages that I use:

[ snip ]

> My removal recommendations are based on functionality currently included
> dcd v1.0.2.

Also, in standard dcd v1.0.2, what program uses /etc/rpc?

-- 

Best Regards,

mds
mds resource
888.250.3987

Dare to fix things before they break . . .

Our capacity for understanding is inversely proportional to how much we
think we know.  The more I know, the more I know I don't know . . .


---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

On Wed, 2002-07-10 at 17:41, Michael D. Schleif wrote:
> 
> Mike Noyes wrote:
> > 
> > On Wed, 2002-07-10 at 15:16, Michael D. Schleif wrote:
> > CVS retains all previous versions of a file in the repository. You can
> > specify a specific version for retrieval.
> > 
> > Example:
> > 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/bin/packages/glibc-2.0/dhclient.lrp
> > 
> > Download version 1.10
> > 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=HEAD&content-type=application/octet-stream
> > 
> > Download version 1.1
> > 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=1.1&content-type=application/octet-stream
> 
> Yes, these are our (leaf) _cvs_ versions.  However, how can a user
> select net-snmp v4.2.4 when my net-snmp version is 1.1?

Michael,
A simple href on a web page will work. Lynn is already doing this on his
pages.

net-snmp.lrp v4.2.4

http://leaf-project.org/devel/guitarlynn/

> > > What happens when I decide that /usr/sbin/ntp_setup actually belongs
> > > /usr/bin/ntp_setup?  Or, /usr/sbin/ntp_setup becomes /usr/bin/setup_ntp?
> > >
> > > Clearly, cvs cannot know my intent, in this regard.  When committing a
> > > directory change, under this scenario, how should it be done?
> > 
> > If we had shell access to the repository, we would hand edit the
> > structure change. SF doesn't allow us shell access to the cvs server, so
> > we need to open SF support requests to make changes like this.
> 
> If this is all that is available to us -- and, really, such requests
> seem to be available to only a few, like you, Mike -- then, it behooves
> me to select a good structure now, before I have to request alot of
> changes.  That is why I belabor this point now.

I understand your concerns, but the SF staff are happy to make any
changes we may need (move, rename, remove). You can talk with them on
irc if you want to verify this(irc.slashnet.org channel #sourceforge).
BTW, I'm there most of the day too.

Note: changes of this type take from 24 to 72 hours of working days to
process. A project admin usually needs to make the requested change.

Note 2: I keep a log of all SF support requests that are opened for our
project in this task.
https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=45595&group_id=13751&group_project_id=5257

Note 3: If you have a problem with one of the SF services please add a
comment to this task.
https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=45594&group_id=13751&group_project_id=5257

> > > What should I, joe-leaf-user, expect to find while perusing ViewCVS?
> > 
> > doc -- released documentation
> > bin/packages -- released packages sorted by library type/revision
> > 
> > binary files for LEAF release/branch tree (write access controlled
> > by lead developer)
> > /bering
> > /dachstein
> > /oxygen
> > /packetfilter
> > /wisp-dist
> > /wrp
> > src -- source code
> 
> Is that like Jeff's earlier directory structure outline, or is this
> referring to the text to include in the cvs commit blurb?

This is the current LEAF repository structure. see
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/


> > Think of the devel tree as individual repositories, and the doc, bin,
> > and src trees as community resources. Did that help?
> 
> Right now, I'm only thinking about what goes under my devel/helices
> tree.  How that gets tied into dcd, bering, or whatever, is another
> issue, which I've decided to ignore for the moment.  Remember, this all
> started with your request to me to commit my net-snmp packages.  I
> committed the LRP's only, and since I've begun to plan committing
> several other items.  It's this planning that has me hung now; but, I'd
> really like to put that behind me ;>

Understood. I'm not sure how I can assist you with this though, as each
developer has different ideas of what a repository should look like.
Maybe these links will help.

CVS Documentation
http://www.cvshome.org/docs/

# Open Source Development with CVS by Karl Fogel
http://cvsbook.red-bean.com/cvsbook.html

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Leaf-devel] dcd: cleanup issues ???

[Michael D. Schleif]

Several months ago, Charles and I had an off-list discussion regarding
several dcd related issues.  I know that he has his todo list, to which
I've contributed possible solutions; but, I also have issues with which
I've struggled on my own.

One thing that Charles and I want to do is remove all user configurable
parameters from all init scripts.  To that end, I have reviewed all
/var/lib/lrpkg/*.conf, based on this list of packages that I use:

bash, bwidth22, daemontl, dhclient, dhcpd, djbutils, dnscache, etc,
ifconfig, ipsec, iptraf, libdb, libm, libpcap, libz, lncurses, local,
lrdline2, mawk, modules, netsnmp, netsnmpd, nmbd-207, ntpclnt, qmail,
ramlog, root, rsync, sftp, ssh, sshd, tcpdump, tinydns, vim, weblet

I am left with three (3) init scripts that require attention, listed
here with my recommendations:

[1] /etc/init.d/netbase (re: /sbin/portmap & inetd)
remove references to portmap; leave inetd

[2] /etc/init.d/netstd_init (re: /usr/sbin/routed)
remove file entirely

[3] /etc/init.d/netstd_misc (re: /usr/sbin/bootparamd)
remove file entirely

My removal recommendations are based on functionality currently included
dcd v1.0.2.

What am I missing?

What do you think?

-- 

Best Regards,

mds
mds resource
888.250.3987

Dare to fix things before they break . . .

Our capacity for understanding is inversely proportional to how much we
think we know.  The more I know, the more I know I don't know . . .


---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Michael D. Schleif]

Mike Noyes wrote:
> 
> On Wed, 2002-07-10 at 15:16, Michael D. Schleif wrote:
> >
> > Jeff Newmiller wrote:
> > >
> > > On Wed, 10 Jul 2002, Michael D. Schleif wrote:
> >
> > > > [1] Should I have separate trees for different underlying versions of
> > > > net-snmp?  For example, I committed net-snmp v4.2.4.  I am contemplating
> > > > building and committing both v4.2.5 and the totally different
> > > > distribution v5.x.  So, one line of thinking is like this:
> > > >
> > > > devel/helices/net-snmp/v4.2.4/netsnmp.lrp ...
> > > > devel/helices/net-snmp/v4.2.5/netsnmp.lrp ...
> > > > devel/helices/net-snmp/v5.0.2/netsnmp.lrp ...
> > >
> > > This seems quite the wrong direction.  CVS is supposed to manage
> > > versioning completely independently of the directory structure.
> >
> > Yes, I agree.  However, I am dealing with somebody else's software and
> > making it suitable for leaf.  Obviously, I can have several iterations
> > of net-snmp v4.2.4 that address various leaf concerns.
> 
> Michael,
> CVS retains all previous versions of a file in the repository. You can
> specify a specific version for retrieval.
> 
> Example:
> 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/bin/packages/glibc-2.0/dhclient.lrp
> 
> Download version 1.10
> 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=HEAD&content-type=application/octet-stream
> 
> Download version 1.1
> 
>http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=1.1&content-type=application/octet-stream

Yes, these are our (leaf) _cvs_ versions.  However, how can a user
select net-snmp v4.2.4 when my net-snmp version is 1.1?

> > What happens when I decide that /usr/sbin/ntp_setup actually belongs
> > /usr/bin/ntp_setup?  Or, /usr/sbin/ntp_setup becomes /usr/bin/setup_ntp?
> >
> > Clearly, cvs cannot know my intent, in this regard.  When committing a
> > directory change, under this scenario, how should it be done?
> 
> If we had shell access to the repository, we would hand edit the
> structure change. SF doesn't allow us shell access to the cvs server, so
> we need to open SF support requests to make changes like this.

If this is all that is available to us -- and, really, such requests
seem to be available to only a few, like you, Mike -- then, it behooves
me to select a good structure now, before I have to request alot of
changes.  That is why I belabor this point now.

[ snip ]

> > What should I, joe-leaf-user, expect to find while perusing ViewCVS?
> 
> doc -- released documentation
> bin/packages -- released packages sorted by library type/revision
> 
> binary files for LEAF release/branch tree (write access controlled
> by lead developer)
> /bering
> /dachstein
> /oxygen
> /packetfilter
> /wisp-dist
> /wrp
> src -- source code

Is that like Jeff's earlier directory structure outline, or is this
referring to the text to include in the cvs commit blurb?

> > I worry, however, if every developer goes about creating some adhoc
> > structure to their liking . . .
> 
> Think of the devel tree as individual repositories, and the doc, bin,
> and src trees as community resources. Did that help?

Right now, I'm only thinking about what goes under my devel/helices
tree.  How that gets tied into dcd, bering, or whatever, is another
issue, which I've decided to ignore for the moment.  Remember, this all
started with your request to me to commit my net-snmp packages.  I
committed the LRP's only, and since I've begun to plan committing
several other items.  It's this planning that has me hung now; but, I'd
really like to put that behind me ;>

-- 

Best Regards,

mds
mds resource
888.250.3987

Dare to fix things before they break . . .

Our capacity for understanding is inversely proportional to how much we
think we know.  The more I know, the more I know I don't know . . .


---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

On Wed, 2002-07-10 at 15:16, Michael D. Schleif wrote:
> 
> Jeff Newmiller wrote:
> > 
> > On Wed, 10 Jul 2002, Michael D. Schleif wrote:
> 
> [ snip ]
> 
> > > [1] Should I have separate trees for different underlying versions of
> > > net-snmp?  For example, I committed net-snmp v4.2.4.  I am contemplating
> > > building and committing both v4.2.5 and the totally different
> > > distribution v5.x.  So, one line of thinking is like this:
> > >
> > > devel/helices/net-snmp/v4.2.4/netsnmp.lrp ...
> > > devel/helices/net-snmp/v4.2.5/netsnmp.lrp ...
> > > devel/helices/net-snmp/v5.0.2/netsnmp.lrp ...
> > 
> > This seems quite the wrong direction.  CVS is supposed to manage
> > versioning completely independently of the directory structure.
> 
> Yes, I agree.  However, I am dealing with somebody else's software and
> making it suitable for leaf.  Obviously, I can have several iterations
> of net-snmp v4.2.4 that address various leaf concerns.

Michael,
CVS retains all previous versions of a file in the repository. You can
specify a specific version for retrieval.

Example:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/bin/packages/glibc-2.0/dhclient.lrp

Download version 1.10
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=HEAD&content-type=application/octet-stream

Download version 1.1
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=1.1&content-type=application/octet-stream


> What happens when I decide that /usr/sbin/ntp_setup actually belongs
> /usr/bin/ntp_setup?  Or, /usr/sbin/ntp_setup becomes /usr/bin/setup_ntp?
> 
> Clearly, cvs cannot know my intent, in this regard.  When committing a
> directory change, under this scenario, how should it be done?

If we had shell access to the repository, we would hand edit the
structure change. SF doesn't allow us shell access to the cvs server, so
we need to open SF support requests to make changes like this.

ref. CVS repository clean-up requests
https://sourceforge.net/tracker/?group_id=1&atid=21


> During commit, I am presented with an editor session, in which I am
> allowed to enter text.  I wonder whether or not this allowance should
> rather be a requirement?
> 
> What is it that this commit blurb is intended to convey?  Is this
> intended to be an introduction to the package?  A simple statement of
> my/leaf or somebody else's version upgraded to whatever?
> 
> What should I, joe-leaf-user, expect to find while perusing ViewCVS?

doc -- released documentation
bin/packages -- released packages sorted by library type/revision

binary files for LEAF release/branch tree (write access controlled
by lead developer)
/bering
/dachstein
/oxygen
/packetfilter
/wisp-dist
/wrp
src -- source code 


> I worry, however, if every developer goes about creating some adhoc
> structure to their liking . . .

Think of the devel tree as individual repositories, and the doc, bin,
and src trees as community resources. Did that help?

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Mike Noyes]

On Wed, 2002-07-10 at 15:39, Charles Steinkuehler wrote:
> > Under this scenario, committing to cvs directory structures, cvs is
> > responsible for knowing whether or not a specific file or directory
> > has changed?  Any change, including mod/grp/own?
> 
> CVS doesn't track file permissions or ownership...just contents.

Charles,
CVS does track the x bit of committed files. The x bit is set on import
and add commands.

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Charles Steinkuehler]

> Yes, I agree.  However, I am dealing with somebody else's software and
> making it suitable for leaf.  Obviously, I can have several iterations
> of net-snmp v4.2.4 that address various leaf concerns.
>
> Also, I must be prepared for somebody else's version upgrades causing
> problems that do not exist in previous versions.  For most part,
> net-snmp v4.2.5 fixes a number of things a small number of people
found
> problematic in v4.2.4.  However, v4.2.5 also created problems for a
> small number of users that did not exist in v4.2.4.
>
> So, in reality, my package has two (2) versioning systems running in
> parallel: somebody else's and leaf/mine.  How can cvs facilitate this
> distinction?

See "Open source development with CVS" by Karl Fogel (Coriolis
press...also, parts are available online).  The last part of chapter 6
has a section on using vendor branches to track 3rd party software.
This basically describes how to import an external code-base into a
local CVS tree, using CVS to track any local changes, and finally how to
import a new release, if/when it becomes available from the 3rd party
(ie the NetSnmp folks).

> Under this scenario, committing to cvs directory structures, cvs is
> responsible for knowing whether or not a specific file or directory
has
> changed?  Any change, including mod/grp/own?

CVS doesn't track file permissions or ownership...just contents.

> What happens when I decide that /usr/sbin/ntp_setup actually belongs
> /usr/bin/ntp_setup?  Or, /usr/sbin/ntp_setup becomes
/usr/bin/setup_ntp?
>
> Clearly, cvs cannot know my intent, in this regard.  When committing a
> directory change, under this scenario, how should it be done?

Moving files once they're in CVS is ugly...see the above reference for
details.  There's a CVS replacement in the works that tries to clean up
a bunch of CVS's rough edges, but it's not in widespread use yet.

Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)



---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]

[Michael D. Schleif]

Jeff Newmiller wrote:
> 
> On Wed, 10 Jul 2002, Michael D. Schleif wrote:

[ snip ]

> > [1] Should I have separate trees for different underlying versions of
> > net-snmp?  For example, I committed net-snmp v4.2.4.  I am contemplating
> > building and committing both v4.2.5 and the totally different
> > distribution v5.x.  So, one line of thinking is like this:
> >
> > devel/helices/net-snmp/v4.2.4/netsnmp.lrp ...
> > devel/helices/net-snmp/v4.2.5/netsnmp.lrp ...
> > devel/helices/net-snmp/v5.0.2/netsnmp.lrp ...
> 
> This seems quite the wrong direction.  CVS is supposed to manage
> versioning completely independently of the directory structure.

Yes, I agree.  However, I am dealing with somebody else's software and
making it suitable for leaf.  Obviously, I can have several iterations
of net-snmp v4.2.4 that address various leaf concerns.

Also, I must be prepared for somebody else's version upgrades causing
problems that do not exist in previous versions.  For most part,
net-snmp v4.2.5 fixes a number of things a small number of people found
problematic in v4.2.4.  However, v4.2.5 also created problems for a
small number of users that did not exist in v4.2.4.

So, in reality, my package has two (2) versioning systems running in
parallel: somebody else's and leaf/mine.  How can cvs facilitate this
distinction?

> > [2] Perhaps, my net-snmp package, for instance, should be in cvs in
> > expanded form, so that when only one (1) or a few file contents change,
> > that will be directly reflected in cvs?  Under this scenario, when only
> > a single file -- perhaps, the primary binary? -- is changed, users can
> > checkout only that file.
> 
> This sounds good.

I am new to cvs; so, bear with me.

Under this scenario, committing to cvs directory structures, cvs is
responsible for knowing whether or not a specific file or directory has
changed?  Any change, including mod/grp/own?

What happens when I decide that /usr/sbin/ntp_setup actually belongs
/usr/bin/ntp_setup?  Or, /usr/sbin/ntp_setup becomes /usr/bin/setup_ntp?

Clearly, cvs cannot know my intent, in this regard.  When committing a
directory change, under this scenario, how should it be done?

> > [3] Item [2] presents a difficulty when a user wants the whole LRP
> > package as one (1) LRP file.  Is there some way to properly archive and
> > compress a cvs directory tree and check that out?
> 
> If possible, but probably not. Probably should use both expanded and
> packaged form.

Yes, I like this, too.

> > [4] I am still confused on how best to handle package descriptions.
> >  presents several
> > TXT files that, once clicked on, present descriptive text regarding the
> > LRP's that reside in versioned directories below this one.  Another
> > example is Jacques Nilo's 
> > wonderful page that links to installation and troubleshooting
> > information.  How are we to do this under cvs?
> 
> After presenting two approaches you use the pronoun "this"??

I am sorry; but, I lumped these two together to make a generic
documentation point.

During commit, I am presented with an editor session, in which I am
allowed to enter text.  I wonder whether or not this allowance should
rather be a requirement?

What is it that this commit blurb is intended to convey?  Is this
intended to be an introduction to the package?  A simple statement of
my/leaf or somebody else's version upgraded to whatever?

What should I, joe-leaf-user, expect to find while perusing ViewCVS?

> CVS is designed to handle directories full of information... so a
> directory tree of html documents is a natural thing to enter.
> 
> An idea...
> 
>   net-snmp/
> README.txt
> package/
>   net-snmp.lrp
> target/
>   etc/
> blahblah
>   usr/
> bin/
>   snmpbinary
>   ...
> doc/
>   index.html
>   images/
> image1.jpg
>   ...
> src/
>   sourcefiles...
> 
> Let CVS deal with versioning.

I rather like this structure.  It is intuitive to navigate, complex
enough to deal with complex packages, and simple enough to maintain.

I worry, however, if every developer goes about creating some adhoc
structure to their liking . . .

OK, yes, it is time to stop worrying about whatever shenanigans some
other might do ;>

> David Douthitt has advocated (and it sounds good to me but I haven't done
> it myself) a mechanism whereby sources obtained from other sources are
> kept in original form and a parallel directory containing patchfiles and
> compilation instructions is generated to allow LEAF-specific modifications
> to be maintained separate from the original source tree if
> necessary.  Read the archives... :)

I've been looking at what others have done and when I looked at David's,
I saw a directory structure that didn't mean anything to me and could
not find any files, other than Makefile.  What am I missing?

-- 

Bes

[Leaf-devel] Tip about the modification to upgrade to libc 2.2

[Etienne Charlier]

Hi,

I used with success the Simon Blake's instructions to upgrade Bering to
Glibc 2.2
I had a small problem and I found the solution by myself but I think I would
be usefull
to put some comments in the mailing list archive...

I built the initrd and root.lrp on a RedHat 7.3 running on a VmWare on My
Laptop.

I burned a bering cd with those files and I tested it on a PII 350 pc ( the
only one in my
home able to boot from a CD-RW disk...
I worked...
I burned a CD-R to use in my "production" machine ( a P133) and
patatra the first instruction in linuxrc gave me an error message more
or less like
signal 4 sent to linuxrc.

After some research, I found that my laptop is a PIII processor and the
glibc installed
by redhat is compiled for i686...


I reinstalled redhat on an old hd on the P133 and I rebuilt the initrd/root
from that
machine and I could boot that CD on the P133

Just my 0.02 E=

Etienne Charlier




---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ???

[Mike Noyes]

On Wed, 2002-07-10 at 13:01, Jeff Newmiller wrote:
> David Douthitt has advocated (and it sounds good to me but I haven't done
> it myself) a mechanism whereby sources obtained from other sources are
> kept in original form and a parallel directory containing patchfiles and
> compilation instructions is generated to allow LEAF-specific modifications
> to be maintained separate from the original source tree if
> necessary.  Read the archives... :)

Jeff,
David's Ports system for packages has my vote for our src/packages tree.
However, there may be problems with it that I'm unaware of, because I'm
not a programmer.

Oxygen base in Ports form:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/ddouthitt/base/

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ???

[Jeff Newmiller]

On Wed, 10 Jul 2002, Michael D. Schleif wrote:

> 
> Mike and I were discussing cvs off-list.  Since much of this is
> un-structured now, perhaps, we can impose some user-friendly and
> consistent form on our cvs tree.

A topic with a long history...

> I am starting to realize that, perhaps, I should take a directory based
> approach to helices' cvs tree.
> 
> I have not settled on any particular structure.  However, I am wondering
> about several things:
> 
> [1] Should I have separate trees for different underlying versions of
> net-snmp?  For example, I committed net-snmp v4.2.4.  I am contemplating
> building and committing both v4.2.5 and the totally different
> distribution v5.x.  So, one line of thinking is like this:
> 
> devel/helices/net-snmp/v4.2.4/netsnmp.lrp
> devel/helices/net-snmp/v4.2.4/netsnmpd.lrp
> devel/helices/net-snmp/v4.2.4/nettrapd.lrp
> devel/helices/net-snmp/v4.2.5/netsnmp.lrp
> devel/helices/net-snmp/v4.2.5/netsnmpd.lrp
> devel/helices/net-snmp/v4.2.5/nettrapd.lrp
> devel/helices/net-snmp/v5.0.2/netsnmp.lrp
> devel/helices/net-snmp/v5.0.2/netsnmpd.lrp
> devel/helices/net-snmp/v5.0.2/nettrapd.lrp
> . . .

This seems quite the wrong direction.  CVS is supposed to manage
versioning completely independently of the directory structure.

> [2] Perhaps, my net-snmp package, for instance, should be in cvs in
> expanded form, so that when only one (1) or a few file contents change,
> that will be directly reflected in cvs?  Under this scenario, when only
> a single file -- perhaps, the primary binary? -- is changed, users can
> checkout only that file.

This sounds good.

> [3] Item [2] presents a difficulty when a user wants the whole LRP
> package as one (1) LRP file.  Is there some way to properly archive and
> compress a cvs directory tree and check that out?

If possible, but probably not. Probably should use both expanded and
packaged form.

> [4] I am still confused on how best to handle package descriptions. 
>  presents several
> TXT files that, once clicked on, present descriptive text regarding the
> LRP's that reside in versioned directories below this one.  Another
> example is Jacques Nilo's 
> wonderful page that links to installation and troubleshooting
> information.  How are we to do this under cvs?

After presenting two approaches you use the pronoun "this"??

CVS is designed to handle directories full of information... so a
directory tree of html documents is a natural thing to enter.

An idea...

  net-snmp/
README.txt
package/
  net-snmp.lrp
target/
  etc/
blahblah
  usr/
bin/
  snmpbinary
  ...
doc/
  index.html
  images/
image1.jpg
  ...
src/
  sourcefiles...

Let CVS deal with versioning.

David Douthitt has advocated (and it sounds good to me but I haven't done
it myself) a mechanism whereby sources obtained from other sources are
kept in original form and a parallel directory containing patchfiles and
compilation instructions is generated to allow LEAF-specific modifications
to be maintained separate from the original source tree if
necessary.  Read the archives... :)

---
Jeff NewmillerThe .   .  Go Live...
DCN:<[EMAIL PROTECTED]>Basics: ##.#.   ##.#.  Live Go...
  Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/BatteriesO.O#.   #.O#.  with
/Software/Embedded Controllers)   .OO#.   .OO#.  rocks...2k
---




---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ???

[Mike Noyes]

On Wed, 2002-07-10 at 12:19, Michael D. Schleif wrote:
> 
> Mike and I were discussing cvs off-list.  Since much of this is
> un-structured now, perhaps, we can impose some user-friendly and
> consistent form on our cvs tree.

Michael,
Remember that your devel/helices tree structure is entirely up to you.

We have structures for our bin and doc trees, but haven't come to a
consensus on src yet.

> I am starting to realize that, perhaps, I should take a directory based
> approach to helices' cvs tree.

This is a good idea.

> I have not settled on any particular structure.  However, I am wondering
> about several things:
> 
> [1] Should I have separate trees for different underlying versions of
> net-snmp?

I don't recommend using version specific names for directories or files
in cvs if at all possible.


> [2] Perhaps, my net-snmp package, for instance, should be in cvs in
> expanded form, so that when only one (1) or a few file contents change,
> that will be directly reflected in cvs?  Under this scenario, when only
> a single file -- perhaps, the primary binary? -- is changed, users can
> checkout only that file.

Again, the structure of your devel/helices tree is up to you.

> [3] Item [2] presents a difficulty when a user wants the whole LRP
> package as one (1) LRP file.  Is there some way to properly archive and
> compress a cvs directory tree and check that out?

You can tag the files, and export them for packaging purposes. ref.
http://cvsbook.red-bean.com/cvsbook.html#Exporting_For_Public_Distribution

Packages that are ready for general consumption should be committed to
our bin/packages tree in cvs. I hope to have this tree exporting nightly
to our pub directory on the SF shell server this month.

> [4] I am still confused on how best to handle package descriptions. 
>  presents several
> TXT files that, once clicked on, present descriptive text regarding the
> LRP's that reside in versioned directories below this one.  Another
> example is Jacques Nilo's 
> wonderful page that links to installation and troubleshooting
> information.  How are we to do this under cvs?

I'd like people to start familiarizing themselves with phpWebSite (see
demo link below). Instead of using the devel tree on the shell server
for web content I'd like use to use phpWebSite. Page creation and menu
placement is fairly easy. Everyone of our project members has an
admin/author account for phpWebSite. Contact me off list if you don't
have your login information yet.

Note: the demo is using 0.8.2 and we are using 0.8.1.1.
http://phpwebsite.appstate.edu/demo/

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Leaf-devel] CVS structure ???

[Michael D. Schleif]

Mike and I were discussing cvs off-list.  Since much of this is
un-structured now, perhaps, we can impose some user-friendly and
consistent form on our cvs tree.

I am starting to realize that, perhaps, I should take a directory based
approach to helices' cvs tree.

I have not settled on any particular structure.  However, I am wondering
about several things:

[1] Should I have separate trees for different underlying versions of
net-snmp?  For example, I committed net-snmp v4.2.4.  I am contemplating
building and committing both v4.2.5 and the totally different
distribution v5.x.  So, one line of thinking is like this:

devel/helices/net-snmp/v4.2.4/netsnmp.lrp
devel/helices/net-snmp/v4.2.4/netsnmpd.lrp
devel/helices/net-snmp/v4.2.4/nettrapd.lrp
devel/helices/net-snmp/v4.2.5/netsnmp.lrp
devel/helices/net-snmp/v4.2.5/netsnmpd.lrp
devel/helices/net-snmp/v4.2.5/nettrapd.lrp
devel/helices/net-snmp/v5.0.2/netsnmp.lrp
devel/helices/net-snmp/v5.0.2/netsnmpd.lrp
devel/helices/net-snmp/v5.0.2/nettrapd.lrp
. . .

[2] Perhaps, my net-snmp package, for instance, should be in cvs in
expanded form, so that when only one (1) or a few file contents change,
that will be directly reflected in cvs?  Under this scenario, when only
a single file -- perhaps, the primary binary? -- is changed, users can
checkout only that file.

[3] Item [2] presents a difficulty when a user wants the whole LRP
package as one (1) LRP file.  Is there some way to properly archive and
compress a cvs directory tree and check that out?

[4] I am still confused on how best to handle package descriptions. 
 presents several
TXT files that, once clicked on, present descriptive text regarding the
LRP's that reside in versioned directories below this one.  Another
example is Jacques Nilo's 
wonderful page that links to installation and troubleshooting
information.  How are we to do this under cvs?

What do you think?

-- 

Best Regards,

mds
mds resource
888.250.3987

Dare to fix things before they break . . .

Our capacity for understanding is inversely proportional to how much we
think we know.  The more I know, the more I know I don't know . . .


---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Leaf-devel] ViewCVS download

[Mike Noyes]

Everyone,
Lynn found a way to ensure files are downloaded from cvs as binaries. He
changed the content type at the end of the ViewCVS download url to
application/octet-stream.

-- 
Mike Noyes <[EMAIL PROTECTED]>
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/



---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel