Re: [leaf-devel] cvs structure
On Mon, 2010-11-22 at 23:11 +0100, KP Kirchdoerfer wrote: Am Montag, 1. November 2010, 22:04:59 schrieb davidMbrooke: On Mon, 2010-11-01 at 21:32 +0100, KP Kirchdoerfer wrote: David; Am Sonntag, 31. Oktober 2010, 22:09:54 schrieb davidMbrooke: On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote: Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew: Ok; I propose: - just core and contrib repository (names are not fixed), testing isn't needed - we can also put packages in contrib which we consider for testing or provided as-is. Just to make sure I understand 100%, some examples: etc.lrp: Certainly part of core. No debate. Maybe this also debatable :) The most radical way (besides opening it all) would be just to define core just as buildenv and buildtool itself. Which is the bare minimum to build packages on a definded base (uclibc version). Though even that raises pb's. What if a user wants to provide a complete new kernel arch? And in the developer guidelines and policies we asked to provide modules not in the package, but with modules.tgz During 2.x and 3.x we thought about core mainly as packages that are provided on the floppy image - but as that donÄt exist any longer..., and it doesn't work very well in the long term. asterisk.lrp: Certainly part of contrib (only if it is fixed?) aiccu.lrp: Not part of core, since only relevant to some users, but you (kp) and I (dMb) would be willing to upgrade, test, repair etc. Both belongs shurely to contrib Should we distinguish supported contrib from unsupported contrib? Something like primary (instead of core - approx 10 packages that EVERY user will need), secondary (tested and supported, but not core), then contrib for the others? Hmm, the idea of approx 10 packages that every users need is a good one. Your secondary and contrib maybe rephrased as packages and testing? (primary/packages/testing) kp Hi kp, To me, testing implies a temporary state: will move somewhere else when testing is successful, which isn't quite what I had in mind. A package in contrib will always stay in contrib... In terms of packages (i.e. ignoring buildenv and buildtool) then core or primary is: - kernel (OK, not really a package as such...) - initrd - root - etc - modules Would a system actually run with just this list (+ moddb + configdb)? Then there are mainstream add-on packages: - iptables - shorwall - Hence also libm, perl - ip6tables - shorwall6 - dropbear - dhcpcd - dnsmasq - mhttpd - webconf - A few more perhaps? Others would be contrib. So maybe 3 categories: core, mainstream, contrib ??? dMb David; I've slept and thought over this the past weeks. In the meantime Erich has been added to the list of developers being able to commit and it worked out pretty well. I've made the experience in the past that too restrictive settings are more a loss than a win. So I think we may go with a more open-minded and easy-to-understand rule. Current cvs should be open to every LEAF developers who asks for write permission - assuming everyone is aware of the responsibility having write permissions. A contrib section should be added with write permissions for everyone who has been added as LEAF developer. Sounds easy and effetive to me :) kp Hi kp, I like to keep things simple so sure, let's go with what you propose. In terms of write access there would be no difference between my core and mainstream anyway. (Only difference would have been the level of support and testing, and the intent to widen the development team.) dMb -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] cvs structure
Am Montag, 1. November 2010, 22:04:59 schrieb davidMbrooke: On Mon, 2010-11-01 at 21:32 +0100, KP Kirchdoerfer wrote: David; Am Sonntag, 31. Oktober 2010, 22:09:54 schrieb davidMbrooke: On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote: Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew: Ok; I propose: - just core and contrib repository (names are not fixed), testing isn't needed - we can also put packages in contrib which we consider for testing or provided as-is. Just to make sure I understand 100%, some examples: etc.lrp: Certainly part of core. No debate. Maybe this also debatable :) The most radical way (besides opening it all) would be just to define core just as buildenv and buildtool itself. Which is the bare minimum to build packages on a definded base (uclibc version). Though even that raises pb's. What if a user wants to provide a complete new kernel arch? And in the developer guidelines and policies we asked to provide modules not in the package, but with modules.tgz During 2.x and 3.x we thought about core mainly as packages that are provided on the floppy image - but as that donÄt exist any longer..., and it doesn't work very well in the long term. asterisk.lrp: Certainly part of contrib (only if it is fixed?) aiccu.lrp: Not part of core, since only relevant to some users, but you (kp) and I (dMb) would be willing to upgrade, test, repair etc. Both belongs shurely to contrib Should we distinguish supported contrib from unsupported contrib? Something like primary (instead of core - approx 10 packages that EVERY user will need), secondary (tested and supported, but not core), then contrib for the others? Hmm, the idea of approx 10 packages that every users need is a good one. Your secondary and contrib maybe rephrased as packages and testing? (primary/packages/testing) kp Hi kp, To me, testing implies a temporary state: will move somewhere else when testing is successful, which isn't quite what I had in mind. A package in contrib will always stay in contrib... In terms of packages (i.e. ignoring buildenv and buildtool) then core or primary is: - kernel (OK, not really a package as such...) - initrd - root - etc - modules Would a system actually run with just this list (+ moddb + configdb)? Then there are mainstream add-on packages: - iptables - shorwall - Hence also libm, perl - ip6tables - shorwall6 - dropbear - dhcpcd - dnsmasq - mhttpd - webconf - A few more perhaps? Others would be contrib. So maybe 3 categories: core, mainstream, contrib ??? dMb David; I've slept and thought over this the past weeks. In the meantime Erich has been added to the list of developers being able to commit and it worked out pretty well. I've made the experience in the past that too restrictive settings are more a loss than a win. So I think we may go with a more open-minded and easy-to-understand rule. Current cvs should be open to every LEAF developers who asks for write permission - assuming everyone is aware of the responsibility having write permissions. A contrib section should be added with write permissions for everyone who has been added as LEAF developer. Sounds easy and effetive to me :) kp -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] cvs structure
On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote: -snip- Ok; I propose: - just core and contrib repository (names are not fixed), testing isn't needed - we can also put packages in contrib which we consider for testing or provided as-is. - lrp's and sources are required for both to be inline with the SF requirements. About write permissons: contrib should be open to all leaf-developers, what about the core? We may give write permissions to core by request... Everyone, Current CVSROOT/avail global access. Modify as necessary. # Global access for all project members avail||bin/packages/glibc-2.0 avail||bin/packages/glibc-2.1 avail||bin/packages/glibc-2.2 avail||bin/packages/nolibc avail||bin/packages/uclibc-0.9/20/contrib avail||bin/packages/uclibc-0.9/28/contrib avail||doc/docmanager avail||doc/howto avail||doc/man avail||doc/network_diagrams avail||src/bering-uclibc/contrib opinions? -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, sourceforge/sitedocs -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] cvs structure
David; Am Sonntag, 31. Oktober 2010, 22:09:54 schrieb davidMbrooke: On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote: Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew: Ok; I propose: - just core and contrib repository (names are not fixed), testing isn't needed - we can also put packages in contrib which we consider for testing or provided as-is. Just to make sure I understand 100%, some examples: etc.lrp: Certainly part of core. No debate. Maybe this also debatable :) The most radical way (besides opening it all) would be just to define core just as buildenv and buildtool itself. Which is the bare minimum to build packages on a definded base (uclibc version). Though even that raises pb's. What if a user wants to provide a complete new kernel arch? And in the developer guidelines and policies we asked to provide modules not in the package, but with modules.tgz During 2.x and 3.x we thought about core mainly as packages that are provided on the floppy image - but as that donÄt exist any longer..., and it doesn't work very well in the long term. asterisk.lrp: Certainly part of contrib (only if it is fixed?) aiccu.lrp: Not part of core, since only relevant to some users, but you (kp) and I (dMb) would be willing to upgrade, test, repair etc. Both belongs shurely to contrib Should we distinguish supported contrib from unsupported contrib? Something like primary (instead of core - approx 10 packages that EVERY user will need), secondary (tested and supported, but not core), then contrib for the others? Hmm, the idea of approx 10 packages that every users need is a good one. Your secondary and contrib maybe rephrased as packages and testing? (primary/packages/testing) kp -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] cvs structure
On Mon, 2010-11-01 at 21:32 +0100, KP Kirchdoerfer wrote: David; Am Sonntag, 31. Oktober 2010, 22:09:54 schrieb davidMbrooke: On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote: Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew: Ok; I propose: - just core and contrib repository (names are not fixed), testing isn't needed - we can also put packages in contrib which we consider for testing or provided as-is. Just to make sure I understand 100%, some examples: etc.lrp: Certainly part of core. No debate. Maybe this also debatable :) The most radical way (besides opening it all) would be just to define core just as buildenv and buildtool itself. Which is the bare minimum to build packages on a definded base (uclibc version). Though even that raises pb's. What if a user wants to provide a complete new kernel arch? And in the developer guidelines and policies we asked to provide modules not in the package, but with modules.tgz During 2.x and 3.x we thought about core mainly as packages that are provided on the floppy image - but as that donÄt exist any longer..., and it doesn't work very well in the long term. asterisk.lrp: Certainly part of contrib (only if it is fixed?) aiccu.lrp: Not part of core, since only relevant to some users, but you (kp) and I (dMb) would be willing to upgrade, test, repair etc. Both belongs shurely to contrib Should we distinguish supported contrib from unsupported contrib? Something like primary (instead of core - approx 10 packages that EVERY user will need), secondary (tested and supported, but not core), then contrib for the others? Hmm, the idea of approx 10 packages that every users need is a good one. Your secondary and contrib maybe rephrased as packages and testing? (primary/packages/testing) kp Hi kp, To me, testing implies a temporary state: will move somewhere else when testing is successful, which isn't quite what I had in mind. A package in contrib will always stay in contrib... In terms of packages (i.e. ignoring buildenv and buildtool) then core or primary is: - kernel (OK, not really a package as such...) - initrd - root - etc - modules Would a system actually run with just this list (+ moddb + configdb)? Then there are mainstream add-on packages: - iptables - shorwall - Hence also libm, perl - ip6tables - shorwall6 - dropbear - dhcpcd - dnsmasq - mhttpd - webconf - A few more perhaps? Others would be contrib. So maybe 3 categories: core, mainstream, contrib ??? dMb -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] cvs structure
On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote: Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew: Ok; I propose: - just core and contrib repository (names are not fixed), testing isn't needed - we can also put packages in contrib which we consider for testing or provided as-is. Just to make sure I understand 100%, some examples: etc.lrp: Certainly part of core. No debate. asterisk.lrp: Certainly part of contrib (only if it is fixed?) aiccu.lrp: Not part of core, since only relevant to some users, but you (kp) and I (dMb) would be willing to upgrade, test, repair etc. Should we distinguish supported contrib from unsupported contrib? Something like primary (instead of core - approx 10 packages that EVERY user will need), secondary (tested and supported, but not core), then contrib for the others? - lrp's and sources are required for both to be inline with the SF requirements. About write permissons: contrib should be open to all leaf-developers, what about the core? We may give write permissions to core by request... Access to core works OK by current mechanism, IMHO. opinions? kp -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ???
On Wed, Jul 10, 2002 at 02:19:58PM -0500, 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.4/netsnmpd.lrp Looks good to me, would allow for recursive wget --no-parent or ncftp -R and version management would be a simpler. A copy of the current as devel/helices/net-snmp/current/netsnmpd.lrp or a zero legnth file devel/helices/net-snmp/current-is-v5.0.2 are also helpful; get devel/helices/net-snmp/current-* | sed | ncftpget -R v5.0.2 http://leaf.sourceforge.net/devel/helices/net-snmp/ 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 http://leaf.sourceforge.net/devel/jnilo/ wonderful page that links to installation and troubleshooting information. How are we to do this under cvs? I would put the txt files in the version directores for which they belong. At some point (maybe even by a cgi to select components) a custom disk image might be generated, such a program would have no trouble separating out .txt and .lrp files. // George -- GEORGE GEORGALIS, System Admin/Architectcell: 347-451-8229 Security Services, Web, Mail,mailto:[EMAIL PROTECTED] File, Print, DB and DNS Servers. http://www.galis.org/george --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ???
On Wed, Jul 10, 2002 at 01:01:27PM -0700, Jeff Newmiller wrote: On Wed, 10 Jul 2002, Michael D. Schleif wrote: 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. Yeah, I was thinking about http/ftp access. Looks good. // George -- GEORGE GEORGALIS, System Admin/Architectcell: 347-451-8229 Security Services, Web, Mail,mailto:[EMAIL PROTECTED] File, Print, DB and DNS Servers. http://www.galis.org/george --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. 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 wrote: On Wed, 10 Jul 2002, Michael D. Schleif wrote: [ snip ] 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: [ snip ] 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... [ snip ] I took a liking to this structure, which you can see here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/helices/ I appreciate *ALL* feedback on this infrastructure, before I get carried away with further additions to 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 Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ???
On Wed, Jul 17, 2002 at 03:21:32PM -0500, Michael D. Schleif wrote:
Jeff Newmiller wrote:
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...
[ snip ]
I took a liking to this structure, which you can see here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/helices/
I appreciate *ALL* feedback on this infrastructure, before I get carried
away with further additions to cvs.
What do you think?
My model has been the following:
archives/
somearchive.tar.gz
otherarchive.bz2
...
iproute2/
distinfo
Makefile
patches/
somepatchname.diff
somepatchname2.diff
...
work/ {temporary dir; created and used to compile within}
binaries/ {temporary dir; created and stores binaries ONLY (no path)}
world/{temporary dir; created and used to store full paths
and all files needed within the structure}
otherpkg/
...
My current lrp package setup was to have the following:
iproute2-sourcedir/
lrp/ {created}
...
Under lrp/ there is a Makefile which contains all of the targets to make packages, etc.
There is also a directory like world/ above which contains all paths and a Makefile
in each directory that needs to have a binary in it.
After this lrp/ directory is correctly configured, then the entire directory is
wrapped up into a *.diff file and saved with the unmodified source archive. Examples
of this can be found in the Oxygen/LEAF Resource CDROM.
Perhaps what I will do is to use this patch as a regular patch in the CVS ports tree
and add the patch to the source code, then use it to create packages at will.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ???
David Douthitt wrote:
[ snip ]
My model has been the following:
archives/
somearchive.tar.gz
otherarchive.bz2
...
iproute2/
distinfo
Makefile
patches/
somepatchname.diff
somepatchname2.diff
...
work/ {temporary dir; created and used to compile within}
binaries/ {temporary dir; created and stores binaries ONLY (no path)}
world/{temporary dir; created and used to store full paths
and all files needed within the structure}
otherpkg/
...
My current lrp package setup was to have the following:
iproute2-sourcedir/
lrp/ {created}
...
Under lrp/ there is a Makefile which contains all of the targets to make packages,
etc.
There is also a directory like world/ above which contains all paths and a Makefile
in each directory that needs to have a binary in it.
After this lrp/ directory is correctly configured, then the entire directory is
wrapped up into a *.diff file and saved with the unmodified source archive.
Examples
of this can be found in the Oxygen/LEAF Resource CDROM.
Perhaps what I will do is to use this patch as a regular patch in the CVS ports tree
and add the patch to the source code, then use it to create packages at will.
I've been considering using whatever structure I settle on as my
development environment. I have cvs setup on my own network and hope to
integrate leaf development into my other development projects. However,
cvs doesn't lend itself to this end for several reasons:
[1] Each sandbox includes cvs directories under each directory in the
project. So, rolling up the hierarchy directly into an LRP is
cumbersome. cvs export only adds to the kludge.
[2] Since cvs does not retain group, mode nor ownership attributes, [1]
is further complicated and requires another kludge to correct directory
and files attributes.
[3] I still have not figured out how to force synchronization between
cvs revision numbers and project source revision numbers.
[4] All of this makes inclusion of package/package/package.lrp an
absolute must!
If anybody has overcome any of these obstacles, I'd appreciate
enlightenment . . .
--
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
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ???
On Wed, 2002-07-17 at 15:50, Michael D. Schleif wrote: [2] Since cvs does not retain group, mode nor ownership attributes, [1] is further complicated and requires another kludge to correct directory and files attributes. Michael, This should only be an issue when exporting for public distribution. The recommended solution is a script to export, configure, and package your release. # Exporting For Public Distribution http://cvsbook.red-bean.com/cvsbook.html#Exporting_For_Public_Distribution -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ???
On Wed, Jul 10, 2002 at 01:14:07PM -0700, Mike Noyes wrote: 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/ From having worked with FreeBSD extensively for several months now, I've been discovering more and more about the FreeBSD ports system that I like. I'll be revisiting the CVS tree and possibly updating it. I've been away for a bit, but hope to dive into active development soon. --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
Everyone, I just removed the lowercase enforcement from our repository. If win clients start leaving broken stub files in our repository, we'll need to reexamine this issue. On Thu, 2002-07-11 at 16:59, Mike Noyes wrote: On Thu, 2002-07-11 at 16:12, Manfred Schuler wrote: You should not force all filenames (except Makefile) to lowercase. Some kernel modules have uppercase letters in their names. Also the README files are typically in uppercase. An X terminal dist would have big problems with that rule. I believe this was done to address the following problem: Introduction to SourceForge.net Project CVS Services https://sourceforge.net/docman/display_doc.php?docid=768group_id=1 Case Sensitivity When a developer performs certain types of CVS operations, specifically cvs add and cvs remove, CVS checks the listing of already-deleted files for that directory (i.e. the files in the Attic for that directory) to see if there is a match of the same filename. There is a difference between what MS Windows-based systems consider a match and what case-sensitive operating systems, such as Linux (which is used to provide the project CVS services), see as a match in these cases. If the filename match does not occur on the server, but there would be a case-insensitive match, the Windows-based CVS client will abort its operation and leave a broken stub file within the repository, which must be removed by SourceForge.net staff. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
Ugh, I just reverted to the prior enforce script. I'll take a look at it again in the morning. Currently lowercase name enforcement is active. On Tue, 2002-07-16 at 17:12, Mike Noyes wrote: Everyone, I just removed the lowercase enforcement from our repository. If win clients start leaving broken stub files in our repository, we'll need to reexamine this issue. On Thu, 2002-07-11 at 16:59, Mike Noyes wrote: On Thu, 2002-07-11 at 16:12, Manfred Schuler wrote: You should not force all filenames (except Makefile) to lowercase. Some kernel modules have uppercase letters in their names. Also the README files are typically in uppercase. An X terminal dist would have big problems with that rule. I believe this was done to address the following problem: Introduction to SourceForge.net Project CVS Services https://sourceforge.net/docman/display_doc.php?docid=768group_id=1 Case Sensitivity When a developer performs certain types of CVS operations, specifically cvs add and cvs remove, CVS checks the listing of already-deleted files for that directory (i.e. the files in the Attic for that directory) to see if there is a match of the same filename. There is a difference between what MS Windows-based systems consider a match and what case-sensitive operating systems, such as Linux (which is used to provide the project CVS services), see as a match in these cases. If the filename match does not occur on the server, but there would be a case-insensitive match, the Windows-based CVS client will abort its operation and leave a broken stub file within the repository, which must be removed by SourceForge.net staff. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
Mike Noyes schrieb: [snip] 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=1atid=21 I don't think it is a good idea to make a change like this. If someone wants to retrieve an older version, it does not work because the file he needs is not available anymore. It is better to create the new file in CVS and pin the release/version tag to the new file and not to the old file. [snip] -- Manfred Schuler E_Mail: mailto:[EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
On Thu, 2002-07-11 at 03:56, Manfred Schuler wrote:
Mike Noyes schrieb:
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=1atid=21
I don't think it is a good idea to make a change like this.
If someone wants to retrieve an older version, it does not work
because the file he needs is not available anymore.
It is better to create the new file in CVS and pin the
release/version tag to the new file and not to the old file.
Manfred,
That has not been my experience. When the SF staff moves/renames files
on the SF cvs server they maintain the cvs structure. Talk with Jacob
Moorman, Quality of Service Manager ('moorman' on SourceForge.net,
'moorman' on SlashNET IRC) to verify this if you like.
--
Mike Noyes [EMAIL PROTECTED]
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/
---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases more
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,
I did _NOT_ at all want to criticize the staff at SF.
I know about them only what I see on the list, so I'm
not in a position to judge how they do their job.
I think I didn't express clearly what I mean.
It is meant as a principle when working on large projects:
_NEVER_ change anything that is correctly checked in
I will give you an example of what I mean:
In version 1.0 of package xxx you have 2 script files:
scripta and scriptb
One line in scripta is
source scriptb
Later you decide scriptb is not a good name and you change the name
to scriptc and the line in scripta to:
source scriptc
The version 1.1 of the package xxx consists now of the files
scripta and scriptc.
Now you rename scriptb in your CVS tree to scriptc.
A user who wants to checkout version 1.0 gets a problem because
scripta requires scriptb, but someone who dosen't know about
the rename, doesn't know where to get scriptb.
Even when the label is moved with the files, you get
scripta and scriptc on checkout, but the package won't work
because of the wrong filename.
You see, when you rename files in CVS, you get nonfunctional old
versions.
Mike Noyes schrieb:
On Thu, 2002-07-11 at 03:56, Manfred Schuler wrote:
Mike Noyes schrieb:
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=1atid=21
I don't think it is a good idea to make a change like this.
If someone wants to retrieve an older version, it does not work
because the file he needs is not available anymore.
It is better to create the new file in CVS and pin the
release/version tag to the new file and not to the old file.
Manfred,
That has not been my experience. When the SF staff moves/renames files
on the SF cvs server they maintain the cvs structure. Talk with Jacob
Moorman, Quality of Service Manager ('moorman' on SourceForge.net,
'moorman' on SlashNET IRC) to verify this if you like.
--
Mike Noyes [EMAIL PROTECTED]
http://sourceforge.net/users/mhnoyes/
http://leaf-project.org/
---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases more
http://thinkgeek.com/sf
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
--
Manfred Schuler
E_Mail: mailto:[EMAIL PROTECTED]
---
This sf.net email is sponsored by:ThinkGeek
PC Mods, Computing goodies, cases more
http://thinkgeek.com/sf
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote: Mike, I did _NOT_ at all want to criticize the staff at SF. I know about them only what I see on the list, so I'm not in a position to judge how they do their job. Manfred, I apologize for the tone of my last message. It was inappropriate. Sorry. I think I didn't express clearly what I mean. It is meant as a principle when working on large projects: _NEVER_ change anything that is correctly checked in I will give you an example of what I mean: In version 1.0 of package xxx you have 2 script files: scripta and scriptb One line in scripta is source scriptb Later you decide scriptb is not a good name and you change the name to scriptc and the line in scripta to: source scriptc The version 1.1 of the package xxx consists now of the files scripta and scriptc. Now you rename scriptb in your CVS tree to scriptc. A user who wants to checkout version 1.0 gets a problem because scripta requires scriptb, but someone who dosen't know about the rename, doesn't know where to get scriptb. Even when the label is moved with the files, you get scripta and scriptc on checkout, but the package won't work because of the wrong filename. You see, when you rename files in CVS, you get nonfunctional old versions. Ah, now I see. :-) I hadn't considered this sequence of actions. I believe interdependent files that require movement/renaming are candidates for branches. Would branching the sample above be an appropriate course of action? -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote: I think I didn't express clearly what I mean. It is meant as a principle when working on large projects: _NEVER_ change anything that is correctly checked in I will give you an example of what I mean: In version 1.0 of package xxx you have 2 script files: scripta and scriptb One line in scripta is source scriptb Later you decide scriptb is not a good name and you change the name to scriptc and the line in scripta to: source scriptc The version 1.1 of the package xxx consists now of the files scripta and scriptc. Now you rename scriptb in your CVS tree to scriptc. Manfred, I looked at this example again, and I think the sequence below is an accepatble solution for it. $ cp scriptb scriptc $ cvs add scriptc $ cvs ci -m added scriptc old filename was scriptb scriptc $ rm scriptb $ cvs remove scriptb $ cvs ci -m removed scriptb new filename is scriptc scriptb I believe this will leave the repository in a correct state, and solve the older version retrieval problem. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
On Thu, 2002-07-11 at 07:51, Mike Noyes wrote: Manfred, I looked at this example again, and I think the sequence below is an accepatble solution for it. Here is a small but significant addition to this sequence. It will allow retrieval of the tree in its 1.0 state. $ cvs -q tag R_1_0 $ cp scriptb scriptc $ cvs add scriptc $ cvs ci -m added scriptc old filename was scriptb scriptc $ rm scriptb $ cvs remove scriptb $ cvs ci -m removed scriptb new filename is scriptc scriptb I believe this will leave the repository in a correct state, and solve the older version retrieval problem. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote: It is meant as a principle when working on large projects: _NEVER_ change anything that is correctly checked in Manfred, Incorrectly checked in files/directories are candidates for SF staff cvs repository clean-up support requests (SR). I believe there are other instances where SF cvs SRs are appropriate too. Please take a look at our old SF SRs. In which cases should I have used standard cvs commands to accomplish these tasks? [ 574291 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=574291group_id=1atid=21 [ 547717 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=547717group_id=1atid=21 [ 547118 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=547118group_id=1atid=21 [ 525177 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=525177group_id=1atid=21 [ #513309 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=513309group_id=1atid=21 [ #503058 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=503058group_id=1atid=21 -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more 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 schrieb: On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote: Mike, I did _NOT_ at all want to criticize the staff at SF. I know about them only what I see on the list, so I'm not in a position to judge how they do their job. Manfred, I apologize for the tone of my last message. It was inappropriate. Sorry. No reason to apologize. I think I didn't express clearly what I mean. It is meant as a principle when working on large projects: _NEVER_ change anything that is correctly checked in I will give you an example of what I mean: In version 1.0 of package xxx you have 2 script files: scripta and scriptb One line in scripta is source scriptb Later you decide scriptb is not a good name and you change the name to scriptc and the line in scripta to: source scriptc The version 1.1 of the package xxx consists now of the files scripta and scriptc. Now you rename scriptb in your CVS tree to scriptc. A user who wants to checkout version 1.0 gets a problem because scripta requires scriptb, but someone who dosen't know about the rename, doesn't know where to get scriptb. Even when the label is moved with the files, you get scripta and scriptc on checkout, but the package won't work because of the wrong filename. You see, when you rename files in CVS, you get nonfunctional old versions. Ah, now I see. :-) I hadn't considered this sequence of actions. I believe interdependent files that require movement/renaming are candidates for branches. Would branching the sample above be an appropriate course of action? No need to branch. Just remove the HEAD and MAIN tags from the old file. -- Manfred Schuler E_Mail: mailto:[EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
Comments inline Mike Noyes schrieb: On Thu, 2002-07-11 at 07:06, Manfred Schuler wrote: It is meant as a principle when working on large projects: _NEVER_ change anything that is correctly checked in Manfred, Incorrectly checked in files/directories are candidates for SF staff cvs repository clean-up support requests (SR). I believe there are other instances where SF cvs SRs are appropriate too. Please take a look at our old SF SRs. In which cases should I have used standard cvs commands to accomplish these tasks? [ 574291 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=574291group_id=1atid=21 removing empty directories or renaming a top level directory should not impose any problem because there should not be any dependencies. [ 547717 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=547717group_id=1atid=21 Removing 'x' bit should do no harm [ 547118 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=547118group_id=1atid=21 Removing 'x' bit should do no harm [ 525177 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=525177group_id=1atid=21 top level directory, ok [ #513309 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=513309group_id=1atid=21 top level directory, ok [ #503058 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=503058group_id=1atid=21 Developers top level directory, should be ok -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel -- Manfred Schuler E_Mail: mailto:[EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
On Thu, 2002-07-11 at 13:17, Manfred Schuler wrote: Comments inline Manfred, Thanks for the analysis. I'm glad I don't appear to be causing problems in our repository. Mike Noyes schrieb: [ 547717 ] CVS repository clean-up: leaf https://sourceforge.net/tracker/index.php?func=detailaid=547717group_id=1atid=21 Removing 'x' bit should do no harm I added some enforce scripts to our CVSROOT recently. Would you take a look at them and let me know if you see any problems? Thanks. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/CVSROOT/ -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more 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 schrieb: On Thu, 2002-07-11 at 07:51, Mike Noyes wrote: Manfred, I looked at this example again, and I think the sequence below is an accepatble solution for it. Here is a small but significant addition to this sequence. It will allow retrieval of the tree in its 1.0 state. 1$ cvs -q tag R_1_0 2$ cp scriptb scriptc 3$ cvs add scriptc 4$ cvs ci -m added scriptc old filename was scriptb scriptc 5$ rm scriptb 6$ cvs remove scriptb 7$ cvs ci -m removed scriptb new filename is scriptc scriptb [snip] I recommend to tag every release with an appropriate label. So you can retrieve any old release or verify what is released. I also recommend to tag the latest release with somthing like 'latest' for easy retrieval. I don't think this sequence will work because in line 5 you remove scriptb and in line 7 you try to checkin scriptb. I have no experience with cvs and from the man pages I could not determine if line 6 removes only the last version or all versions of scriptb. If it removes all versions you get the problem with version 0.9. I would use this sequence cvs -q tag R_1_0 cvs -f ci -m file renamed to scriptc scriptb cvs -q tag -d MAIN scriptb mv scriptb scriptc cvs add scriptc cvs ci -m file renamed from scriptb scriptc This sequence is not tested. It is just what I can read from the man pages. Maybe you need additonally this line cvs remove scriptb but as mentioned, I don't know what exactly is removed. Maybe the tag MAIN cannot be deleted, although I couldn't find it in the man page. -- Manfred Schuler E_Mail: mailto:[EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ??? [LONG]
On Thu, 2002-07-11 at 14:21, Manfred Schuler wrote: Mike Noyes schrieb: On Thu, 2002-07-11 at 07:51, Mike Noyes wrote: Manfred, I looked at this example again, and I think the sequence below is an accepatble solution for it. Here is a small but significant addition to this sequence. It will allow retrieval of the tree in its 1.0 state. 1$ cvs -q tag R_1_0 2$ cp scriptb scriptc 3$ cvs add scriptc 4$ cvs ci -m added scriptc old filename was scriptb scriptc 5$ rm scriptb 6$ cvs remove scriptb 7$ cvs ci -m removed scriptb new filename is scriptc scriptb [snip] I recommend to tag every release with an appropriate label. So you can retrieve any old release or verify what is released. I also recommend to tag the latest release with somthing like 'latest' for easy retrieval. Manfred, Agreed. Tags are good. :-) I don't think this sequence will work because in line 5 you remove scriptb and in line 7 you try to checkin scriptb. I believe this sequence is correct, and a checkin is required to move the file to the Attic in the repository. ref. http://cvsbook.red-bean.com/cvsbook.html#Removing_Files http://cvsbook.red-bean.com/cvsbook.html#What_Happens_When_You_Remove_A_File I have no experience with cvs and from the man pages I could not determine if line 6 removes only the last version or all versions of scriptb. If it removes all versions you get the problem with version 0.9. I would use this sequence cvs -q tag R_1_0 cvs -f ci -m file renamed to scriptc scriptb From the cvs man page: commit [-lnR] [-m 'log_message' | -f file] [-r revision] [files...] Sometimes you may want to force a file to be committed even though it is unchanged; this is achieved with the -f flag, which also has the effect of disabling recursion (you can turn it back on with -R of course). How will this help? cvs -q tag -d MAIN scriptb mv scriptb scriptc cvs add scriptc cvs ci -m file renamed from scriptb scriptc This sequence is not tested. It is just what I can read from the man pages. Maybe you need additonally this line cvs remove scriptb but as mentioned, I don't know what exactly is removed. Maybe the tag MAIN cannot be deleted, although I couldn't find it in the man page. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more 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 schrieb: On Thu, 2002-07-11 at 14:21, Manfred Schuler wrote: Mike Noyes schrieb: On Thu, 2002-07-11 at 07:51, Mike Noyes wrote: Manfred, I looked at this example again, and I think the sequence below is an accepatble solution for it. Here is a small but significant addition to this sequence. It will allow retrieval of the tree in its 1.0 state. 1$ cvs -q tag R_1_0 2$ cp scriptb scriptc 3$ cvs add scriptc 4$ cvs ci -m added scriptc old filename was scriptb scriptc 5$ rm scriptb 6$ cvs remove scriptb 7$ cvs ci -m removed scriptb new filename is scriptc scriptb [snip] I recommend to tag every release with an appropriate label. So you can retrieve any old release or verify what is released. I also recommend to tag the latest release with somthing like 'latest' for easy retrieval. Manfred, Agreed. Tags are good. :-) I don't think this sequence will work because in line 5 you remove scriptb and in line 7 you try to checkin scriptb. I believe this sequence is correct, and a checkin is required to move the file to the Attic in the repository. ref. http://cvsbook.red-bean.com/cvsbook.html#Removing_Files http://cvsbook.red-bean.com/cvsbook.html#What_Happens_When_You_Remove_A_File You are right. I was irritated by 'ci' (check in). 'commit' would make things easier to understand. Checking in a nonexisting file looks strange. I have no experience with cvs and from the man pages I could not determine if line 6 removes only the last version or all versions of scriptb. If it removes all versions you get the problem with version 0.9. I would use this sequence cvs -q tag R_1_0 cvs -f ci -m file renamed to scriptc scriptb From the cvs man page: commit [-lnR] [-m 'log_message' | -f file] [-r revision] [files...] Sometimes you may want to force a file to be committed even though it is unchanged; this is achieved with the -f flag, which also has the effect of disabling recursion (you can turn it back on with -R of course). How will this help? The intention was to get a final log message. You get it when you commit the remove. cvs -q tag -d MAIN scriptb mv scriptb scriptc cvs add scriptc cvs ci -m file renamed from scriptb scriptc This sequence is not tested. It is just what I can read from the man pages. Maybe you need additonally this line cvs remove scriptb but as mentioned, I don't know what exactly is removed. Maybe the tag MAIN cannot be deleted, although I couldn't find it in the man page. I had a quick look at the enforce scripts. You should not force all filenames (except Makefile) to lowercase. Some kernel modules have uppercase letters in their names. Also the README files are typically in uppercase. An X terminal dist would have big problems with that rule. Attic should not be allowed as name. -- Manfred Schuler E_Mail: mailto:[EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases more http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ???
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. http://leaf.sourceforge.net/devel/helices/net-snmp/ 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 http://leaf.sourceforge.net/devel/jnilo/ 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 ???
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 ??? [LONG]
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. http://leaf.sourceforge.net/devel/helices/net-snmp/ 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 http://leaf.sourceforge.net/devel/jnilo/ 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? -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our
Re: [Leaf-devel] CVS structure ??? [LONG]
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]
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]
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=HEADcontent-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.1content-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=1atid=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 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=HEADcontent-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.1content-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]
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=HEADcontent-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.1content-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. a href=insert-urlnet-snmp.lrp v4.2.4/a 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=detailtaskproject_task_id=45595group_id=13751group_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=detailtaskproject_task_id=45594group_id=13751group_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
Re: [Leaf-devel] CVS structure ??? [LONG]
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] CVS Structure Update
Mike Noyes wrote: Everyone, The last thing I did before disappearing for the last couple of months, was to restructure our CVS repository. All developers now have a personal tree in devel/yourname. There is a bin directory for released files. The oxygen and dachstein trees are controlled by David and Charles respectively. Please notify them before committing/adding anything to those trees. I will create a bin/packages directory for us too. The doc tree is self explanatory. The src tree structure is pending (consensus required). Is there ever going to be any consensus? The issue seems to have been forgotten lately. I might set up my personal cvs tree, but I'd rather not do so. If you need help with CVS commands please let me know. I'll update the Individual Developer Content FAQ in the next couple of weeks. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/ Any comments or suggestions are welcome. I'll see what I can come up with. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS Structure Update
At 2002-01-07 11:07 +0100, Ewald Wasscher wrote: Mike Noyes wrote: The last thing I did before disappearing for the last couple of months, was to restructure our CVS repository. All developers now have a personal tree in devel/yourname. There is a bin directory for released files. The oxygen and dachstein trees are controlled by David and Charles respectively. Please notify them before committing/adding anything to those trees. I will create a bin/packages directory for us too. The doc tree is self explanatory. The src tree structure is pending (consensus required). Is there ever going to be any consensus? The issue seems to have been forgotten lately. I might set up my personal cvs tree, but I'd rather not do so. Ewald, Thanks for the comments. The personal devel/yourname cvs trees are necessary. We must migrate most of the images, kernel tarballs, and packages from the shell server into cvs. SF project allocation of resources is the main reason for this change. Our space on the shell server is limited to approximately 1G, while cvs space is unlimited. We are already using over 1G. I'm working on a way to do daily exports (using cron) of certain directories from our cvs repository to our pub directory on the shell server. This will allow us to automate the process of keeping those directories current. Here are the trees I have in mind: dachstein, oxygen, doc, images, packages. All of these except doc are from the bin tree in cvs. see http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/ Note: I need to create the images and packages trees in bin. Do I need to create a kernel tree also? I plan on using David's scripts for the packages tree. see http://leaf.sourceforge.net/pub/oxygen/repository/ Everyone can keep track of changes made to our cvs repository by subscribing to our leaf-cvs-commits list. http://leaf.sourceforge.net/content.php?menu=14page_id=20 -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3 (about to be) available.)
Charles Steinkuehler, 2001-04-20 08:45 -0500 It'd be interesting to see how much each option affected size, but overall a 411K 2.4 kernel is VERY COOL, and should be quite usable for floppy firewalls. While I'd like to see a 'one size fits all' kernel, perhaps there could be a floppy only, minimal kernel, and a larger kernel with all the 'goodies' like RAID, loopback, etc (compiled as modules, where possible) for folks running from CD, HDD, Flash, or what have you. Charles, This sounds good. Getting back to your CVS comments from yesterday. I agree, we need to start committing files to CVS. There are approximately six people working independently on the EigerStein update. Putting these individual pieces into CVS will allow all of us to build off of each others efforts. First, Charles this looks like a significant update. Are we still going to call it EigerStein, or have you decided on a new name? Second, are we creating a release that branches from 2.9.8, or ESb2? Third, does anyone have suggestions for the tree structure? Should we use Dave C.'s or Matthew Grant's devel snapshot as a template? I did the following search on Google looking for ideas. http://www.google.com/search?q=cvs+repository+structure Fourth, we need to decide if packages should have their own tree. Are we going to try to make them work on as many releases as possible? If so, I think a separate tree for packages is in order. I also, like David's diff idea for them. https://sourceforge.net/tracker/index.php? \ func=detailaid=412704group_id=13751atid=313751 David, How close are you to committing the Oxygen devel tree to CVS? Jack, How close is Ladybug to release? Is it ready for CVS? Scott, I think Echowall should be added to CVS. Do you agree? -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about to be) available.)
David Douthitt, 2001-04-20 10:22 -0500 How close are you to committing the Oxygen devel tree to CVS? The CDROM contains a direct image of the Oxygen development source tree, along with the packages. Everything in src/base is either a binary in the system or a package on the boot disk. Everything else in src/ other than src/base are package sources; pkgs/ contains the results of compilations. Doing this should set up a good CVS tree for Oxygen: # cd $CVSROOTDIR # mkdir -p ./mnt # mkdir -p ./Oxygen # mount -o loop Oxygen-2.1.3-CDROM.iso ./mnt # cp -a ./mnt/src/base ./Oxygen Is this possible on SourceForge? Also, to get packages, do: David, No for two reasons. One we don't have shell level access to our CVS repository yet. Second, mount is restricted to root on shell1 (I just checked). However, you can commit this tree to our CVS repository from your machine. I don't know how long it will take. # cd $CVSROOTDIR # mkdir -p ./mnt # mkdir -p ./packages # mount -o loop Oxygen-2.1.3-CDROM.iso ./mnt # cp -a ./mnt/src/* ./packages # rm -rf ./packages/base That should do it. Unfortunately, not. You need to use CVS for the import process. Otherwise, it wont be able to setup its internal housekeeping files. -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about to be) available.)
Charles Steinkuehler wrote:
These are the things I've thought about, and my opinions on them:
* Include versions in the package name - not enough name space.
Why not require VFAT support? I don't think it adds too much size to a
compressed kernel.
Not a bad idea; however, there are a few things that come to mind:
* How do you create a VFAT diskette under Windows? Some may laugh; I
for one am not sure how
* What about DOS diskettes? 1.44M preformatted diskettes?
* What of mkfs.msdos? Does it understand VFAT?
We could also switch to minix formatted floppies, but
the Windows folks would have a fit (and you thought 1680K floppies were hard
to work with on 'Doze :)
Heh.
Why not change the package format? It's possible to work with deb and rpm
pacakges in shell-script using nothing more than dd, gzip, cat, and tar.
So I've heard; however, RPM files have not worked that way in my
experience - they require rpm2cpio to get anything decent out. Also,
last time I started untarring (more recent) DEB files there was always
an error or warning about a particular file - it may have been called
'-' or something.
Using dd to cut the file up, you can have an initial text (or script)
portion, followed by one or more tgz archives (this is pretty much how a deb
package is made).
I'm not sure what you mean, but I have a strong aversion to any format
which can't be undone by the following GNU tar command:
tar xzvf package
I've had it up to here with all the different package formats - and
none of them satisfy the above requirement. I've HP-UX boxes here
(Software Depots), Unixware ("Packages"), Red Hat Linux (RPM), and
until recently Debian (DEB). Makes me want to do what I've heard
somewhere that a few others are doing: skip the packages altogether
and only use source *.tar.gz files from the original creator
I'd like to see pre/post install/remove script support,
var/lib/lrpkg/pkg.sh
...used this way:
pkg.sh postremove
pkg.sh preremove
pkg.sh postinstall
pkg.sh preinstall
and I think we could
have minimal dependancy checking (for library existance/version, kernel rev,
etc) without too much bloat to the packaging scripts...
How to check for library version? You could use:
LIBC=$(ls -1 /lib/libc-*)
LIBC=${LIBC%%.so}
LIBC=${LIBC##*/libc-}
...but then you are relying on the name to be correct. Is it?
For the kernel, you'd probably be best with
KERNEL=$(uname -r)
KERNEL=${KERNEL%%-*}
...this assumes that uname -r works; does it?
___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure
David Douthitt, 2001-04-20 11:24 -0500
I've had it up to here with all the different package formats - and
none of them satisfy the above requirement. I've HP-UX boxes here
(Software Depots), Unixware ("Packages"), Red Hat Linux (RPM), and
until recently Debian (DEB). Makes me want to do what I've heard
somewhere that a few others are doing: skip the packages altogether
and only use source *.tar.gz files from the original creator
David,
Midori is using *.tar.gz for their packages.
This reminds me. At the embedded conference, I asked the embedded Linux
distribution vendors about their support for floppies and generic images.
The only two that support both are HardHat Linux and Midori. So, the only
currently available bases for us are LRP(heavily
modified)/Oxygen/EigerStein(updated), HardHat, and Midori. HardHat uses rpm
with a stripping script, and Midori uses *.tar.gz.
There were a couple of other interesting things I learned. Lineo, is
producing a router (hardware+software) based on Linux 2.0.x. It isn't
certified, but the price point for the low end version is ~$100. None of
the hardware vendors had SBCs with three ethernet ports. Although, many of
them indicated this was something they planed on delivering soon. Joining
the ELC may be a good idea. They had a presentation booth that was
available for members to show their products/projects. It was empty most of
the time, so availability isn't a problem. I appears to me that the first
thing every embedded distribution produces is a router. I had some
conversations on the advantages of real-time for QoS also. Opinions were split.
Ray and I did get together and talk. :)
He probably has greater insight into the significant things that happened.
--
Mike Noyes [EMAIL PROTECTED]
http://leaf.sourceforge.net/
___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about tobe) available.)
On Fri, 20 Apr 2001, David Douthitt wrote:
Not a bad idea; however, there are a few things that come to mind:
* How do you create a VFAT diskette under Windows? Some may laugh; I
for one am not sure how
Beats me. I think it's a simple matter of formatting under Windows. I'll
give it a shot tonight.
* What about DOS diskettes? 1.44M preformatted diskettes?
Require a reformat assuming that they aren't already VFAT formatted. Even
for the average Windows user formatting a disk isn't difficult.
* What of mkfs.msdos? Does it understand VFAT?
Yep. 'mkdosfs -F 32 /dev/fd0[u]' does the trick.
Why not change the package format? It's possible to work with deb and rpm
pacakges in shell-script using nothing more than dd, gzip, cat, and tar.
So I've heard; however, RPM files have not worked that way in my
experience - they require rpm2cpio to get anything decent out. Also,
last time I started untarring (more recent) DEB files there was always
an error or warning about a particular file - it may have been called
'-' or something.
I'm also against moving away from text-and-script-controlled tarballs.
About the only thing that might compel me to want to do so is the ability
to add apt-get for LRP, with a package repository on Sourceforge to allow
people to auto-update - and even then, I might need some arm-twisting.
"Keep It Simple, 'cause they're Stupid" my History teacher always used to
say.
and I think we could
have minimal dependancy checking (for library existance/version, kernel rev,
etc) without too much bloat to the packaging scripts...
How to check for library version? You could use:
LIBC=$(ls -1 /lib/libc-*)
LIBC=${LIBC%%.so}
LIBC=${LIBC##*/libc-}
...but then you are relying on the name to be correct. Is it?
I don't know about you, but I didn't do anything to the names when I put
together my 2.1.3 modules. On LRP 2.9.8, I get the following:
Veil# ls -1 /lib/libc-*
/lib/libc-2.0.7.so
At that point it's simply a matter of a naming convention. Anyone who's
making images that mess with the libs should be aware that libc NEEDS to
be named that for packages to work correctly.
For the kernel, you'd probably be best with
KERNEL=$(uname -r)
KERNEL=${KERNEL%%-*}
...this assumes that uname -r works; does it?
It does:
Veil# uname -r
2.2.18
Veil#
--
George Metz
Commercial Routing Engineer
[EMAIL PROTECTED]
"We know what deterrence was with 'mutually assured destruction' during
the Cold War. But what is deterrence in information warfare?" -- Brigadier
General Douglas Richardson, USAF, Commander - Space Warfare Center
___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about tobe) available.)
On Fri, 20 Apr 2001, George Metz wrote:
On Fri, 20 Apr 2001, David Douthitt wrote:
Not a bad idea; however, there are a few things that come to mind:
* How do you create a VFAT diskette under Windows? Some may laugh; I
for one am not sure how
Beats me. I think it's a simple matter of formatting under Windows. I'll
give it a shot tonight.
vfat is backward-compatible. Microsoft used reserved features in the FAT
format to implement its features, and included consistency checks with
fallback to 8.3 behavior in case an older MSDOS system modifies the FAT
entries.
Every floppy you use in Windows is treated as vfat.
* What about DOS diskettes? 1.44M preformatted diskettes?
Require a reformat assuming that they aren't already VFAT formatted. Even
for the average Windows user formatting a disk isn't difficult.
What about them? They are vfat.
* What of mkfs.msdos? Does it understand VFAT?
Yep. 'mkdosfs -F 32 /dev/fd0[u]' does the trick.
vfat != fat32
The vfat module happens to support both the long filenames and large disk
support.
Why not change the package format? It's possible to work with deb and rpm
pacakges in shell-script using nothing more than dd, gzip, cat, and tar.
So I've heard; however, RPM files have not worked that way in my
experience - they require rpm2cpio to get anything decent out. Also,
last time I started untarring (more recent) DEB files there was always
an error or warning about a particular file - it may have been called
'-' or something.
I'm also against moving away from text-and-script-controlled tarballs.
About the only thing that might compel me to want to do so is the ability
to add apt-get for LRP, with a package repository on Sourceforge to allow
people to auto-update - and even then, I might need some arm-twisting.
"Keep It Simple, 'cause they're Stupid" my History teacher always used to
say.
and I think we could
have minimal dependancy checking (for library existance/version, kernel rev,
etc) without too much bloat to the packaging scripts...
How to check for library version? You could use:
LIBC=$(ls -1 /lib/libc-*)
LIBC=${LIBC%%.so}
LIBC=${LIBC##*/libc-}
...but then you are relying on the name to be correct. Is it?
The loader has to know the name. "ldd" gets the loader to divulge the
name(s) expected by a binary on a full distro. Might be better to steal
this technique in the package loader than add a new file to the lrp
format, though that doesn't help those with the old lrpkg figure out
their problems.
[...]
---
Jeff NewmillerThe . . Go Live...
DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go...
Work:[EMAIL PROTECTED] Live: OO#.. Dead: OO#.. Playing
Research Engineer (Solar/BatteriesO.O#. #.O#. with
/Software/Embedded Controllers) .OO#. .OO#. rocks...2k
---
___
Leaf-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about tobe) available.)
VERY informative, Jeff! Very much appreciate this new information [EMAIL PROTECTED] wrote: vfat is backward-compatible. Microsoft used reserved features in the FAT format to implement its features, and included consistency checks with fallback to 8.3 behavior in case an older MSDOS system modifies the FAT entries. Every floppy you use in Windows is treated as vfat. Interesting! * What about DOS diskettes? 1.44M preformatted diskettes? Require a reformat assuming that they aren't already VFAT formatted. Even for the average Windows user formatting a disk isn't difficult. What about them? They are vfat. Well! The vfat module happens to support both the long filenames and large disk support. And just how much space does VFAT take up? The loader has to know the name. "ldd" gets the loader to divulge the name(s) expected by a binary on a full distro. Might be better to steal this technique in the package loader than add a new file to the lrp format, though that doesn't help those with the old lrpkg figure out their problems. My biggest concern is that someone on one of the other distributions (e.g., LRP 2.9.8) will load a package, see a SegFault, and then go ask why it SegFaults - with the accompanying head-scratching by the wizards as to why a prepackaged *.lrp would SegFault. The version idea is the simplest. just query the version and see if it is xxx(2.1). I like the long name idea, using VFAT. The only thing is, VFAT adds FAT to the kernel (pun intended :-) Just how big is this thing? Long names also mean this: someone on an old distribution copies this *.lrp over, and of course has to shoehorn it into 8.3 - either deliberately, or via Windows 8.3 mangling for DOS FAT. Then loading the package will fail, because the name doesn't match the pkg.list name And using VFAT would allow longer names under UNIX as well. ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3 (aboutto be) available.)
Man, I am so swamped. Ladybug needs to be whacked against the new Oxygen release -- this shouldn't be too big of a deal, since the new Oxygen has a fair number of the architectural changes I was working on built into it (only better). So the work at this point is a matter of kernel customization, removal of the routing-specific stuff, editing of menus, packaging the applications to be run, and testing. Let's say it's far from release. I would love to put it in CVS, and will follow whatever scheme is used by everyone else. -- Jack Coates Monkeynoodle: It's what's for dinner! On Fri, 20 Apr 2001, Mike Noyes wrote: snip Jack, How close is Ladybug to release? Is it ready for CVS? Scott, I think Echowall should be added to CVS. Do you agree? -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about tobe) available.)
David Douthitt, 2001-04-20 16:25 -0500 I like the long name idea, using VFAT. The only thing is, VFAT adds FAT to the kernel (pun intended :-) Just how big is this thing? Would someone explain to me why we shouldn't use cramfs? I believe it works with floppies too. http://www.linuxdevices.com/articles/AT5214244852.html ~ Together, Quinlan reckons that cramfs, ramfs and packramfs comprise an ~ "elegant" solution for embedded developers wishing to optimize boot ~ time, resource usage and robustness. -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(abouttobe) available.)
On Fri, 20 Apr 2001, Mike Noyes wrote: David Douthitt, 2001-04-20 16:25 -0500 I like the long name idea, using VFAT. The only thing is, VFAT adds FAT to the kernel (pun intended :-) Just how big is this thing? Would someone explain to me why we shouldn't use cramfs? I believe it works with floppies too. This is designed to remain mounted indefinitely, which is appropriate for flashram, but I feel this is inappropriate for the floppy. http://www.linuxdevices.com/articles/AT5214244852.html ~ Together, Quinlan reckons that cramfs, ramfs and packramfs comprise an ~ "elegant" solution for embedded developers wishing to optimize boot ~ time, resource usage and robustness. --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Work:[EMAIL PROTECTED] Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(abouttobe) available.)
On Fri, 20 Apr 2001, Mike Noyes wrote: [EMAIL PROTECTED], 2001-04-20 16:30 -0700 On Fri, 20 Apr 2001, Mike Noyes wrote: David Douthitt, 2001-04-20 16:25 -0500 I like the long name idea, using VFAT. The only thing is, VFAT adds FAT to the kernel (pun intended :-) Just how big is this thing? Would someone explain to me why we shouldn't use cramfs? I believe it works with floppies too. This is designed to remain mounted indefinitely, which is appropriate for flashram, but I feel this is inappropriate for the floppy. Jeff, That doesn't sound good, but how is it different from the backup scripts we use now? The disk need not be accessed for months at a time in an LRP box. I thought this might be a good way to write protect hard drives and flash disks. Perhaps... or it may actually be _too_ restrictive, since you simply don't have the option to write anything to it... almost like a cd, without the media portability. This seems appropriate for a truly single-purpose hardware device, since you don't need such a big ramdisk, and you don't want to customize it. When dealing with the variety of hardware that LRP can handle, though, it seems like too much work. --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Work:[EMAIL PROTECTED] Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(about tobe) available.)
[EMAIL PROTECTED], 2001-04-20 17:26 -0700 On Fri, 20 Apr 2001, Mike Noyes wrote: That doesn't sound good, but how is it different from the backup scripts we use now? The disk need not be accessed for months at a time in an LRP box. Jeff, Understood. Thanks for taking the time to explain this to me. I thought this might be a good way to write protect hard drives and flash disks. Perhaps... or it may actually be _too_ restrictive, since you simply don't have the option to write anything to it... almost like a cd, without the media portability. Ok. I must be getting confused. I thought packramfs would write temporary data to a cramfs partition. This seems appropriate for a truly single-purpose hardware device, since you don't need such a big ramdisk, and you don't want to customize it. When dealing with the variety of hardware that LRP can handle, though, it seems like too much work. That would explain the strange look I got from the MontaVista rep. when I suggested cramfs on a floppy. This still doesn't explain why Debian is trying to do the following for their boot floppies. http://lists.debian.org/debian-boot-0102/msg00435.html ~ Build in crams and ramfs. We're going to boot off of a cramfs initrd ~ and then set up and pivot_root into a ramfs filesystem. -- Mike Noyes [EMAIL PROTECTED] http://leaf.sourceforge.net/ ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure (was: Patched kernel 2.4.3(abouttobe) available.)
On Fri, 20 Apr 2001, Mike Noyes wrote: [EMAIL PROTECTED], 2001-04-20 17:26 -0700 On Fri, 20 Apr 2001, Mike Noyes wrote: I thought this might be a good way to write protect hard drives and flash disks. Perhaps... or it may actually be _too_ restrictive, since you simply don't have the option to write anything to it... almost like a cd, without the media portability. Ok. I must be getting confused. I thought packramfs would write temporary data to a cramfs partition. I overlooked that capability. This seems appropriate for a truly single-purpose hardware device, since you don't need such a big ramdisk, and you don't want to customize it. When dealing with the variety of hardware that LRP can handle, though, it seems like too much work. That would explain the strange look I got from the MontaVista rep. when I suggested cramfs on a floppy. This still doesn't explain why Debian is trying to do the following for their boot floppies. http://lists.debian.org/debian-boot-0102/msg00435.html ~ Build in crams and ramfs. We're going to boot off of a cramfs initrd ~ and then set up and pivot_root into a ramfs filesystem. I;m not really familiar with the details, but I think the cramfs initrd is both disk- and ram-efficient, and pivoting the root means switching the root over to a writeable filesystem while maintaining access to the old filesystem. For a boot floppy there is no customization, but it is convenient to have a writeable root. --- Jeff NewmillerThe . . Go Live... DCN:[EMAIL PROTECTED]Basics: ##.#. ##.#. Live Go... Work:[EMAIL PROTECTED] Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --- ___ Leaf-devel mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/leaf-devel
