Re: [leaf-devel] ANN: Pending upgrade to Allura
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/14/2012 1:44 AM, Mike Noyes wrote: Everyone, Upgrade complete. Excellent! Thanks Mike!!! - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDLIToACgkQLywbqEHdNFzG+wCfYJLb8LK/yHm7ynR0jIN4xU0T HKEAnRMgTd9yawdMk6jeJheTt0cnyZrc =Cb0T -END PGP SIGNATURE- -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] LEAF Project Logo - Time for an update?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/15/2012 2:20 PM, davidMbrooke wrote: I have uploaded a .png version of the full logo to our Wiki and (temporarily) added it to the Main Page: http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Main_Page I'm also thinking of removing the text and using just the graphic portion in some places (e.g. the Wiki sidebar). What do you think? I won't be offended (much) if you don't like it :-) +1 :) - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+yw38ACgkQLywbqEHdNFxnMQCfWwf6vAwcnuag4pNhzgtQMpk9 y5MAn1PZcM2KfUN6iAlzaikEP3/7XlyK =QdQZ -END PGP SIGNATURE- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Fwd: Re: Screen captures
I got some screen captures forwarded to me by Rich Bowen of SourceForge. I'm not sure if anyone wants to do anything with these, or if you'd like me to post them to the site somewhere. -- Charles Steinkuehler char...@steinkuehler.net ---BeginMessage--- Here they are. Thanks! --Rich rbo...@geek.net On Nov 14, 2011, at 11:10 AM, Charles Steinkuehler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just send the png files along, thanks. On 11/14/2011 10:00 AM, Rich Bowen wrote: Hi. Rich Bowen here, Community Growth guy at SourceForge. There\'s a journalist who\'s doing a piece on SF projects, and yours - LEAF - was one of the ones selected. She wanted some screen captures from your application, and I made a few for her. I was wondering if it would be ok for me to add them to your SF profile page, just to give visitors an idea of what sort of app it is that they\'re looking at. I\'d be glad to do this myself, if you like, or I can send the png files to you. Thanks. --Rich rbo...@geek.net -- This message has been sent to you, a registered SourceForge.net user, by another site user, through the SourceForge.net site. This message has been delivered to your SourceForge.net mail alias. You may reply to this message using the Reply feature of your email client, or using the messaging facility of SourceForge.net at: https://sourceforge.net/sendmessage.php?touser=40648 - -- Charles Steinkuehler cst...@newtek.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7BPYcACgkQenk4xp+mH405rwCcC9s1XKtwDRFvZpUp0Hq6t7c0 d6wAniK+L/dzfCXG8Qe22pBoUEkv+/AK =sRLx -END PGP SIGNATURE- -- Rich Bowen :: rbo...@geek.net :: @rbowen Community Growth Hacker SourceForge.net :: @sourceforge This e- mail message is intended only for the named recipient(s) above. It may contain confidential and privileged information. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and delete the message and any attachment(s) from your system. Thank you. ---End Message--- signature.asc Description: OpenPGP digital signature -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Fwd: Re: Screen captures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/14/2011 1:38 PM, KP Kirchdoerfer wrote: Am Montag, 14. November 2011, 18:44:13 schrieb Charles Steinkuehler: I got some screen captures forwarded to me by Rich Bowen of SourceForge. I'm not sure if anyone wants to do anything with these, or if you'd like me to post them to the site somewhere. If they show anything meaningful, Mike may add (one of) them to our profile page. And probably they are useful for the wiki documentation and David can take care about...? Oops...I forgot the list strips attachments. I've put the three files on-line for reference: http://neo.steinkuehler.net/leaf/ - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7BfQwACgkQLywbqEHdNFwMfgCfa0Iz3fTZBz9SL7EODzi/9rlu hVYAoO9AyhZVHrrg5DxZm8cJudG5rXmM =hXSa -END PGP SIGNATURE- -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Buildtool with cvs down etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/1/2011 6:26 AM, KP Kirchdoerfer wrote: Theoratically it should be possible to work with the tarball without access to cvs - but I doubt anyone has done this before. If it helps, I have installed viewvc and made a backup of the SF CVS archive available on-line: http://leaf.steinkuehler.net/cgi-bin/viewvc.cgi/ I will try to get time later on to see if I can run a build against this CVS repository. NOTE: If necessary to assist in getting a stable release, I can make local accounts available on this system, enabling cvs write access via ssh. I'm not sure this is a great idea (I'd prefer SF to get CVS back on-line), but I do have decent bandwidth here (25 MBit down, 5 MBit up) if it becomes necessary to carry on with CVS for a short time prior to switching to svn/git (and no-one else has a more appropriate system available). - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1IOa8ACgkQLywbqEHdNFxt5wCg4c7R1KJSeLoHexr2HsZFP8/6 S88AnRbsLWX7YtYIhWyseaVTxxEyKT6r =OXFO -END PGP SIGNATURE- -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] next steps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/31/2011 12:54 PM, Mike Noyes wrote: On Mon, 2011-01-31 at 17:37 +0100, KP Kirchdoerfer wrote: -snip- And it might be a good base, to make a step back and rework our infrastructure. This could be work on buildenv to support more platforms, or more possibly, we may be forced to move away from cvs I don't like to make, or be forced to make, such changes before we finally have a stable successor to Bering-uClibc 3.x. KP, Maybe Charles or someone else with SVN experience is willing to step in and see what issues there are with our current CVS build environment on SVN. I suspect SF will be forced to discontinue CVS service for security reasons. This is one reason I've been pushing for us to migrate to git. I play with subversion daily, administer a production subversion server as part of my day job, and have migrated several projects from a legacy cvs environment to subversion. If there's anything I can do to assist with a transition from cvs to svn, please let me know. - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1HFHsACgkQLywbqEHdNFwV+wCgwx2rUL0eTwC9pawzYvZ2pX4S VCEAoPQKEx3K+3TCXbFLaGkEztBcd2/R =k2Gw -END PGP SIGNATURE- -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] next steps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/31/2011 3:06 PM, Mike Noyes wrote: SVN Admin https://sourceforge.net/project/admin/svn.php?group_id=13751 KP, Martin, Andrew, and the rest of the Bering team can provide you with migration issues. Thanks! What's the current status of subversion? Has any CVS content been migrated into SVN? If not, does SF have a process for this, or would I need to do it manually? If I need to migrate data from CVS, is there anything that would need to happen first (ie: any required cleanup or changes on the CVS side)? I tried browsing the subversion repository, and it didn't seem to work...I'm not sure if that's due to there being nothing there or a result of the recent security issues with SF. I should have a recent CVS tarball or archive, from prior to SF shutting things down. I can bring that online or use it to convert into subversion if necessary. - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1HJxgACgkQLywbqEHdNFxStgCg4qDHZSllRxyREWggza9TAzV6 T58AoLY1jesCIQvlNFSz2a9WcC9R2hMV =ub7u -END PGP SIGNATURE- -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS Backups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/31/2011 3:18 PM, Charles Steinkuehler wrote: I tried browsing the subversion repository, and it didn't seem to work...I'm not sure if that's due to there being nothing there or a result of the recent security issues with SF. I should have a recent CVS tarball or archive, from prior to SF shutting things down. I can bring that online or use it to convert into subversion if necessary. I just verified, and it looks like my nightly rsync of the SF CVS archives started failing on 1/27/11. My local copy should be good up to apx. 3:15 AM CST 1/26/2011. Let me know if anyone needs access to this. - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1HKKsACgkQLywbqEHdNFyORACffHYa0zlPc8szQuG3Xaz+zENf ZgkAn1rZL+uKeBpKZfzKva7Oci7xz7VE =miF9 -END PGP SIGNATURE- -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Signed e-mail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2010 4:24 PM, Mike Noyes wrote: BTW. does someone know why my messages never make it to leaf-devel if they are signed? Erich, It is due to our spam filters in mailman. I can look at the situation to see if something can be done. I apologize for any inconvenience this issue has caused you. Note that my e-mail is typically signed, and I have not noticed any issue with sending mails to the list. ?!? - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzlrt8ACgkQLywbqEHdNFxVQwCdHGoF7Avzirj9UFyngXJzmVer SMQAn0kX09i/6exhHcAuh0ByPqItsO+C =zHJS -END PGP SIGNATURE- -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Mailing Lists
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/6/2010 11:38 AM, Mike Noyes wrote: Everyone, Are there any objections to deleting the following mailing lists: leaf-announce, leaf-auto, leaf-hardware, leaf-wisp-dist This will leave: leaf-cvs-commits (rename to leaf-commits, or delete in favor of laconica w/git), leaf-devel, leaf-user No objections here. Just -devel, -user, and -commits seems like plenty with the limited traffic these days. - -- Charles Steinkuehler char...@steinkuehler.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLu2taLywbqEHdNFwRAhvTAKCj8y8GsXytG6TrY9NiFjJETbV/gACfb1j3 7D8ESGCjQPgQrdqKaEfK94Q= =NA5R -END PGP SIGNATURE- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Project description
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 | Everyone, | We seem to have agreement on a name switch from Firewall to Framework. I | think we can make this change now, and continue work on a description | for later adoption. Is this acceptable? | | Mike Noyes +1 Charles Steinkuehler +1 - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1VKmLywbqEHdNFwRAsBaAJ9VKykfr3K5JAwOQdC72ow7hlzcKwCgqARL SuVdVQF1EANNnbon0oIAeWQ= =vqMP -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering uClibc with Kernel 2.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erich Titl wrote: | Actually playing with e1000 for 2.4 reset me a little lately. Definitely | I am convinced that if LEAF wants to go on strongly we need to be on par | with other project which do similar work, e.g. 2.6 is a must. | | And for all your effort which point into the future here it is _WELL DONE_ I agree! Besides driver issues, another reason to migrate to a 2.6 kernel is support for IPV6, which will become vastly more important in the years to come, particularly outside the US, where the IPV4 address pool is already beginning to be exhausted. | One of my concerns in the 2.6 branch will be IPSEC, as now we need to | use the native stack. It appears that with using the native stack IPSEC | will be an application like any other, so we may have now the benefit of | using Strongswan's IKEv2 implementation :-) I can likely assist with the IPSec stuff. I have migrated a few sites from leaf-based firewalls to minimal debian installs, using the new IPSec tools (racoon and racoon-tool, in my case). I have a few more sites that still run leaf and will need to be upgraded soon. A 2.6 kernel based release with modern IPSec would allow me to avoid migrating to debian (and rotating HDDs). I don't yet have any real-world experience with IPV6, other than the dropped IPV6 packets seen by anyone running a firewall...the nasties have taken to using IPV6 tunneling to try and circumvent firewall rules, as many routers block IPV4 traffic but have separate (and frequently non-existent or less maintained) rule sets for IPV6. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH1VUXLywbqEHdNFwRAi/sAJ0d/ZHMKLXR+ryRRT9v4GhXUw5rDQCg/TsQ 0SuTICfWv3CevIn3uCF8qQQ= =jG9Q -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Busybox has buggy regex handling
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mats Erik Andersson wrote:
| Hi folks,
|
| this is preliminary information that Busybox does
| not possess a full command of regular expression
| to the extent desirable for the 3.1 of Bering.
| I know for certain that this disturbs the validation
| I have implemented for Webconf, but those of you who
| rely on regular expressions in other subsystems of
| Bering ought to read the following exposition.
|
| The problem is that the regex handling in Busybox
| cannot correctly resolve repetitions using \{n\}.
| The following is a reduction of the actual case
| that disturbs my validation of ip-addresses inside
| /var/webconf/lib/validator.sh.
|
| firewall# ### Matches exactly {0,...,25}
| firewall# tjugufem=\(1\?[0-9]\|2[0-5]\)
| firewall# ### Should match n-m-k, where n,m,k in {0,...,25}
| firewall# Trenne=$tjugufem\(-$tjugufem\)\{2\}
| firewall#
| firewall# echo 25-19-25 | grep ^$Trenne$
| 25-19-25
| firewall# echo 25-20-25 | grep ^$Trenne$
| firewall#
Can you provide the exact sed code you're working with? I don't have
the validator.sh code handy to examine directly.
It looks like the regular expression you're passing to grep is:
~ $ echo ^$Trenne$
~ ^\(1\?[0-9]\|2[0-5]\)\(-\(1\?[0-9]\|2[0-5]\)\)\{2\}$
For portability I would suggest directly crafting an extended regular
expression (rather than escaping all the extended metacharacters in a
standard regex). To gnu sed, the above and below are identical, but
they might not be to busybox. Try the following, as an extended
expression (ie: egrep or sed -r), and see if it's still buggy:
~ egrep '^(1?[0-9]|2[0-5])(-(1?[0-9]|2[0-5])){2}$'
...and try changing the location of the iterator to the first regex:
~ egrep '^((1?[0-9]|2[0-5])-){2}(1?[0-9]|2[0-5])$'
Minor glitches like this are why the old (2.2 based kernel) releases
used the 'real' sed. :)
- --
Charles Steinkuehler
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHx5RWLywbqEHdNFwRAv19AJoD+CGhagwaUQOEGKuDlDCQGFAI3ACgidZ+
QPHg8StqqnhqHq1SE2GKwtA=
=Q51A
-END PGP SIGNATURE-
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] doc-build - weekly reminder
Mike Noyes wrote:
On Tue, 2007-03-20 at 11:24, Mike Noyes wrote:
I just committed the lockfile replacement script Charles recommended to
our repository. Please look it over, and I'll try to incorporate it into
doc-build.sh tomorrow.
Everyone,
I just tried to integrate lock_unlock, and ran into a problem.
/home/groups/l/le/leaf/admin/lock_unlock: line 34: syntax error near
unexpected token `('
/home/groups/l/le/leaf/admin/lock_unlock: line 34: ` rm -f
${name}.+([0-9]).+([0-9])'
Any help with this problem is appreciated. The lock_unlock file is in
our cvs repository.
Looks like they're using extended pattern matching (the +([0-9])
portions of the rm statement, which will match any number of digits).
To make bash happy with this syntax, set extglob to on with:
shopt -s extglob
before trying to run the lock_unlock code.
--
Charles Steinkuehler
[EMAIL PROTECTED]
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erich Titl wrote: - adding a tag does not create overhead to the CVS archive (unless we use subversion) Tags do not create overhead in subversion, either. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEX26FLywbqEHdNFwRAqJ/AJwJMVw7dtSQkM6F/FQnG7zEUT3sdQCeOUy1 xVaOa4T/MYltOOlYTAM4eM0= =7uuu -END PGP SIGNATURE- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Glitch in initrd backup when using alternative initrdfile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Hejl wrote: Eric Spakman wrote: There currently aren't any release tags unfortuanatly. But everything in CVS is exactly 2.4.1, so if you build buildenv you would have version 2.4.1. Just to clarify - the main reason that there releases aren't tagged in CVS was not simply because of oversight, but because buildtool currently doesn't support fetching tagged files (and adding would only solve part of the problem - to be of real use, buildtool would need to support branches, so maintenance fixes would be fetched). When making a checkout from CVS, remember to use a SF developer account - synching between the real CVS server and the backup server (which is used for anonymous access) still doesn't seem to work (I infer that from the fact that commits from 2 days ago are still not visible on the backup server). This might be one benefit to subversion. tags and branches in subversion are not special case items, as they are in CVS, but full-fledged repositories in their own right. Assuming buildtool could talk to a subversion repository, it would be a simple matter of specifying the appropriate base repository in a config file somewhere and any desired version (with applicable patches/updates, if it's been maintained) can be built. The difference would be simply (using the somewhat standard CVS-like repository layout): Latest Version: base-URL/trunk Previous release version with updates: base-URL/branches/v1.2.3 Previous release snapshot: base-URL/tags/v1.x.y ...also, since branches and tags are free (zero-copy) in subversion, they don't suffer from the performance penalties encountered with CVS, meaning it's faster/easier to create them as well as easier to use them, so they're more likely to be properly taken advantage of. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEW3RWLywbqEHdNFwRAp85AKCo4C8FwJLNz/43aY/DgeaQz9lVPwCfS6T0 n8ztyvK2IEpIkRb8eSlTH4U= =vOkC -END PGP SIGNATURE- --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Hejl wrote: Hi Erich, I assume the code within buildtool to access a certain file is pretty central. How difficult is it for this piece of code to use an environment variable specifying a TAG (defaulting to HEAD). It is, but that doesn't solve the problem. The idea behind buildtool is that it can use whatever sources (getting them from CVS is only one option, FTP and HTTP are others). So, the version to fetch is stored in a config file (buildtool.cfg, one for each package) - and currently, all those contain HEAD. It would probably be possible to add some hack to ignore the HEAD from the config and use something else (something the user provided) instead, but I haven't tried it. This is where subversion's branching would really shine. You would simply change the repository URL in the main config file and 'head' would point to the latest version of that branch, which is probably what you'd want (ie: security updates/bug fixes included). You would have the same problems the current CVS version has with versions if you wanted to build to a particular repository version number, rather than the latest version of a branch/tag, however. Ideally, building from a local working-copy of the repository will be fairly easy (it sounds like this is getting tested RealSoonNow). This would separate download problems from actually building the source (possibly important for those with flaky internet access, or folks using the flaky sourceforge CVS servers! :). This would also somewhat isolate buildtool from the actual download mechanism, making it possible to use subversion, bit-keeper, perforce, or whatever should anyone want to. It would also mean buildtool wouldn't have to be updated to support building arbitrary versions...you could select from one (or a few) major revisions and get automatic downloads/builds by adjusting the repository URL, and manually create a working copy to build from if you wanted some arbitrary version of a package (or packages) for some reason. I have briefly looked at the buildtool source in CVS, and it looks like it would be pretty simple to add a subversion download method. If I get some spare time I may try to do this, although I'm not exactly a perl guru. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEW67OLywbqEHdNFwRAi2RAKC3V+qmdhLUBwr4AqFgyyutSZfFPQCeOWm/ vnngyLeIT/yvhHPN3KRcjQA= =vqrP -END PGP SIGNATURE- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Glitch in initrd backup when using alternative initrdfile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Hejl wrote: Hi Charles, This might be one benefit to subversion. It might be (I don't know, I've not used subversion so far). But the problem I see for buildtool is not so much that it's too hard to fetch a file for a specific branch, but rather that buildtool currently isn't fetching anything other than HEAD. So, one would have to make pretty much the same changes to buildtool, wether we're using subversion or not. Wether the url created is base-URL/tags/something/filename (for subversion) or base-URLfilename?rev=HEADonly_with_tag=something (for viewcvs) seems to be an implementation detail to me. Actually, that could be something to try: * add a branch in CVS for each release * append only_with_tag=something to each URL to fetch from viewcvs (based on wether the user supplied a branch tag or not). Of course, this would only work if the initial checkout of buildtool was done for the right branch too. This _could_ work (basically, it's along the lines of what Erich suggested). You don't understand how subversion works. It's like a file-system and making a tag or branch is like copying a directory. Everything underneath is copied too. Sorry for the long e-mail...executive summary: *HEAD* (latest version on this branch) is not the same as *TRUNK* (main-line development branch), at least in subversion. :) A brief example, start with a minimal subversion repository, accessed via the following url: https://my.svn.org/svn/ Now let's add a project (bering-uclibc) and the 'default' structure used when importing stuff from CVS. We now have the following URLs: https://my.svn.org/svn/bering-uclibc/ https://my.svn.org/svn/bering-uclibc/branches/ https://my.svn.org/svn/bering-uclibc/tags/ https://my.svn.org/svn/bering-uclibc/trunk/ After adding lots of stuff to the repository (under trunk/), you've got a major release ready: https://my.svn.org/svn/bering-uclibc/trunk/dir1 https://my.svn.org/svn/bering-uclibc/trunk/file1 https://my.svn.org/svn/bering-uclibc/trunk/file2 https://my.svn.org/svn/bering-uclibc/trunk/... You're now ready to make a branch, so you do a *COPY* within subersion: Copy from: https://my.svn.org/svn/bering-uclibc/trunk/ ...to: https://my.svn.org/svn/bering-uclibc/branches/Release_1.0 Now you have: https://my.svn.org/svn/bering-uclibc/Release_1.0/dir1 https://my.svn.org/svn/bering-uclibc/Release_1.0/file1 https://my.svn.org/svn/bering-uclibc/Release_1.0/file2 https://my.svn.org/svn/bering-uclibc/Release_1.0/... So...you can set the repository root in buildtool to either: https://my.svn.org/svn/bering-uclibc/trunk/ ...or... https://my.svn.org/svn/bering-uclibc/Release_1.0/ ...and *BOTH* will work just the same, without buildtool knowing anything about revision numbers. The caveat is that you will always get the *HEAD* of the particular branch you're using, but you don't always have to get the *TRUNK*. NOTE: The initial copy in subversion is fast and 'free' (doesn't take any extra repository space). Only changes to the resulting branches increase the repository size, and it should go without saying (but I'll say it anyway! :) that after copying, changes made to one branch (ie: trunk/file1) will not affect another branch (ie: branches/Release_1.0) unless you explicitly merge the changes (with the various merge commands or by manually backporting). - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEW7HHLywbqEHdNFwRAhmQAKDwiBmaCdJ7/dk3a9tu/vjxPNknCgCeIsYS n9/hPyqmxVTDinQ5h0SKsig= =qOdf -END PGP SIGNATURE- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Re: CVS Backups [was: bering-uclibc and cvs usage]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I now have the CVS tarballs made available by the SF staff (see leaf-admin list) online and available via rsync: [EMAIL PROTECTED]:~$ rsync rsync.steinkuehler.net::leaf-cvs-recover All transfers logged drwxr-xr-x 48 2006/04/14 16:38:00 . - -rw-r--r-- 1355499672 2006/04/14 16:04:58 anon-leaf-cvsroot.tar.bz2 - -rw-r--r-- 1368256626 2006/04/14 16:18:57 devel-leaf-cvsroot.tar.bz2 drwxr-xr-x 8 2006/04/14 16:24:01 anon-leaf-cvsroot drwxr-xr-x 8 2006/04/14 16:31:53 devel-leaf-cvsroot I put them in the separate leaf-cvs-recover rsync module to avoid creating problems for anyone doing automated backups of the leaf-cvs repository. This is about all I have time for today. It might be good if someone with an existing mirror of the CVS repository (or decent bandwidth) makes additional backup copies of the tarball or expanded repository (rsyncing the expanded repository shouldn't take too much bandwidth if you already have a recent copy of the repository). - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEQBfsLywbqEHdNFwRAsMPAKCNQ6QnWWpDhdx7b1vET5AZTIsV/gCg3w6A N3P0o4bcIJbI51NweSRtNbg= =BhPb -END PGP SIGNATURE- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: bering-uclibc and cvs usage [was: Re: [leaf-devel] Re: CVS problem]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Hejl wrote: Again - if there's somebody familiar with perl, CVS and subversion, who wants to port buildtool and genpage, they're more than welcome to do so (and I'd do my best to help as much as I can). Subversion can generally be used as a 'superset' of CVS, and quite a bit of the command line is identical, particularly for the common uses you've probably got coded into your tools (ie: checkout, update, commit), so converting could be as simple as substituting svn for cvs (unless you're using some perl module to directly access CVS w/o using the command-line client). I'm sure there's also a 'wrapper' script available somewhere for most of the less common usages. ...of course, even if the conversion is easy, everything takes some work, and usually more time (especially regression testing!)... P.S. In case somebody is wondering - I'm _NOT_ threatening to move away from SF and create a fork of LEAF on some other site. I'm just saying that at this point, there seems to be nobody available to do the work required to move from CVS to subversion, so migrating to another repository would seem easier than migrating to another SCM, if we are forced to make a decision. Yeah, that's why I figure it's worth it to start keeping a backup rotation of our CVS directory from SF. I'm sure we'll eventually migrate to subversion, but it probably won't be until some critical need forces the issue. :) NOTE: I have overseen the conversion of a very large CVS archive into subversion (the source code for a commercial 3D graphics package), and it's fairly painless using the automated scripts provided with subversion for that purpose. So at least that part *SHOULD* be easy. :) - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEPsaILywbqEHdNFwRAhdvAKCqLElKeeaC/Hs9e4+HYOMiSXv57ACg+Mt+ EVlCG3PxvqUhYJDYyNsHrIE= =Rl/d -END PGP SIGNATURE- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] SF shell cron job: doc-build.sh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: Everyone, I placed revision 1.12 in cvs yesterday. Please take a look at it if you have a chance. Comments and feedback are welcome. If everyone thinks it's usable, I'll enable it in crontab on Monday. RCS file: /cvsroot/leaf/sourceforge/admin/doc-build.sh,v I finally got a chance to look at this, and the CVS version is only 1.8 (*NOT* 1.12). Looks like the SF CVS issues ate some of the most recent commits. Can you post the latest file for review? - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEPQWJLywbqEHdNFwRApKbAKC6YFHnbbqZFW5u+HH/t3PFNG9CDwCgzcu7 z4VOca5FrnGJPzMj3YGUnI8= =8AXe -END PGP SIGNATURE- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Re: CVS problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: On Wed, 2006-04-12 at 06:44, Charles Steinkuehler wrote: QUESTION: What's the status of the SF CVS archive in terms of how long it's going to continue to be in use? If everything is going into subversion soon, I'm not going to mess with generating rotating backups of the CVS repository, but if the CVS stuff is going to stay in production for a while, it's probably worth it. Charles, The SF staff indicates CVS will coexist with SVN for the foreseeable future. Natanael Copa expressed interest in using SVN for Alpine, and the Bering-uClibc team is concerned about buildtool. I enabled SVN, so it is available, but I'm not sure how we proceed from here. We can migrate the existing CVS stuff over to subversion all at once, a project/directory at a time, or kicking and screaming once SF shuts down CVS for good (whenever that might be)...although this depends somewhat on what processes the SF staff makes available. With a local copy of the CVS archive and subversion access, it should be possible to convert any/all of our CVS content at our own pace. Regardless, it sounds like it's worth setting up a rolling backup script for the CVS archives, and it would probably be good to look into backing up our SF subversion repository. Definition: Backup : A process you don't need until you don't do it. (From the Embedded Muse: http://www.ganssle.com/tem/tem115.pdf and the Devil's Infosec Directory: http://www.csoonline.com/read/080105/debrief.html ) :-) - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEPcZPLywbqEHdNFwRAihSAJwLZqsgtu6118pPZOIbFOrPz6UcbACgqBJt Fz9VUXpVRHtmwbXGaKFkxwU= =n7iq -END PGP SIGNATURE- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] SF shell cron job: doc-build.sh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: On Wed, 2006-03-29 at 14:07, KP Kirchdoerfer wrote: Am Mittwoch, 29. März 2006 23:13 schrieb Mike Noyes: Here is an early run of our new document build script. I'm using the default docbook xsl currently. I'll work on a customization layer after initial build testing, etc. are complete. http://leaf-project.org/doc/new/ does that mean changes will be updated by a cron job again? Would be great! KP, Not yet. I'm still working on doc-build.sh. The current revision in cvs is 1.6. Pending: * feedback on shell code in doc-build.sh I finally got a few free minutes to look at this. Your script looks very clean except for one issue with the check_errors function. You're removing the lockfile in this routine, which is required for expected operation if one of the document building commands fails. You are also using the check_errors procedure for testing whether the lockfile generation worked or not. That means if you run this script while another instance is already running, it will not be able to grab the lockfile, but will then forcibly remove the lockfile without owning it (a BadThing :). It looks like the easiest way to handle this is to special case the create_lockfile error checking (ie: put the logic inside the create_lockfile function). If you want the lockfile forcibly grabbed after some amount of time (ie: 8 to 24 hours or so...something that's much longer than document generation should normally take), you can do this with the -l switch, ie: lockfile -l 72000 ... would force removal of any existing lockfile older than 20 hours. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKxcHLywbqEHdNFwRAgdLAJ9aSDUi05ATZ4uCC/qZgQQmyjPSLQCgxmq0 HycMVYykWU01rZ4KdGwcDtw= =kWfM -END PGP SIGNATURE- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] SVN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: On Sat, 2006-03-25 at 16:22, Charles Steinkuehler wrote: Mike Noyes wrote: On Sat, 2006-03-25 at 11:37, Charles Steinkuehler wrote: Mike Noyes wrote: Please let me know which hooks you'd like me to enable, or you can enable them yourself. Thanks for all your feedback on this issue. :-) https://sourceforge.net/docs/E09#scripts https://sourceforge.net/project/admin/svn.php?group_id=13751 It doesn't look like there's a lot of choice for hook scripts. If we enable anything, the most useful is probably the generic e-mail hook (svnnotify). It would be good for general principal to have a 'commits' mailing list, that would receive posts from the svnnotify script (and that anyone could subscribe to). It would also be possible to setup some automation based on the e-mails (ie: automatically re-build documentation if someone commits an update), although I'm not sure we need to go to the hassle. We have a cvs-commits list. Would svn require a separate list, or can it coexist with cvs syncmail? I'd send it to the same list. Charles, SVN svnnotify hook added, and now points to leaf-cvs-commits. Awesome! Thanks Mike! - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEKIQDLywbqEHdNFwRAq87AJ98o06JwcD7tC5RvuUvA8JJgH48qQCcDIEX /BLPCuFHl70a9P8+kiWvmOo= =65K3 -END PGP SIGNATURE- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] flash usb
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jørn Eriksen wrote: Hello Everyone, I found this doing a little search: http://www.mega-tokyo.com/osfaq2/index.php/Disk%20Images%20Under%20Linux So - I wonder - can we just use whatever geomoetry we like with a USB disk? I believe so. As mentioned before, the concept of CHS is quite dated, and hasn't truly reflected what's physically on the disk since pretty much the advent of IDE back in (thinking...) the late 80's, early 90's? AFAIK, as long as the partition table is valid for how the disk is formatted, everything should be fine (at least for those filesystems that actually *USE* CHS info in their internal structurs...many don't, and just use logical block numbering as has been the standard on SCSI drives since roughly the dawn of time :). What I would do to make an image: Use dd to create an appropriately sized blank file (perhaps 4-8 Meg). Mount the filesystem as a loop-back device. Partition the lo device with an HDD partition table (4 main partitions). Create a bootable partition in the first primary parition. Install LRP files from an appropriate image Install desired boot loader (I'm partial to grub for this sort of thing, and it would allow using EXT3, but syslinux, lilo, or most anything should work as well). dd the image to a USB dongle. Test, then ship (or is that ship, then test...I always forget! :). I'm going to try to test the image floating around, but have been fairly short on time lately. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEJzeGLywbqEHdNFwRAqRNAJ42JzAvbfOvK2A1mBolHq6r/ya2eQCeIlH6 tfPpC1ZeYeY258e2L4y9V0M= =+ASE -END PGP SIGNATURE- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] SVN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: On Sat, 2006-03-25 at 11:37, Charles Steinkuehler wrote: Mike Noyes wrote: Please let me know which hooks you'd like me to enable, or you can enable them yourself. Thanks for all your feedback on this issue. :-) https://sourceforge.net/docs/E09#scripts https://sourceforge.net/project/admin/svn.php?group_id=13751 It doesn't look like there's a lot of choice for hook scripts. If we enable anything, the most useful is probably the generic e-mail hook (svnnotify). It would be good for general principal to have a 'commits' mailing list, that would receive posts from the svnnotify script (and that anyone could subscribe to). It would also be possible to setup some automation based on the e-mails (ie: automatically re-build documentation if someone commits an update), although I'm not sure we need to go to the hassle. Charles, We have a cvs-commits list. Would svn require a separate list, or can it coexist with cvs syncmail? I'd send it to the same list. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEJd7aLywbqEHdNFwRAn+cAKChNzP7nhwyp6TCCZ5F8NXIApsy4wCg7+gZ b1HuWuu3tBCYtTg9ZD1gziY= =kYzu -END PGP SIGNATURE- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] lwp (webconf) packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Spakman wrote: Hi Mike, The problem with this kind of tools is that they expect a real USB-key available with a certain size. The problem is that we need to create and image where a few aspects are uncertain: -The size of the usb-key (Mbytes) -Geometry We need a generic tool which creates a bootable image that can be installed on any USB key. IIRC, a USB keys can be formatted as a floppy type device (ie: one partition), or as a HDD (ie: 4 primary partitions). It should be possible to make an image that has an HDD partition table with a smallish (ie: maybe 8 Megs or so, still a *LOT* bigger than a floppy) FAT partition containing the boot files as the first partition. The remaining space could be unused, or formatted and used once the LEAF system was up and running. This should make it unnecessary to know the size of the USB key (as long as the key is bigger than the boot partition size). The geometry issue shouldn't generally be a problem...the CHS geometry of the FAT filesystem is essentially embedded in the partition table, so would be written when the image is burned onto the USB key. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEGfkvLywbqEHdNFwRAqB2AKDQiY+5KdpXe0Y0EftNNfHu15qZBACgvP32 iKxLSWjcFowQvjRx6JRNK7A= =SZN2 -END PGP SIGNATURE- --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Re: adding a new menu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: I need to fix it so it's robust enough for the new SF requirements. Locking has me a bit confused, and I'll need to read how to add that to daily.sh. I'll attempt to address these issues when I work on our documentation build process. If the lockfile utility is available on the SF servers (highly likely, but I didn't check), it's pretty easy: code #!/bin/sh LOCKFILE=leafcron.lock # Get the lockfile if we can, don't retry if we can't lockfile -r 0 $LOCKFILE # Test to see if we have the lockfile if [ $? -ne 0 ] ; then echo Couldn't get lockfile! exit 1 fi echo Got lock file: $LOCKFILE # Do more stuff here... # Done with everything...remove lockfile rm -f $LOCKFILE /code If lockfile isn't available, you can do mostly the same thing using touch and checking for the prior existence of a file, but it's not as graceful as lockfile, particularly when it comes to atomically checking for and creating the lock (shouldn't exactly be a problem for a cron job though, but it is an issue for multiple process access to mailbox files, which is why lockfile exists in the first place). Holler if you need help with the above, or any other scripting chores. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD8mXhLywbqEHdNFwRAnTXAJ9pj9H6Ea8XI/4vVyfK1SIK9q96rgCcC4GQ nZ/EwESoj01Lgwac3+n4CZo= =YZDw -END PGP SIGNATURE- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] SourceForge Permissions Problem
I've got my new server online, and am working on getting my LEAF mirror up and running again. The first problem I've run into is a permissions problem. I cannot access the phpwebsite/images/announce directory, which does not have group read permissions: -bash-2.05b$ ls -ld phpwebsite/images/announce/ drwx--S--- 2 mhnoyes leaf 4096 Feb 25 2005 phpwebsite/images/announce/ If this directory contains secret stuff (ie: local mysql passwords or something), let me know and I'll just exclude it from rsync. If it contains web images (as would be implied by the directory structure), please make this group readable so I can mirror it. Thanks! -- Charles Steinkuehler [EMAIL PROTECTED] P.S. Mike: Let me know if you cannot login to the new system...I transfered the leaf account, but may have to reset the password. The new system is neo.steinkuehler.net, but may also be reached using the previous basic.steinkuehler.net domain name as well. Note the ssh keys have changed so you'll have do delete the .ssh/known_hosts entry if you're on linux, or ssh will be very unhappy. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] SourceForge Permissions Problem
Mike Noyes wrote: On Mon, 2006-01-16 at 05:16, Charles Steinkuehler wrote: I've got my new server online, and am working on getting my LEAF mirror up and running again. Charles, Excellent news. :-) The first problem I've run into is a permissions problem. I cannot access the phpwebsite/images/announce directory, which does not have group read permissions: -bash-2.05b$ ls -ld phpwebsite/images/announce/ drwx--S--- 2 mhnoyes leaf 4096 Feb 25 2005 phpwebsite/images/announce/ If this directory contains secret stuff (ie: local mysql passwords or something), let me know and I'll just exclude it from rsync. If it contains web images (as would be implied by the directory structure), please make this group readable so I can mirror it. Thanks for bringing this to my attention. I removed the empty directory. Please let me know if you see any other issues. Thanks. The main other issue I ran into was filepaths. At first, I tried fixing these (ie: replacing references in the web pages with correct entries for the mirror), but it wound up being too much of a pain. The current solution, which seems to be working fairly well is (note: paths are from memory, so there could be a typo, but you get the general idea): 1) symlink /home/groups/l/le/leaf/ to the appropriate location on the local mirror. 2) Create /tmp/persistent/leaf/tmp/ directory, with temp permissions (ie: 777) There are still some issues (mainly with the rss/news stuff on the home page), but I'll probably wait to do more work until you've done the wiki thing, since that will probably require some tweaking, as well. It's probably all stuff you can tweak if you have time and can login... -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] SF Subversion Beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Hejl wrote: | Hi Mike, | | Ok. I'll sign us up, unless someone has an objection. The SF staff needs | to know our decision by Wednesday 4 January. | will this be in addition to our current CVS repo, or will the current | CVS repo be migrated to SVN and we'll be forced to use that? I'm asking | because a lot of the Bering uClibc infrastructure is built around CVS | and viewcvs, and while the SF CVS infrastructure isn't terribly | reliable, I don't really want to have to hustle to move everything | (webpage+script that generates the packages page, all of the buildtool | setups) to a possibly not yet stable (I guess that's what being a beta | tester is all about) SVN repository. | | If this is in addition to CVS and we can slowly port everything, I have | no problem with that. I should also mention that the web interface to subversion isn't quite as polished as viewcvs is when working with CVS. If any scripts are relying on viewcvs like features to get anything other than the latest revision of something, we'll definately need to slowly port vs. cutover instantly. NOTE: My experience is somewhat dated (ie: 12-18 months ago, when I was setting up our new subversion repository). I'm sure things are likely improved greatly since then, but I'm not up on the current state of the art. I do all my repository browsing via the tortoise SVN client. :O - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDrIQ/LywbqEHdNFwRAuOQAKD2MpyUhHHF1gD2UmW7Fl5WYr1NsACdELeR lHmH/jLbSdLKeLLTcJleU4Y= =Qanh -END PGP SIGNATURE- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] SF Subversion Beta
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: | Everyone, | Are we interested in participating in SourceForge's Subversion Beta? Probably. Subversion is likely better than CVS for our needs, if only for the reason that it *NEVER* modifies files, even if you forget to tag them as binary (since the bulk of our CVS repository is binary tar.gz and iso files). I've been using subversion for quite a while for several internal development projects (including versioning custom binary file formats from CAD tools), and have had no problems with it. It's pretty much a superset of CVS, so it's easy to migrate to. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDqw1ELywbqEHdNFwRAv4cAKCnE8aE4+mhsK9L2WeF8j4k3oZuDgCfcaq5 wMbeT1XwW4gR0d0XAjO7kCA= =Jv0X -END PGP SIGNATURE- --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] 2.6.x kernel support?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erich Titl wrote: | Natanael Copa wrote: | Erich Titl wrote: | | .. | | I dont have time for reading about memory management in Linux right now, | but AFAIK the executables and libraries are mmap'ed. | | This would mean, that an executable would onle be mapped to memory, but | copied as soon as the memory page it resides on is written to by anyone. | This could produce some interrupts. | ... | I don't know if I should/can consider a RAMdisk simply RAM. It needs to | behave like a disk in the sense of logical I/O. | | ... | | It would really not make any sense to copy a mmap'ed executable from RAM | to another place in RAM, | | That would be true if RAMdisk does just mapping. | | but as I said, I'm not 100% sure about that and | currently I dont have time to investigate it (so, strictly I should | have kept my muth shut, but now its to late anyway...:) | | Same for me, still it is an interesting object. Maybe someone with | deeper insight into RAMdisks on Linux could tell. The data in a tmpfs filesystem resides entirely in the page cache (and/or the swap file, if it exists). This is the same status code would have if it was loaded from (for example) an ext2 formatted partition on a HDD or some other 'conventional' filesystem (ie: cramfs, iso9660, FAT, etc.). Upon loading, each instance of an application will get it's own private memory area for stacks and variables, but the executable code is only loaded into memory once. The MMU is used to make the memory visible to more than one process at once (ie: you can have 50 apache process running at once, but they're all executing out of the same chunk of physical memory containing the code, although each process will also have it's own private memory area for state information). So...if you have a program in tmpfs, it can be run in-place, as the files are already in the page-cache. The special handling of tmpfs is due to the fact that there is *NO* filesystem as such on the tmpfs device...instead the virtual memory manager itself takes care of the filesystem details (hence, no formatting is required!). With pretty much any other filesystem, this is *NOT* the case, and you'll have two copies of any data (the copy on the filesystem and the copy in the page cache). This is because tmpfs is the only filesystem that's handled directly by the virtual memory manager, without using a filesystem driver. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDDJXLLywbqEHdNFwRAsWEAJ926QQ2T6whnJYexsfZWcaZhD591gCgnjMC 8Ri6P6yOHL1Kx2gzk6VUWFg= =GEyf -END PGP SIGNATURE- --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] 2.6.x kernel support?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: | Charles, | Forth code is hard to find. The best I could locate is here: | | http://forth.sourceforge.net/ | http://cvs.sourceforge.net/viewcvs.py/forth/forth-repository/ Yep...the language is hard to search on (with forth being a very common english word), and most of the public code was around in the old printed listing and maybe online BBS days. Not a lot in a searchable archive form on the 'net. | I'll look for lua source next. Good luck! - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDCGsSLywbqEHdNFwRAvB9AJ0a58XwSS1XbpwX/OUeRHERdpPErACeOeqR iFo13QtaaUbZfpL/FVRiJqU= =Ppo9 -END PGP SIGNATURE- --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] 2.6.x kernel support?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: | On Fri, 2005-08-19 at 15:01, Charles Steinkuehler wrote: | I would, however, be in favor of using a very powerful, but very small | 'shell-like' scripting language (ie: forth) in the initramfs, with the | 'applications' being scripts rather than biaries, which is what would make | this idea attractive (at least to me). The downside is utilities like tar | and gunzip would have to be coded in forth, which I haven't been able to | find (or had the spare time to write). | | Charles, | Does the initramfs cpio newc/crc buffer format fulfill the compressed | file support? It's not the initramfs system I'm worried about, particularly. It's the utilities we need to put INTO the initramfs in order to build a LEAF root filesystem image from the LRP files and configuration information (ie: LEAF.CFG and the kernel command line parameters). Several utilities are needed (look at /linuxrc for full details), but a lot of stuff could be worked around (ie: replace sed code with 'native' script) or are fairly trivial (ie: mount/umount and similar are pretty much just calls to the kernel with little user-mode function we'd have to duplicate), so it's stuff like gunzip and tar that I think will be hardest to replicate in a 'ground up' rework of the init scripts. | I'll look for forth gzip and tar source. Good luck! I've looked for these before, but have never been able to put much time into it. While you're on the prowl, it might also be good to keep an eye out for lua or (other small script interpreter) versions of these utilities as well... - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDB3jvLywbqEHdNFwRArfJAKDPpcmvOkiXhcOECxejh323Qjn85QCgiMNV kH5Jj9koHlcQeuV0dgkPTMg= =j3iv -END PGP SIGNATURE- --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] 2.6.x kernel support?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: | On Thu, 2005-08-18 at 23:45, [EMAIL PROTECTED] wrote: | We already use ramfs b.t.w. But what is currently the real benefit of | initramfs to LEAF? | | The lwn article sums up the benefits, but I'm still looking for a | better overview of the features/benefits. To me, it looks like the new initramfs would make it possible to do something like the old LRP patch (which allowed the kernel to use a tar.gz file as an initial ramdisk image) without requiring a kernel patch. It also looks like a handy way to solve various boot-strap problems (like getting a kernel with built-in RAID to look for RAID images *AFTER* some external module is loaded). A lot of this stuff is currently (at least circa 2.2/2.4, which I'm more familiar with) kind of 'hacked' into the kernel, and if your boot sequence is particularly odd, you might have to patch the kernel (or load an excessively large initial ramdisk). This feature might be useful in making a very small initial ramdisk image for leaf that 'bootstrapped' the full LEAF system, and would not require a C library of it's own (instead using klibc and essentailly making direct kernel calls). You'll never be able to run bind or sendmail this way, but being able to run a simple shell (or other script processor like forth, lua, etc.) and do things like extract tar files to build a root filesystem image would be all we'd need. This would eliminate the 'special' file that has existed in LRP/LEAF since the beginning (ie: root.lrp or initrd.lrp), replacing it with a (hopefully) standard chunk of init code that was simply linked with the kernel. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDBhfRLywbqEHdNFwRAmVaAKC4ctI4urM+d2fudhAHPB6kPow07gCfeN8c 9COK9Mms7v+4FAAzqVYnw3k= =fP/3 -END PGP SIGNATURE- --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] 2.6.x kernel support?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: | Hello Mike, Charles, | | Still only have webmail, so I hope it will show up on the list | | This feature might be useful in making a very small initial ramdisk image | for leaf that 'bootstrapped' the full LEAF system, and would not require | a C library of it's own (instead using klibc and essentailly making direct | kernel calls). You'll never be able to run bind or sendmail this way, | but being able to run a simple shell (or other script processor like | forth, lua, etc.) and do things like extract tar files to build a root | filesystem image would be all we'd need. | | This is what I mean with redundant, you would need a shell (and other | programs) in the initramfs (pre-init) and in userspace which isn't the | same one. So you need the space for a klibc compiled shell in the | initramfs and an other (uClibc/glibc) compiled shell in root.lrp (or so), | while currently we use one shell which is both used for pre-init (linuxrc) | and userspace. | It isn't possible to use the klibc initramfs programs in userspace | (AFAIK), which would be pointless anyway because the klibc versions | are/should be very limited in functionality/size. | | For Mike: There are ofcourse images of ~1.5 Mb which contain an initramfs | and 2.6 kernel, but they don't contain all the programs we have in such an | image ;) | | But I agree, the initramfs approach would make a technical cleaner | implementation. But it also means (because of redundancy and a bigger | kernel (2.6)) a bigger base image. I also don't see a lot of real | advantages for our case yet. I generally agree with your analysis. Using the initramfs system doesn't make sense for LEAF as it stands now. I would, however, be in favor of using a very powerful, but very small 'shell-like' scripting language (ie: forth) in the initramfs, with the 'applications' being scripts rather than biaries, which is what would make this idea attractive (at least to me). The downside is utilities like tar and gunzip would have to be coded in forth, which I haven't been able to find (or had the spare time to write). I think the entire extra 'footprint', including code to do tar, gunzip, and the forth interpreter itself could be squeezed into maybe 25K or so (assuming no re-use of the application scripts), meaning the 'redundancy' issue wouldn't be that bad, even for a floppy system. If you elected to reuse some of the scripted code, you'd only need a re-compiled interpreter for the appropriate libc, which for forth would probably mean 10-15K of 'redundancy'. ...of course, the probability of this actually happening is pretty close to zero (unless I somehow become independently wealthy!), but I still think it would be cool... - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDBlbULywbqEHdNFwRAnLCAKChLtlI9drIqDN9zgUebloC2L6g7gCg3F3L Mu/XxB1VWh7XxrRsKhulVbM= =ajCI -END PGP SIGNATURE- --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Cramfs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erich Titl wrote: | Hi folks | | I would like to use cramfs to store static filesystems on flash. I know | lince and wisp-dist did that before, I just seem to miss the point on | how to get the xx.cramfs file to the flash medium. | | Do I have to treat it like a binary file system image or can I copy it | to a partition. | | If so what would be the partition type to use. | | Thanks for pointers I believe it's a binary file system image, which you should be able to test by mounting it via a loop-back device. Note that AFAIK, being a binary filesystem image doesn't mean you can't copy it to a partition. Copying it to flash, however, is another story. What kind of flash are you talking about? If this is an embedded system, you have to compile things like pointers to the flash memory into the device driver so the system knows how to talk to it, and get your flash programmed somehow. If you're talking about one of the flash cards that does disk emulation (ie: CF card or similar), I think you can just copy the image over (ie: dd if=image.cramfs of=/dev/hda1). - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCuWfKLywbqEHdNFwRAuqyAJ9RExra5Grtn1RtBNZb9Qt+HWmnxACcDmoL hx1l4qYq64TioZVoCEbt7uk= =K5Ky -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Cramfs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erich Titl wrote: | Charles | | Charles Steinkuehler wrote: | Erich Titl wrote: | | Hi folks | | | | I would like to use cramfs to store static filesystems on flash. I know | | lince and wisp-dist did that before, I just seem to miss the point on | | how to get the xx.cramfs file to the flash medium. | | | | Do I have to treat it like a binary file system image or can I copy it | | to a partition. | | | | If so what would be the partition type to use. | | | | Thanks for pointers | | | I was assuming this, I could, of course, loop mount the cramfs file. I | am just wondering about partition type and size if I just copy the | cramfs image to a partition. AFAIK, the partition (or chunk of raw flash) you copy the cramfs image file to simply has to be *BIGGER* than the image. Any extra space is simply wasted (this is a read-only filesystem, after all). Also, I don't think there is a partition type code specific for cramfs (this FS is mainly used in raw flash or as a ramdisk image, after all). That shouldn't be a problem, however...just use whatever code you want (ie: 0x83, 0xcf, whatever). The kernel typically identifies cramfs partitions via a 'magic number' at the start of the filesystem data, rather than via partition type codes (only available on HDD and similar media) anyway. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCuYnxLywbqEHdNFwRAlGXAKCizcCVtCF7PFLevlog+R2bosP00ACeN5Xt J//w+orAVsEN63JxR/aV4Lo= =aglg -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] rsync -avz rsync.leaf-project.org::leaf-cvs/leaf /home/mega/leaf/leaf-cvs]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erich Titl wrote: | Charles Steinkuehler wrote: | Charles Steinkuehler wrote: | ... | OK, I think I've got it setup correctly. At the very least, the rsync | server should have a current (within the last 24 hours) version of the | *ENTIRE* CVS archive (not just the first 'chunk' of it), and I think it | will | now properly update via cron (or e-mail me if there are problems). | | Looks OK now, thanks ...and I think the cron task is actually doing it's job now, although it's still taking a few tries to get the whole archive: Downloading LEAF CVS Archive... curl: (18) transfer closed with 906409437 bytes remaining to read ...trying again... curl: (18) transfer closed with 555630637 bytes remaining to read ...trying again... curl: (18) transfer closed with 481381949 bytes remaining to read ...trying again... curl: (18) transfer closed with 125861005 bytes remaining to read ...trying again... ...SUCCESS! Unpacking tarball... real15m43.374s user13m4.830s sys 0m57.080s ...done Let me know if you notice any more problems. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCsEfYLywbqEHdNFwRAut6AJ9+W4nJaN0jEs8EY0KR/e7FUi6gLgCdEpED zKrOSyaRmGcVBKChDDaVcKo= =g7LM -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] rsync -avz rsync.leaf-project.org::leaf-cvs/leaf /home/mega/leaf/leaf-cvs]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles Steinkuehler wrote: | Charles Steinkuehler wrote: | | | Erich Titl wrote: | | | | | Hi Charles | | | | | | I am observing a lot smaller rsync chunk for the last few weeks. Has the | | | repository changed? | | | | Unknown...I'll look into it Monday. | | Looks like I'm still having problems downloading the CVS tarball, so only | stuff 'early' in the CVS tarball is getting updated. | | I'm re-working the sync script, but it might be a couple days before I get | all the kinks worked out. I'll post what I wind up with here in case it's | useful to anyone else... OK, I think I've got it setup correctly. At the very least, the rsync server should have a current (within the last 24 hours) version of the *ENTIRE* CVS archive (not just the first 'chunk' of it), and I think it will now properly update via cron (or e-mail me if there are problems). NOTE: The server that this is running on is getting very low on disk space (that's what happens when marketing folks have write access to an FTP server!), but will hopefully not run into serious problems in the next few days. Long term, either a bunch of stuff will get deleted or we'll get bigger disks...just an FYI. Let me know if it looks like anything's wrong...or if everything seems OK. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCrzQULywbqEHdNFwRAp1SAJ9YET6Q6ZCBnkmjprKdJ+PrE4MhQgCfQgJY voLF0N+RZJsphScgjSfiviA= =Crg0 -END PGP SIGNATURE- --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] rsync -avz rsync.leaf-project.org::leaf-cvs/leaf /home/mega/leaf/leaf-cvs]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles Steinkuehler wrote: | Erich Titl wrote: | | | Hi Charles | | | | I am observing a lot smaller rsync chunk for the last few weeks. Has the | | repository changed? | | Unknown...I'll look into it Monday. Looks like I'm still having problems downloading the CVS tarball, so only stuff 'early' in the CVS tarball is getting updated. I'm re-working the sync script, but it might be a couple days before I get all the kinks worked out. I'll post what I wind up with here in case it's useful to anyone else... - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCrgnuLywbqEHdNFwRAn0iAKDK+L3dd7WIgeR6DLfahqvBR691mwCgpyUF 0zNxWjjbL7z4dbN1yq5JBX8= =AiKB -END PGP SIGNATURE- --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] rsync -avz rsync.leaf-project.org::leaf-cvs/leaf /home/mega/leaf/leaf-cvs]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Erich Titl wrote: | Hi Charles | | I am observing a lot smaller rsync chunk for the last few weeks. Has the | repository changed? Unknown...I'll look into it Monday. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCrNBzLywbqEHdNFwRAqIHAKD367V0tadZSRLM1dqHxZ3V62YAHQCgrOY6 T40Y8WvgMKrQyY8lwUFhDuI= =rYcZ -END PGP SIGNATURE- --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] uClibc-Bering and uClibc 0.9.27
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: | Hi Martin, | | Yes, it does look like they have broken it again. BTW, do you know what | ABI means? I've had a hunt, but it appears to be an acronym that you | either know the meaning of or you don't... and I don't! I believe it's Application Binary Interface, but whatever it stands for, it's referring to the calling convention required to use the code. Note that there can be several *DIFFERENT* ways to interface (pass parameters return results) to code (ie: register(s), stack(s), pointer/value passing, etc), and everyone on both 'sides' has to agree on the conventions. In the context of a uClibc, the low-level calling conventions between routines are standardized (by gcc), and ABI is most likely referring to the interface visible to the application (ie: how many and what kind of parameters are required for each function, and what result type (if any) is returned...the stuff you find in the .h header files), which would require a recompile if it changed. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCndc6LywbqEHdNFwRAkMUAKCfV0dMjcs3OcxG7tg1gC4Bl1/BoACfWHXP hgV1W5uabMJ0WgeXGpdz9J0= =IMik -END PGP SIGNATURE- --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] I quit.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Eastep wrote: | It is with regret that I announce that Shorewall development and support is | officially ended. Tom, First, many thanks for creating the firewall that I now use to replace the customized scripts from my earlier LRP/LEAF releases. I know of no better way to say how much I (and many others, I'm sure!) appreciate your work than to let you know it is being used in production environments. Having supported my own LRP/LEAF distributions, I can fully appreciate your reasons for needing to step aside, and the mixture of emotions that creates. I feel it is safe to say that Shorewall will not go quietly into the night, and that it will take many dedicated people to shoulder the burden you've been carrying for quite some time. | I regret letting down those of you who depend on Shorewall. But look at it | this way -- you have the source for all of the code that you run and it's | all written in a very simple programming language. And there was always the | possiblilty that I would walk in front of a bus. | | ... and you have to admit that the price was right :-) You are not letting us down in any way. The contribution you've made to everyone using shorewall is immense, and realized everytime someone downloads a version of shorewall or reads any of the (excellent) online documentation. As others have offered, I can provide any hosting services (via existing CoLo servers) that might be required and cannot be fulfilled by sourceforge. In addition, I am beginning to have a bit more free time and may be able to help with ongoing development. | Shorewall will always be a part of my life that I look back on with fondness. Those of us who use (and will hopefully continue to use) shorewall will always remember your dedication, your tireless responses to queries for help, the quality of your code, and the effort you expended which made our burdens lighter. For all this and more, thank you! - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCi3voLywbqEHdNFwRAvNKAJ9DNjk6SFNoxmsp2o9siqAqqfwXLwCg6M/t laFluaAza/PAuqLzB8BLjoo= =fxpi -END PGP SIGNATURE- --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Re: [Shorewall-devel] What happens now?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: | On Wed, 2005-05-18 at 12:28, Cristian Rodriguez wrote: | 2005/5/18, Tom Eastep [EMAIL PROTECTED]: | I've attached the simple scripts that I use to publish to Sourceforge | and to my own server (shorewall.net AKA lists.shorewall.net AKA | cvs.shorewall.net AKA rsync.shorewall.net). | | http://ftp.belnet.be/ and others are providing rsync mirror,what we | need is a master rsync server,sadly providing the hardware and | bandwith for that is out of my possibilities :( | | anyone at leaf or Mandriva can help with this issue??? | | Cristian, | Charles may be willing and able to help. He hosts the leaf master rsync | site. Yes, I can host a master rsync site for shorewall at either of two CoLo locations (100 MBit/s 45 MBit/s) with hardware that's already in place. I'm already doing this for the leaf CVS archives (import the daily SF CVS tarball and make it available via rsync) so users can mirror the Leaf CVS directory w/o having to download the entire tarball (now multiple GBytes). Just let me know what you'd like setup. We can probably get something running on either SF or the rsync server (or both) that auto-magically builds and/or syncs the site and it's mirrors, works like Tom's publish script, or whatever is desired... - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCi7y3LywbqEHdNFwRAoT7AKDQZS6Fmv5p30Cohf89t7tplCKkcwCg7Xq9 6BNfugAxpZTw+E/nytOVF6M= =VPfH -END PGP SIGNATURE- --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Subversion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: | Everyone, | This is a query to prepare us for the eventual move of SF to SVN. | | How many people have experience with SVN? I need some good resources for | training, and some suggestions on repository structure. Subversion *ROCKS*!!! :) You can typically use the same repository layout you'd use for CVS, differences that might affect how we want to arrange things: - - We can move stuff around in subversion ourselves (no more SF support requests for moving directories!) - - Copies are 'cheap', so making branches/tags (they're the same in svn) is a fast operation, no matter how big the repository gets. - - Subversion *NEVER* modifies your files, so we can check in things like *.lrp files, iso images, etc. without having to worry about using the right command-line switches to make sure the files don't get mangled by EOL replacement, tag expansion, or similar issues with CVS. Subversion *DOES* know about mime-types (it's a property that gets stored along with the file), but it's typically not a major problem if this gets set incorrectly, as the file contents are *NEVER* altered (so you can always tweak the mime-type property later if it's wrong). We're not exactly using CVS for revision control, so our main 'architecure' is in the layout of the directory structure, which should probably stay the same in svn. One big plus will be the ability to copy (snapshot) chunks of the svn tree into a releases area (or similar) when a particular branch (ie: bering or Bering-uClibC) has a release. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCgPJOLywbqEHdNFwRAgc7AKDpdusqFUMMA/EWojtu+Vbfrtnx1QCg3Mml n3kXCUeWnWXpxzTGNGrZXeY= =AGoO -END PGP SIGNATURE- --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering-uClibc: development environment assistance ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: | On Tue, 2005-03-22 at 10:01, K.-P. Kirchdrfer wrote: | We can also offer you access to our complete cvs tree (includes write | access to buildtool :)). | | K.-P., | As a project admin Charles has global write access in our repository. But I'd still prefer to have one of the more regular Bering-uClibc developers check in any changes...at least until I'm more comfortable with the buildtool enviornment, doing a lot more uClibc development work, or both. ...besides, I've been using subversion for so long now (part of my day job), I might not remember how to do the CVS command line thing. :) - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCQZoeLywbqEHdNFwRAvXoAKD2FNRbiRYvLo+S/e20UmCoo4JqZgCg8jp0 LzLwPTaaVGCeiLwUVi6FeYw= =+QTn -END PGP SIGNATURE- --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Bering-uClibc: development environment assistance ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Moved to devel list... Martin Hejl wrote: snip | For a much more verbose description (one that also includes the how | and not only the what), please see | http://leaf.sourceforge.net/doc/guide/buc-devel.html | That should be enough to get you going. If something is unclear or plain | wrong (happens at times, since the documentation doesn't always keep up | with development), please let us know. | | If you have specific questions, please ask as well. | | I hope that helps. I just started playing with buildtool, which seems pretty slick. I think I have the build environment setup and built without problems (I was able to build ncurses and bash), but I'm a bit unsure of how to proceed with trying to build new packages (ie: vim, rsync, etc). What's the easiest way to 'tinker' with creating a new package? It looks like I need to put the initial package files online via http or viewcvs, and add an appropriate server section to conf/sources.cfg. Is this correct, or is there support for 'local', or file:// type of access, so I could just make a local repository with the source tarball and buildtool config files, and not hassle with network downloads? Thanks, - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCQEjNLywbqEHdNFwRAip9AKDC2zAkJglMGfFGWGyvLEp0zSDddgCfbZnb AmXUUtLFVYfB97abKHI2P5Q= =0iP6 -END PGP SIGNATURE- --- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882alloc_id=15148op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering-uClibc: development environment assistance ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 K.-P. Kirchdörfer wrote: | Am Dienstag, 22. März 2005 17:33 schrieb Charles Steinkuehler: snip | What's the easiest way to 'tinker' with creating a new package? It | looks like I need to put the initial package files online via http | or viewcvs, and add an appropriate server section to | conf/sources.cfg. | | Is this correct, or is there support for 'local', or file:// type | of access, so I could just make a local repository with the | source tarball and buildtool config files, and not hassle with | network downloads? | | A quick'n'dirty solution is to create a directory for your app in | buildtool/sources | like | buildtool/sources/rsync | | Copy your source tgz into that dir and create there buildtool.mk and | buildtool.cfg (you may copy existing ones and change as needed). | | You'll have to add the new package to conf/sources.cfg like any other | - don't bother about server/network stuff - with all needed files | in sources/yourpackage it will not try to download again. Thanks...I didn't realize it wouldn't try downloading if the files are already there. So far, the only thing that seems odd about buildtool is the centralized file with all the servers, sources, and packages (conf/sources.cfg). The files for building each package are already seperated per-package, so it seems like this should be multiple files and/or directories as well, ie: ~ conf/servers- File with server entries ~ conf/pagkages/ - Directory ~ conf/packages/mypkg - Single entry ~ conf/sources/ - Directory ~ conf/sources/mysrc - Single entry ...but I have no idea how easy/hard this would be in perl (yes, I've fallen to the point of suggesting new features/functions w/o offering any coding assistance! :). It just seems that having to modify the entire sources.cfg file to add/remove a package is going to get cumbersome eventually... | If you like, I can send you the rsync setup and the corresponding | entry for sources.cfg as example. Please do. Also, what's the preferred method to provide files for a new package so they can be included in CVS? A tgz file of sources/pkg and a diff of conf/sources.cfg, or some other method? - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCQFA6LywbqEHdNFwRAnrXAKDhQBpehDViDfZdaz2VHDhdtprFSQCfUEKp LVs2h5j7MZN1B4OdQPqAvLU= =oWQ9 -END PGP SIGNATURE- --- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882alloc_id=15148op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering-uClibc: development environment assistance ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Hejl wrote: | Hi Charles, snip | So far, the only thing that seems odd about buildtool is the centralized | file with all the servers, sources, and packages (conf/sources.cfg). The | files for building each package are already seperated per-package, so it | seems like this should be multiple files and/or directories as well, ie: | | ~ conf/servers- File with server entries | ~ conf/pagkages/ - Directory | ~ conf/packages/mypkg - Single entry | ~ conf/sources/ - Directory | ~ conf/sources/mysrc - Single entry | I agree that mixing the servers with the sources wasn't a terribly good | idea - but then, the servers in conf/sources.cfg should really only be | sourceforge servers (since that's where buildtool gets the buildtool.cfg | from), so that part should be fairly static. | The split between sources and packages doesn't make much sense to me | right now - mainly because the difference between sources and packages | is very muddled at the moment (the only program that actually makes | some use of that info is buildpacket.pl - so if we defined everything as | package it would work the same way it does right now). But that may | change some time soon as well (or maybe it has already, I've not managed | to stay up to date with Arne's latest changes/scripts). I'm less worried about the packages/sources issue than splitting out the various packages (more below). | I guess the reasoning was to keep things simple and avoid instances | where files weren't kept in sync. Plus historical reasons (things were | stored in a similar manner in the original, make-based buildtool from | uClibc, which we adapted to work for our needs). | | ...but I have no idea how easy/hard this would be in perl (yes, I've fallen | to the point of suggesting new features/functions w/o offering any coding | assistance! :). It just seems that having to modify the entire sources.cfg | file to add/remove a package is going to get cumbersome eventually... | I'm sure it will be at some point. But I'm not sure if keeping several | small files up to date is going to be easier in the long run (not for | adding/removing, but for other kinds of maintenance - new dependencies, | splits of packages and so on). I guess it isn't pretty either way. I'm looking at this from the perspective of a 'power' end user, who would like to tweak some things, but be able to easily stay current on files I choose not to modify. With all package/source statements in a single big file, it seems like it would be harder to use CVS or other versioning software to track changes I've made to the release versions. Examples of things that it would be nice to be able to setup: - - Add package(s) (ie: current vim, rsync, qmail discussions) - - Customize package(s) (ie: unique compile-time options or similar) - - Re-target downloads to a local repository or mirror (to verify complete independence from SF or leaf-project.org, and to control exactly which version(s) of packages are used for an 'in-house' release). - - Easily update a modified project to use new data from the SF CVS archives if/when it becomes available It may be possible (or even easy!) to do this with the current config file, but I didn't immediately see how... - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCQGbJLywbqEHdNFwRAhHgAKDMK9OuC5foNly2WNh8c5nCP8h5nwCggd5g PDrVbFern39w4LixRUvqPsg= =UKhW -END PGP SIGNATURE- --- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882alloc_id=15148op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering-uClibc: development environment assistance ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Hejl wrote: | - - Customize package(s) (ie: unique compile-time options or similar) | Well, as long as you don't want upstream changes to be integrated in | your modified version (see below for that topic), you can do that by | separating the sourcing from the build - run buildtool.pl source | packagename first, make your modifications, run buildtool.pl srcclean | packagename (to make sure all your changes are taken into | consideration, especially if autoconf is incolved). | After that, run ./buildtool.pl build packagename, the sources should | be compiled including your changes. | | But this approach doesn't work for integrating upstream changes into | your setup. Thinking about this some more, I think this could be handled like a 'new' package that would start as a 'clone' of an existing package (ie: myash instead of ash). Local mods could be handled with CVS or SVN the same way you'd track vendor releases. | - - Re-target downloads to a local repository or mirror (to verify complete | independence from SF or leaf-project.org, and to control exactly which | version(s) of packages are used for an 'in-house' release). | That should actually be possible, at least for the packages we've | cleaned up already. Once everything is cleaned up, there should not be | any redundant server definitions - so changing the cvs-sourceforge | server definition in conf/sources.cfg to point to your mirror should | make every package definition use that mirror server (at least, where | cvs-sourceforge is used, and where we've removed all redundancies - if | you spot a package where this isn't the case, please let us know). Do you mean like how bash/buildtool.cfg has a Server cvs-sourceforge section, but etc/buildtool.cfg doesn't? If so, I've provided a grep of all app/pkg/buildtool.cfg files that contain a Server tag (circa March 14) after my sig. The checkout of the apps directory took less than a minute...it's occasionally handy to have the full CVS archive available on a local machine!. :) snip | I hope that clarifies a bit. Yes...thanks for all the pointers! - -- Charles Steinkuehler [EMAIL PROTECTED] naibed:/home/leaf/src/bering-uclibc/apps# grep -A 1 'Server' */buildtool.cfg ash/buildtool.cfg:Server cvs-sourceforge ash/buildtool.cfg- Type = viewcvs - -- automake/buildtool.cfg:Server gnu automake/buildtool.cfg- Type = ftp - -- bash/buildtool.cfg:Server cvs-sourceforge bash/buildtool.cfg- Type = viewcvs - -- beep/buildtool.cfg:Server cvs-sourceforge beep/buildtool.cfg- Type = viewcvs - -- bison/buildtool.cfg:Server cvs-sourceforge bison/buildtool.cfg- Type = viewcvs - -- bpalogin/buildtool.cfg:Server cvs-sourceforge bpalogin/buildtool.cfg- Type = viewcvs - -- bridge-utils/buildtool.cfg:Server cvs-sourceforge bridge-utils/buildtool.cfg- Type = viewcvs - -- buildenv/buildtool.cfg:Server ftp.gnu.org buildenv/buildtool.cfg-Type = http - -- buildenv/buildtool.cfg:Server gcc.mirror buildenv/buildtool.cfg- Type = ftp - -- buildenv/buildtool.cfg:Server cvs-sourceforge buildenv/buildtool.cfg-Type = viewcvs - -- buildenv/buildtool.cfg:Server kernel.org buildenv/buildtool.cfg- Type = http - -- buildenv/buildtool.cfg:Server uclibc.org buildenv/buildtool.cfg-Type = http - -- flex/buildtool.cfg:Server cvs-sourceforge flex/buildtool.cfg- Type = viewcvs - -- hdsupp/buildtool.cfg:Server cvs-sourceforge hdsupp/buildtool.cfg-Type = viewcvs - -- iptraf/buildtool.cfg:Server cvs-sourceforge iptraf/buildtool.cfg- Type = viewcvs - -- kgcc/buildtool.cfg:Server cvs-sourceforge kgcc/buildtool.cfg- Type = viewcvs - -- kgcc/buildtool.cfg:Server gnu kgcc/buildtool.cfg- Type = ftp - -- libgcc/buildtool.cfg:Server cvs-sourceforge libgcc/buildtool.cfg- Type = viewcvs - -- libgmp3/buildtool.cfg:Server cvs-sourceforge libgmp3/buildtool.cfg- Type = viewcvs - -- libpthread/buildtool.cfg:Server cvs-sourceforge libpthread/buildtool.cfg- Type = viewcvs - -- libtool/buildtool.cfg:Server cvs-sourceforge libtool/buildtool.cfg- Type = viewcvs - -- linux/buildtool.cfg:Server kernel.org linux/buildtool.cfg-Type = http - -- local/buildtool.cfg:Server cvs-sourceforge local/buildtool.cfg- Type = viewcvs - -- log/buildtool.cfg:Server cvs-sourceforge log/buildtool.cfg- Type = viewcvs - -- lrpstat/buildtool.cfg:Server cvs-sourceforge lrpstat/buildtool.cfg- Type = viewcvs - -- mawk/buildtool.cfg:Server cvs-sourceforge mawk/buildtool.cfg- Type = viewcvs - -- mgetty/buildtool.cfg:Server cvs-sourceforge mgetty/buildtool.cfg- Type = viewcvs - -- nasm/buildtool.cfg:Server cvs-sourceforge nasm/buildtool.cfg- Type = viewcvs - -- ncurses/buildtool.cfg:Server cvs-sourceforge ncurses/buildtool.cfg- Type = viewcvs - -- net-tools/buildtool.cfg:Server cvs-sourceforge net-tools/buildtool.cfg- Type = viewcvs - -- ntp/buildtool.cfg:Server cvs-sourceforge ntp/buildtool.cfg- Type = viewcvs - -- nttcp/buildtool.cfg:Server cvs-sourceforge nttcp/buildtool.cfg- Type = viewcvs
Re: [leaf-devel] rsync.leaf-project.org::leaf-cvs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: | On Tue, 2005-03-15 at 12:27, Mike Noyes wrote: | On Tue, 2005-03-15 at 11:42, Charles Steinkuehler wrote: | MIKE: I've manually updated the CVS archive on the CoLo system | (rsync.steinkuehler.net), and basic should update soon. It looks to me like | everything's OK, but you might want to check. Note that it might be until | sometime tomorrow before basic has a fully updated archive (I think there | will be a *LOT* of stuff to rsync, and I don't off-hand recall when the sync | occurs, except I think it's late-night/early-AM). | | Thanks. I'll rsync tomorrow. It'll probably take me a while. Sorry I | didn't notice this problem earlier. :-( | | Charles, | My rsync is still going. :-( | | Did you verify the expanded tarball was correctly placed on the rsync | leaf-cvs module? It looks like it: [EMAIL PROTECTED]:~$ rsync rsync.steinkuehler.net::leaf-cvs/leaf/src/bering-uclibc/buildtool/ All transfers logged drwxr-xr-x4096 2005/03/15 16:30:29 . - -r--r--r-- 193 2002/11/25 03:16:03 .cvsignore,v drwxr-xr-x4096 2005/03/15 16:30:28 Attic - -r--r--r-- 18231 2003/02/22 01:28:12 COPYING,v - -r--r--r--6660 2004/10/12 03:03:48 Changes,v - -r--r--r-- 10743 2002/12/02 01:19:06 Makefile,v - -r--r--r-- 11024 2004/04/11 16:20:16 README,v - -r--r--r--6245 2004/10/12 03:03:48 TODO,v - -r--r--r-- 184 2002/11/24 01:53:15 Version,v drwxr-xr-x4096 2002/11/24 02:14:58 build - -r-xr-xr-x 65020 2005/03/14 18:19:17 buildpacket.pl,v drwxr-xr-x4096 2005/03/15 16:30:26 buildtool - -r-xr-xr-x 15651 2005/03/09 23:38:32 buildtool.pl,v drwxr-xr-x4096 2005/03/15 16:30:23 conf drwxr-xr-x4096 2005/03/15 16:30:22 doc drwxr-xr-x4096 2005/03/15 16:30:10 make drwxr-xr-x4096 2003/02/24 09:29:01 sources - -r--r--r-- 203 2002/11/24 01:53:15 tar-exclude,v drwxr-xr-x4096 2002/11/24 02:14:59 test drwxr-xr-x4096 2005/03/15 16:30:20 tools Note that basic is currently not setup to automatically sync, as it looks like it's commented out in (user leaf's) crontab: # m h dom mon dow command # Sync Project directory # 45 2 * * * /home/leaf/bin/sync-www # Sync CVS directory # 45 3 * * * /home/leaf/bin/sync-cvs I manually launched a sync, so now I have a local copy of the CVS archives as well as the copy on the CoLo server. Mike: Feel free to uncomment the sync scritps on Basic if you'd like. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCOcMeLywbqEHdNFwRAuPGAJ4qwyMcvrNadBKEwEfefZgAACCz9ACg48Lw sHmy9BudsWAN7qmhT5UdKSs= =nxa1 -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] possible bug in linuxrc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Erich Titl wrote:
| Hi
|
| There is a possible bug in linuxrc (at least with the busybox of Bering)
| when trying to create and mount the /tmp filesystem.
|
| Here is the output from /linuxrc.err
|
| mount -t tmpfs tmpfs /tmp -o size=20M
| mount: Mounting tmpfs on /tmp failed: Invalid argument
| mount -t tmpfs tmpfs /tmp -o size=20M
|
| I extended linuxrc a little to get the debug info. It appears as if the
| tmpfs mount does not like the parameter substitution used for tmp_size
|
| here is the relevant code
|
| [ $VERBOSE ] Lecho Generating /tmp /var/log partitions ...
| echo mount -t tmpfs tmpfs /tmp ${tmp_size:+-o size=$tmp_size}
| /linuxrc.err
| qt mount -t tmpfs tmpfs /tmp ${tmp_size:+-o size=$tmp_size}
| echo mount -t tmpfs tmpfs /tmp -o size=$tmp_size /linuxrc.err
| qt mount -t tmpfs tmpfs /tmp -o size=$tmp_size
|
| as you can see, the second mount appears to work, this is with tmp_size
| set to 20M in leaf.cfg
I suspect the entire -o size=20M is being passed to mount as a single
argument, causing the problem. Options include splitting the substitution
or using eval, ie:
qt mount -t tmpfs tmpfs /tmp ${tmp_size:+-o} ${tmp_size:+size=$tmp_size}
- -or-
eval qt mount -t tmpfs tmpfs /tmp ${tmp_size:+-o size=$tmp_size}
- -or-
eval qt mount -t tmpfs tmpfs /tmp ${tmp_size:+-o size=$tmp_size}
- --
Charles Steinkuehler
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFCOChsLywbqEHdNFwRAviPAJ9hnQ8SJw5BMRoZLavt/MuRJe/CHwCfcIC0
2z4Q70QGJ5hk+EAYwt5f39E=
=iZQ0
-END PGP SIGNATURE-
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] possible bug in linuxrc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eric Spakman wrote:
| Hi Erich,
|
| Of I'm not mistaken Charles suggested this change some time ago on
| this list ;-) But I can't find the mail right now.
|
| Eric
|
| In Bering-uClibc it is fixed some time ago like this:
| qt mount -t tmpfs tmpfs /tmp -o defaults${tmp_size:+,size=$tmp_size}
|
| great, was this fed back? I got my version from Charles some time ago.
The Bering-uClibc guys are currently much better at doing updates than I am.
:)
My Bering-CD image is currently working OK for in-house use, and isn't
really getting updated, although I do try to comment on (and post potential
fixes for) any bugs in the scripts I've written.
- --
Charles Steinkuehler
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFCOK/5LywbqEHdNFwRArv+AKCf6KPyu6I3Lk1ZvIMa1LTifjlUvACggV4s
mmX//nyWC4/Mun+2PcceKII=
=RjDS
-END PGP SIGNATURE-
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] rsync.leaf-project.org::leaf-cvs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: | On Mon, 2005-03-14 at 13:32, Charles Steinkuehler wrote: | Mike Noyes wrote: | | Is the rsync leaf-cvs archive still updating? It doesn't seem to be | | current. Is it a problem with the nightly tarball created by SF? | | | | Example: | | leaf-cvs/leaf/src/bering-uclibc/buildtool/buildpacket.pl | | 37703 2004-07-24 10:51 buildpacket.pl,v | | | | | http://cvs.sourceforge.net/viewcvs.py/leaf/src/bering-uclibc/buildtool/ | | It looks like it's at least trying to work...I'm downloading the following URL: | | http://cvs.sourceforge.net/cvstarballs/leaf-cvsroot.tar.bz2 | | ...is that the right one? | | Charles, | Yes, that's the correct file. If it's a problem with the nightly tarball | creation on SF, I'll open a SR with them. I downloaded the tarball and tried to de-compress it, and got the following: bunzip2: Compressed file ends unexpectedly; ~perhaps it is corrupted? *Possible* reason follows. bunzip2: No such file or directory ~Input file = leaf-cvsroot.tar.bz2, output file = leaf-cvsroot.tar It is possible that the compressed file(s) have become corrupted. You can use the -tvv option to test integrity of such files. You can use the `bzip2recover' program to *attempt* to recover data from undamaged sections of corrupted files. bunzip2: Deleting output file leaf-cvsroot.tar, if it exists. I'd say it looks like there's a problem with the tarball, but I'm going to try again to make sure. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCNs/kLywbqEHdNFwRAt9AAJ4r7PpGwNpKAk2J7SRg1cQhL4WvjQCeORGz nJE0rJ09+vLLHDicweTScY4= =8jTh -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] rsync.leaf-project.org::leaf-cvs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles Steinkuehler wrote: | Mike Noyes wrote: | | | On Mon, 2005-03-14 at 13:32, Charles Steinkuehler wrote: | | Mike Noyes wrote: | | | Is the rsync leaf-cvs archive still updating? It doesn't seem to be | | | current. Is it a problem with the nightly tarball created by SF? | | | | | | Example: | | | leaf-cvs/leaf/src/bering-uclibc/buildtool/buildpacket.pl | | | 37703 2004-07-24 10:51 buildpacket.pl,v | | | | | | | | http://cvs.sourceforge.net/viewcvs.py/leaf/src/bering-uclibc/buildtool/ | | | | It looks like it's at least trying to work...I'm downloading the | following URL: | | | | http://cvs.sourceforge.net/cvstarballs/leaf-cvsroot.tar.bz2 | | | | ...is that the right one? | | | | Charles, | | Yes, that's the correct file. If it's a problem with the nightly tarball | | creation on SF, I'll open a SR with them. | | I downloaded the tarball and tried to de-compress it, and got the following: | | bunzip2: Compressed file ends unexpectedly; | ~perhaps it is corrupted? *Possible* reason follows. | bunzip2: No such file or directory | ~Input file = leaf-cvsroot.tar.bz2, output file = leaf-cvsroot.tar | | It is possible that the compressed file(s) have become corrupted. | You can use the -tvv option to test integrity of such files. | | You can use the `bzip2recover' program to *attempt* to recover | data from undamaged sections of corrupted files. | | bunzip2: Deleting output file leaf-cvsroot.tar, if it exists. | | I'd say it looks like there's a problem with the tarball, but I'm going to | try again to make sure. OK, I tried again and get the same error. Extrating the filenames from the uncompressed partial tarball yeilds 1544 filenames, ending with: - -r--r--r-- 91103/14751 7326801 2003-01-30 23:47:21 leaf/devel/ccarr/devel/bering/dist/Bering_1.0-stable_modules_2.4.20.tar.gz,v Anything after this isn't getting updated. Note that the SF tarball is getting created and updated, as evidenced by some files with recent dates, ie: - -rwxrwxr-x 99/147512189750 2005-03-14 16:33:14 leaf/CVSROOT/history Sounds like we need to make a support request to SF. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCNtfMLywbqEHdNFwRAsxbAJsH42RwuW4Reb3Jb3CFf+75Q0L6bQCcD4cd oiRch/38mO6l4IYWmFVC24U= =8cRv -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] rsync.leaf-project.org::leaf-cvs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles Steinkuehler wrote: | Sounds like we need to make a support request to SF. Hold off on this for now...both times I tried downloading with links. I'm now using curl, and it looks like I'm going to wind up with a different (larger) sized file. I'll post the results when finished. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCNv6tLywbqEHdNFwRAnFPAKDVzyvq/2h+47PWN7VDcRBRzjFgCACdH2/b +GxyGa3LDN4EEog+xPs9YWI= =IOUK -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] rsync.leaf-project.org::leaf-cvs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: | On Tue, 2005-03-15 at 07:26, Charles Steinkuehler wrote: | Charles Steinkuehler wrote: | | | Sounds like we need to make a support request to SF. | | Hold off on this for now...both times I tried downloading with links. I'm | now using curl, and it looks like I'm going to wind up with a different | (larger) sized file. | | Charles, | Will do. | | I'll post the results when finished. | | Thanks. :-) OK, I think I've figured out what's going on. For some reason, the SF server is disconnecting the client before the entire CVS tarball gets downloaded. Using curl's resume capability, I was able to download the entire archive, but it took several successive tries. Each attempt would fail after about 7-8 minutes or apx 200-300 MB of data: multiple curl commands output edited for readability [EMAIL PROTECTED] charles]$ curl -OC - 'http://cvs.sourceforge.net/cvstarballs/leaf-cvsroot.tar.bz2' ~ % Total% Received % Xferd Average Speed Time ~ Dload Upload TotalCurrent Left ~ 25 1056M 25 266M0 0 545k 0 0:33:01 0:08:20 0:24:41 curl: (18) transfer closed with 827527107 bytes remaining to read ~ 29 789M 29 233M0 0 487k 0 0:27:36 0:08:10 0:19:26 curl: (18) transfer closed with 582198011 bytes remaining to read ~ 39 555M 39 218M0 0 530k 0 0:17:50 0:07:00 0:10:50 curl: (18) transfer closed with 353273803 bytes remaining to read ~ 89 336M 89 300M0 0 528k 0 0:10:53 0:09:43 0:01:10 curl: (18) transfer closed with 37835243 bytes remaining to read 100 36.1M 100 36.1M0 0 451k 0 0:01:21 0:01:21 0:00:00 So...I'm not sure *WHY* the SF server is disconnecting, but that definately seems to be what's happening. Can someone with good bandwidth try downloading the tarball with a normal web-browser like Mozilla or IE? I've tested with curl and links, but don't have a GUI running on a machine with a fat upstream link. Currently, it looks like I'm going to have to script the grab of the CVS tarball (it's currently a 'one-liner' in cron) and loop until curl exits with an error other than 18. | BTW, are you using --delete when updating the rsync server? I noticed | some errant commits, that were removed by the SF staff, present in the | leaf-cvs module. Um...I can't rsync directly to the CVS archive. I'm basically grabbing the tarball and 'exploding' it in place on my CoLo system, then rsync'ing from that system to basic.steinkuehler.net. That means there's nothing in place to delete files that may have existed in the CVS archive at one time, but don't any more. If you want, I can wipe the output directory prior to untaring the downloaded file, which should clear out any cruft. MIKE: I've manually updated the CVS archive on the CoLo system (rsync.steinkuehler.net), and basic should update soon. It looks to me like everything's OK, but you might want to check. Note that it might be until sometime tomorrow before basic has a fully updated archive (I think there will be a *LOT* of stuff to rsync, and I don't off-hand recall when the sync occurs, except I think it's late-night/early-AM). - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCNzqpLywbqEHdNFwRAhA1AJ4gbLzP8SABYMwqAZAgDuVHumYMuwCfcqSt YMD4/Lo0VIlDKuyeaj36qpg= =C0Jc -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] rsync.leaf-project.org::leaf-cvs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Noyes wrote: | Charles, | Is the rsync leaf-cvs archive still updating? It doesn't seem to be | current. Is it a problem with the nightly tarball created by SF? | | Example: | leaf-cvs/leaf/src/bering-uclibc/buildtool/buildpacket.pl | 37703 2004-07-24 10:51 buildpacket.pl,v | | http://cvs.sourceforge.net/viewcvs.py/leaf/src/bering-uclibc/buildtool/ It looks like it's at least trying to work...I'm downloading the following URL: http://cvs.sourceforge.net/cvstarballs/leaf-cvsroot.tar.bz2 ...is that the right one? - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCNgL6LywbqEHdNFwRAshAAKDDgx0nA5mEsH5oWdhBe6yeBBwRdwCgyjcJ XxfK1E4V5GDJ3ZkT2lvKKoQ= =jW7S -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] What I don't like about Bering uClibc
Hans Ulrich Niedermann wrote: snip 3. (lrcfg aka config) Every time I have modified a config file of package XYZ in lrcfg, I have to a) run /etc/init.d/XYZ restart from another shell b) make the changes permanent doing this: - go up two levels in the menu - enter the backup menu - read through the list to find XYZ' number (different from XYZ' number in the Packages configuration menu) NOTE: You can use the package name instead of the number. I haven't typed a package number in ages (they're too hard to locate when you've got a lot of packages loaded). - type b to back up - wait for some time - manually compare two numbers without given units, where one shows Bytes (new file size) and the other Kilobytes (free space) - if enough space is available, I have to manually confirm I'd like to have to menu entries in the package configuration: i) restart service ii) make changes permanent This should check for the amount of free space by itself. Both are good ideas. Checking for free space is harder than you'd think, especially at the limits (when the backup media is almost full), as you have to compare available space with file size taking into account sector sizes that might be different between the /tmp ramdisk and the backup media. The lack of du amd some other tools on earlier versions of LRP/LEAF when the backup scripts were written also contributes to the current behavior. 4. (lrcfg, buildtool, ???) Every time I have an updated package and install it, I have to manually save my config files and somehow merge them into the new package. Keeping the config, or having diff/edit, or even 3-way merge would be very nice. Try using partial backups, which backup just the configuration files. As long as you don't update to a new version with incompatable config files, you should be OK. I upgrade my systems by just inserting a new CD (with updated packages) and rebooting...the configuration data is all on a floppy (as partial backups) and is seamlessly used by the newly updated package(s) from the CD. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Re: Asunto: Re: [leaf-user] Leaf website
Mike Noyes wrote: On Thu, 2004-12-30 at 09:02, Charles Steinkuehler wrote: Also, I'm not sure basic is properly mirroring the SF web content anymore (at least it looks different). Do the syncing scripts perhaps need to be modified with all the recent changes to the website? That task is on my to-do also. Mirroring is a little more complex to setup, but easier to maintain. I need to write up a set of instructions. I'll probably use basic to make sure I have the steps correctly documented. Is the mirror script in leaf crontab? The mirror scripts are in the leaf user's home directory, called by crontab leaf crontab # m h dom mon dow command # Sync Project directory # 45 2 * * * /home/leaf/bin/sync-www # Sync CVS directory # 45 3 * * * /home/leaf/bin/sync-cvs /leaf crontab The cvs sync basically rsyncs from a remote server that has enough bandwidth to download the whole CVS tarball nightly. The www sync first rsync's the site content from SF, then rebuilds the local mysql database from the nightly leaf sql database dump (which it expects to find in mirror/leaf.sql). -- Charles Steinkuehler [EMAIL PROTECTED] --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Leaf.cfg
Erich Titl wrote: Charles after moving from lrpkg.cfg to leaf.cfg and the new linuxrc, which I hopefully did right... I found something weird in my backdisk file after manually loading bash using lrpkg -i /disk/bash (/disk being the mount point of my CF) mhttpd=-t msdos /dev/hda1 webconf=-t msdos /dev/hda1 bash=-t console=ttyS0,38400 It looks like lrpkg did not handle the file system and the device correctly. The reason I believe lies in the lrpkg command which scans for the boot parameter in the command line and tries to find the boot.fstype file too. Is there a more recent version available? This is a known bug, resulting from the elimination of the boot.fstype file. It's considered 'cosmetic' (and hasn't been fixed by me) for a few reasons: - If you actually want to backup a manually installed package, you'll have to specify a backup target. It's not possible for lrpkg to know which of the available targets you'll want to use to backup the pacakge. You could default to the first entry in /var/lib/lrpkg/pkgpath.disks, which should be right most of the time, but might not be the right thing to do all the time. - Currently, if you try to backup a manually installed package, you get an error (due to the malformed backdisk entry), 'prompting' the user to select an appropriate backup path. - As soon as you manually specify a backup path in lrcfg, the backdisk file is corrected. - I haven't had time to re-work lrpkg to extract the backup information from pkgpath.disks if boot.fstype doesn't exist. There's no newer version available that I'm aware of. If manually setting a backup destination is enough of a problem, feel free to hack on lrpkg. I'll help as time allows. -- Charles Steinkuehler [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Leaf.cfg
Erich Titl wrote: Hi Charles another little problem showed up using the bash package, apparently bash is included in initdr.lrp (or at least in initrd.list) this prevents bash being backed up using lrcfg. Problem summary: - initrd.lrp includes /bin/bash (symlink to ash) - installing 'real' bash.lrp means multiple packages list /bin/bash in their package.list files, so bash never gets backed up. There's not a perfect solution to this problem, as it is impossible in the current packaging system to include the same file in more than one package. Options for work-arounds include: 1) Remove /bin/bash from initrd.lrp, creating the symlink 'on the fly' as part of the init scripts. This moves the problem to root.lrp (which will try to backup the /bin/bash symlink...if /bin/bash is added to root.exclude.list, we're back to where we started, and bash will never get backed up). 2) Move the 'real' bash to someplace like /usr/bin/bash. This keeps files from steping on each other when backing up, but /bin/bash will still be a symlink to /bin/ash, unless modified (at which point you can no longer make a 'clean' backup of initrd.lrp). 3) Use indirection, similar to the debian 'alternatives', ie: /bin/bash - /etc/alternatives/bash ..and one of .. /etc/alternatives/bash - /bin/ash ..or.. /etc/alternatives/bash - /usr/bin/bash With this method, you can make a 'clean' backup of both initrd.lrp *AND* bash.lrp, with the change required to select whether to use ash or bash as /bin/bash saved in a third package (either etc or a seperate alternates pacakge). ...or you can just ignore the whole mess, and don't backup initrd or bash (or manually remove /bin/bash from one package list file if you need to backup the other). Realistically, it shouldn't generally be required to backup the bash package (for anyone other than the maintainer), and it's only rarely necessary to backup initrd.lrp, so this is the option -- Charles Steinkuehler [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Re: lrcfg and generating leaf.cfg
Arne Bernin wrote: Hi Charles! i just started a small discussion with other bering-uclibc team members, about generating the leaf.cfg file on user request. My intention is that i would like to have a small script started by lrcfg that takes the list of installed packages (from /var/lib/lrpkg/packages), the list of backup devices (from /var/lib/lrpkg/pkgpath.disks) and puts them (after mounting it) into leaf.cfg... (no more editing of leaf.cfg by hand for this). So i was just wondering if this is the way the leaf.cfg should be, all fileystems in PKGPATH and in LRP only the package names ? If i remember it right there was a time when you could put into the LRP line the filesystem names, also . Is this obsolete ?? And what do you think about that idea in general ? I don't have any fundamental objection to doing this, I just wonder how useful it would be. In order to automatically create the leaf.cfg file, you'd already have to have a working LEAF system, meaning your PKGPATH and other critical settings would have to be correct. Anyway, if this is useful enough to someone they want to code it, I'll help if there are any questions about details. As for your questions above: - I assume by filesystems you mean mountable device with optional filesystem specifier (ie: /dev/fd0[:MSDOS], as used by PKGPATH=) rather than just a filesystem (ie: MSDOS). - All mountable devices (and optional filesystem specifier) used to read packages should go into the PKGPATH variable. Note that ORDER IS IMPORTANT, particularly on systems using partial backups, but the correct order should be preserved in the pkgpath.disks file. - Filesystem specifiers are not currently allowed as part of LRP=, but there is an optional search-order specifier (package[:f|:F|:r|:R]). I'm not sure you could extract the search-order suffix w/o parsing the initial kernel command line or existing LEAFCFG file. I wrote this to you personally cause i am not subscribed to leaf-devel, but could do this if you prefer. It seems like leaf-devel is the appropriate place to talk about such issues (CC'd on this e-mail), but you could be cc'd on messages to this thread if you don't want to subscribe (note leaf-devel is farily low-volume). -- Charles Steinkuehler [EMAIL PROTECTED] --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Leaf.cfg
Erich Titl wrote:
Charles
Thanks, the README seemed to make it clear
Unfortunately linuxrc died, so I had to open my box, pry the CF out and
add what's needed
here is the resulting error
LINUXRC: Bering - Initrd - V1.2
Using /boot/lib/modules/ide-core.o
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Using /boot/lib/modules/ide-detect.o
hda: 3SYSTEM SSSCF032MAA, CFA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Using /boot/lib/modules/ide-disk.o
hda: attached ide-disk driver.
hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
hda: task_no_data_intr: error=0x04 { DriveStatusError }
hda: 63488 sectors (33 MB) w/2KiB Cache, CHS=496/4/32
Partition check:
hda: hda1 hda2 hda3
Using /boot/lib/modules/natsemi.o
natsemi dp8381x driver, version 1.07+LK1.0.17, Sep 27, 2002
originally by Donald Becker [EMAIL PROTECTED]
http://www.scyld.com/network/natsemi.html
2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
eth0: NatSemi DP8381[56] at 0xc4827000, 00:0d:b9:00:6d:f4, IRQ 10.
eth1: NatSemi DP8381[56] at 0xc4829000, 00:0d:b9:00:6d:f5, IRQ 11.
.: Kernel panic: Attempted to kill init!
Can't open /var/ lib/lrpkg/root.blk.mk
The problem appears to be /var/lib/lrpkg/initrd.list which was missing
the entry for /var/ lib/lrpkg/root.blk.mk. Maybe you want to add this to
the README for poor fools like me.
Hmm...it sounds like you've got broken version of the initrd package. If
this is the initrd.lrp directly from Bering, it sounds like there's a bug.
/me
...wanders off and checks the initrd.lrp package on my custom-built CD-ROM
package, which exhibits this error, so it sounds like a bug.
--
Charles Steinkuehler
[EMAIL PROTECTED]
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] SNMP and RRD
Mike Noyes wrote: On Thu, 2004-10-21 at 13:51, Charles Steinkuehler wrote: Mike Noyes wrote: On Thu, 2004-10-21 at 11:25, Charles Steinkuehler wrote: Mike Noyes wrote: Can RDD work through a secure serial line? Define secure serial line. A machine isolated from the network through a serial line connection for logging purposes. Since you can't run arbitrary commands or communicate via networking, if you want to monitor the 'health' of the LEAF box (without adding a seperate, network connected monitoring box, which is what I'd probably do) Charles, Point taken. I apologize for the misguided question. Now you're confusing me...your question wasn't misguided at all. The main reason I'd put monitoring on a more connected box is because I'd probably want to access it from my desktop web-browser, or via the internet when I'm traveling, and the primary reason to setup logging over a serial link is to have a completely disconnected machine that (presumably) can't be compromised by an attacker keeping accurate logs. Also, in several instances, I'm running the monitoring programs on machines very remote to the actual firewalls (try running a serial line from California, Colorado, or Kansas to Texas!). If you're happy using the logging machine's console (and pretty much only that console) to monitor the status of your LEAF box, there's no reason you can't (or shouldn't) do so...provided you can get all the info you want to monitor headed to the log file (and find/create appropriate log analysis tools). -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] SNMP and RRD
Mike Noyes wrote: Eric de Thouars, Can RDD work through a secure serial line? Define secure serial line. AFAIK, RRD can monitor just about anything you can collect data from, including SNMP (for both local and remote systems), as well as the output from local commands (to monitor anything from free memory and HDD space to the performance statistics of your mail or database server). If your secure serial line is capable of running IP or executing commands on the LEAF box, you should be able to monitor via RRD and SNMP (or some other data gathering back-end). -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] SNMP and RRD
Mike Noyes wrote: On Thu, 2004-10-21 at 11:25, Charles Steinkuehler wrote: Mike Noyes wrote: Eric de Thouars, Can RDD work through a secure serial line? Define secure serial line. A machine isolated from the network through a serial line connection for logging purposes. http://www.mail-archive.com/[EMAIL PROTECTED]/msg02404.html Issue 74: Secure Logging Over a Network http://www.linuxjournal.com/article.php?sid=3913 OK, I'm going to make some assumptions about this sort of setup, mainly that you've configured the LEAF box to spit out logging data on the serial line, and you've got an otherwise unconnected box at the far end of the serial link that's just collecting and logging the data. I'm also assuming you want to run RRD on the logging box, not on the LEAF box. In this sort of setup, there's mainly one-way connectivity (the LEAF box spitting serial log messages to the logging box), which is what you want. Since you can't run arbitrary commands or communicate via networking, if you want to monitor the 'health' of the LEAF box (without adding a seperate, network connected monitoring box, which is what I'd probably do), you first need to setup something on the leaf box that dumps the desired information into the log file, which could be as simple as a crontab entry, ie: */5 * * * * root logger -t mydata `uptime` would spit out uptime and load average every 5 minutes. On the logging system, you'll need to setup something to extract the desired data from the logs and feed it to RRD, MRTG, or whatever other analysis tool you want to use (this excercise is left for the reader :-). -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Bering 1.2: linuxrc, root.dev.mk and logging
Jon Clausen wrote: Am I reading /var/lib/lrpkg/root.dev.mk correctly? AFAICT everything it does sends any output to /dev/null (except possibly the cd-rom stuff right at the end). Assuming that it is meant to work silently (ie no logging), then there shouldn't be a problem with swapping the code in /linuxrc so that /var/log gets mounted *after* devices are created? I ask because: Wanting to log to harddisk, I had to do the above. It worked nice (thread on leaf-user ends with: Harddisk: device deceased) apart form the fact that the disk died. I subsequently got a personal request to explain how I did it. This all made me think that it would be nice to 'formalize' the functionality. So I concocted some code to parse a log_dev=/dev/hdXn:fstype -statement in /proc/cmdline. Obviously an actual mount can't take place before the device to mount is created. The code seems to do what it's supposed to, but before I submit it here for review, it seemed like a good idea to get it straight whether or not there would be a problem with mounting /var/log after root.dev.mk runs. There should be no problem making the root devices prior to mounting /var/log. In fact, in the latest init scripts (see Bering uClibc or my not-quite-released Bering-CD), the creation of block devices occurs prior to mounting the *ROOT* ramdisk (to allow reading of leaf.cfg and support run-time configuration of ramdisk size). -- Charles Steinkuehler [EMAIL PROTECTED] --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [--ot] [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
Erich Titl wrote: Hi At 21:55 06.07.2004, Lynn Avants wrote: On Monday 05 July 2004 07:44 pm, Mike Noyes wrote: On Mon, 2004-07-05 at 16:14, Chad Carr wrote: I say we all take a look at it, stamp it with approval or disapproval, and move on to more pressing questions, like when to back up changes and how the hell to write a full-featured templating system in the 92k stripped down /bin/sh from Oxygen! Chad, Dash may help in this area. http://gondor.apana.org.au/~herbert/dash/ DASH is a POSIX-compliant implementation of /bin/sh that aims to be as small as possible. DASH is not compilable for glibc-2.0.7. Some time ago I tried to use busybox ash instead of the installed one on Bering 1.2+. My goal was to get more space for possibly a more recent gclibc library and more modern package versions. I quickly found out that the ash syntax used in, for example, the backup routines did not work. I guess in order to be able to use different shells we should stick to an extreme low level of the possible tricks in the scripting _dialect_ so porting issues will pop up less frequently. This may sound like heresy in the ears of shell afficionados but will enhance the chance to use different interpreters. No idea how much work it would take to get up to level alone with busybox ash, let alone with another interpreter. My understanding is the busybox ash comes from the same source the ash used in LRP came from (although I think there are a few differences, such as command line history, that are implemented differently), and should work fine with LEAF. IIRC, busybox ash has several compile-time options to allow for smaller size (by omitting lesser-used features that the complex scripts in LEAF tend to rely on). Are you sure you had everything enabled when you built the busybox ash and it still didn't work with Bering? -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [--ot] [leaf-devel] leaf-tools overview (cdb, trig, tmpl)
Erich Titl wrote: Charles At 23:43 06.07.2004, Charles Steinkuehler wrote: snip IIRC, busybox ash has several compile-time options to allow for smaller size (by omitting lesser-used features that the complex scripts in LEAF tend to rely on). Are you sure you had everything enabled when you built the busybox ash and it still didn't work with Bering? As sure as I can be, (which may not mean a lot.), but then why do we have a separate implementation of ash, sed, halt, klogd, reboot, syslogd, watchdog, wget. I believe busybox is part of initrd.lrp Historical issues, in part (busybox didn't include ash, set, etc. when LRP was initially created). There are also compatability issues (for instance, sed is really 'put to the test' in several scripts that are part of LEAF, and I'm not sure the BB version of sed would work properly). But then, this is busybox 0.60.5 /* vi: set sw=4 ts=4: */ // This file defines the feature set to be compiled into busybox. // When you turn things off here, they won't be compiled in at all. // This file is parsed by sed. You MUST use single line comments. // i.e., //#define BB_BLAH // // // BusyBox Applications //#define BB_ADJTIMEX //#define BB_AR #define BB_ASH OK, you're compiling ash... snip //#define BB_TEST ...but you're *NOT* compiling test, which (as it's alter-ego '[' ) is what processes those conditional commands you were having problems with: definitely the bracket test ( if [ -x /tmp/foo ] ) syntax There should also be several ash options *OTHER* than the build switch you list above...I'm not sure where these would be in older busybox, but in the current CVS, it looks like they're in the shell directory as part of Config.in: http://www.busybox.net/cgi-bin/cvsweb/busybox/shell/Config.in?rev=1.16view=auto Note the recent addition of a 64-bit math support, which might be handy for LEAF... -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] inverting exit status
Chad Carr wrote:
Shell gurus,
Is there a reliable cross-platform way to write an inverted if
statement? Something like bash's:
if ! /usr/bin/false # with some other command, obviously
then
# do something true
else
# do something false
fi
Your assistance is greatly appreciated.
Just shuffle the then and else code around as appropriate for the
sense of the exit condition you're checking for.
If that's not an option (ie: you're only checking one case, and don't
want an empty then), you can do something like
if /usr/bin/false ; [ $? -ne 0 ] ; then
...
or more typically:
/usr/bin/false
if [ $? -ne 0 ] ; then
...
or even:
/usr/bin/false
retcode=$?
...
if [ $retcode -ne 0 ] ; then
...
If you're just trying to test for error codes or something, the
following might be handy:
abort() { ... }
# Call an abort procedure if command1 fails
/usr/bin/command1 || abort
# Run several commands if command2 fails
/usr/bin/command2 || { echo ERROR!!! ; exit ; }
HTH
--
Charles Steinkuehler
[EMAIL PROTECTED]
---
This SF.Net email sponsored by Black Hat Briefings Training.
Attend Black Hat Briefings Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS Nighly tar.bz2
Erich Titl wrote: Charles At 19:29 27.06.2004 -0500, Charles Steinkuehler wrote: ... [EMAIL PROTECTED] charles]$ crontab -l # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.29831 installed on Fri Aug 8 08:17:52 2003) # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $) # m h dom mon dow command # Grab extract latest CVS tarball from SourceForge 15 3 * * * links -source http://cvs.sourceforge.net/cvstarballs/leaf-cvsroot.tar.bz2 | bzcat | tar -x -C ~charles/leaf-cvs/ [EMAIL PROTECTED] charles]$ date Sun Jun 27 19:25:57 CDT 2004 Looks like 3:15 Central Time (-5 hours from UDT). Thanks, do you have an approximate time when this is finished? http://staff:[EMAIL PROTECTED]/gecko.newtek.com/gecko.newtek.com_eth0.html Looks like it's done before 4:00 (the big green spikes are the inbound data from grabbing the cvs tarball). -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS Nighly tar.bz2
Mike Noyes wrote: On Sat, 2004-06-26 at 19:17, K.-P. Kirchdrfer wrote: Am Samstag, 26. Juni 2004 19:40 schrieb Mike Noyes: wget http://cvs.sourceforge.net/cvstarballs/leaf-cvsroot.tar.bz2 Length: 959,993,540 [application/x-bzip2] Well, I need about three to four hours to download it; I can backup it twice or three times a week, if you want. But it will be only a backup, I can't offer services like Charles. K.-P., Understood. I just want more of our members, that are able, to backup our repository periodically. I'll see if I can rsync our repository from Charles through my dial-up connection. ugh That will take forever. If you want, I can burn a couple of CDs and mail an initial copy of the archive to you. Once you've got the initial 1.2G, keeping current with rsync shouldn't be too bad, even over dial-up. I'll extend the CD offer to anyone else who wants to mirror the CVS archive, as well. Just send a 'real-world' address to me off-list, if you want a copy. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS Nighly tar.bz2
Erich Titl wrote: Mike At 18:56 27.06.2004, Mike Noyes wrote: On Sun, 2004-06-27 at 09:00, Erich Titl wrote: Isn't there the possibility to use rsync at SF? The first download will be horrible, but afterwards daily backups should not be that bad. Erich, SourceForge doesn't make a CVS repository rsync service available. It's a service that is often requested, but the SF staff hasn't implemented it. The reasoning behind this decision was never made clear to me. Thanks for this info, I rsynced against Charles' repository this afternoon, will build a daily cron job as soon as I know at what time he is grabbing the new tarball. Charles would you mind sharing this info [EMAIL PROTECTED] charles]$ crontab -l # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/crontab.29831 installed on Fri Aug 8 08:17:52 2003) # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $) # m h dom mon dow command # Grab extract latest CVS tarball from SourceForge 15 3 * * * links -source http://cvs.sourceforge.net/cvstarballs/leaf-cvsroot.tar.bz2 | bzcat | tar -x -C ~charles/leaf-cvs/ [EMAIL PROTECTED] charles]$ date Sun Jun 27 19:25:57 CDT 2004 Looks like 3:15 Central Time (-5 hours from UDT). -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS Nighly tar.bz2
Mike Noyes wrote: Charles makes our repository available for rsync. rsync rsync.leaf-project.org:: leaf-cvsLEAF Project CVS Archives I have no idea how big the tarball is? K.-P., It is large. I'm not sure how big the tarball is (I decompress it as it's downloaded), but the resulting directory is about 1.2G: basic:/home/leaf# du -shc leaf-cvs/leaf/* 1.1Mleaf-cvs/leaf/CVSROOT 4.0kleaf-cvs/leaf/README,v 56k leaf-cvs/leaf/bering 804Mleaf-cvs/leaf/bin 228Mleaf-cvs/leaf/devel 7.0Mleaf-cvs/leaf/doc 32k leaf-cvs/leaf/etitl 64k leaf-cvs/leaf/leaf 4.0kleaf-cvs/leaf/modulename 154Mleaf-cvs/leaf/src 1.2Gtotal Feel free to rsync from my copy if you don't have enough bandwidth to download the nightly tarball (I run the tarball download and rsync server on a machine with a dedicated 100 MBit connection, then rsync my local mirror as I don't have the bandwidth here to support grabbing the full tarball daily). Another plus with rsync is you don't have to mirror the whole archive if you don't want. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Anyone in the Bay Area?
If anyone is in the Bay area (I know Mike N. is), it looks like I'm heading out to San Jose next week for the PCI Developers Conference (I design hardware as my 'day-job'): http://www.pcisig.com/events/devcon04/ I should be free in the evenings Monday Tuesday (14-15), to meet for dinner/drinks/conversation/whatever, if anyone's interested. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Re: 404 error on SF link to you (LEAF)
freeman wrote: Just to let you know... on page (Individual Developer Content): http://leaf.sourceforge.net/mod.php?mod=userpagemenu=14page_id=7 the link to 'your' folder: http://leaf.sourceforge.net/devel/cstein/ comes up 404. In peeking into: http://leaf.sourceforge.net/devel/ there seems to be none which is yours?! Thanks for your work on LEAF! Thanks for the notice. The LEAF site is in the process of being reorganized, and the /devel/ directory is going away. You can find my devel content on the SF site as a tarball in the downloads section, or on my website: http://lrp.steinkuehler.net/ Mike: Can you maybe add a notice that the website is changing and some links may be broken, the devel directories may be missing, etc? Thanks, -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New Website
Mike Noyes wrote: On Sun, 2004-05-16 at 08:47, Tom Eastep wrote: I changed the font (bold, small caps, and size) and bar size (padding) in this release. I gather the improvements weren't enough to make the nav bar stand out for you. Given that it is both dark and tiny, it does not stand out at all. Under Firefox on my 19 monitor, Bering uClibc is only about 2/3 wide and is almost unreadable. Lince *is* unreadable. Tom, Thanks for the feedback. :-) The readability of the nav bar may be related to the small caps, and fonts you have installed. Do you have the Bitstream Vera fonts installed? The larger size is readable for me (Mozilla 1.6 on 'doze), but the darker colors make the nav-bar seem 'disconnected' from the actual website, especially on the pages that still have the smaller text. I agree with KP that the Releases/Branches menu should return. I'll give this serious consideration. If it returns, the nav bar won't. I've been trying to eliminate redundant information. Everyone, Does anyone think the nav bar is usable? Is it worth working on further, or should I scrap it? Is it good enough to last a few months waiting for phpWebSite 0.9.4 to be released? Note: this theme is only temporary. We'll have a theme contest as soon as phpWebSite 0.9.4 is released. IMHO: If you want a nav-bar, it should pretty much duplicate the content on the main-menu (or perhaps a subset of main-menu entries), and match the style of the rest of the site (ie: currently black text on blue). I also think the releases/branches page (and main-menu item) should return. There's too much difference between branches to cover with a simple nav bar. For quick access, I think listing a few of the current popular distributions on the main page is fine (ie: perhaps a bering, bering-uClibc, and 'others' link, with others taking you to the releases page). -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562alloc_id=6184op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] modutils testing
K.-P. Kirchdörfer wrote: Hi; in latest linuxrc archiv from Charles are changes to modutils and modules loading, esp. if you use other medias as a single floppy. Again we find the bang commands from Dachstein. The Bering-uClibc team had a look at it and decided for next version to stay with the Bering way, unless this discussion brings up some new aspects and arguments. We saw the advantages of the Charles changes (it's flexibel to choose modules dir, the device (cdrom) is not always mounted). The advantages of the Bering way are from our view: - easier /etc/init.d/modutils code - easier from a user perspective (it's most automagic) - there is a link for the correct modules dir (lib/modules/2.4.24) In practice we found problems like the following: insmod throws an error with new modutils: /lib/modules/2.4.24. not found loading module Shure cosmetic, but can be confusing (solved in Bering with the correct link - either to cd or /lib/modules) I don't think the full version of insmod behaves this way, so IMHO this is a bug with busybox (likely stemming from the fact that I think BB is folding in modprobe functionality with insmod). If we need a symlink from /lib/modules/kernel-ver, IMHO it should only point to /lib/modules and not to the CD-ROM. Further do the bang commands only work during boot (when /etc/init.d/modutils is called) - afterwards the cd will be umounted and the cdrom/lib/modules/2.4.24 is not available anymore. This is problem for example with ipsec. During ipsec restart the module is unloaded and reloaded - of course that fails, if the device is not mounted. It's necessary to store ipsec.o in modules.lrp - but the the seamless and easy usage of a complete modules tarball on a mass storage is worthless. I run IPSec with no problems. Maybe we have not fully understood how to work with Charles chnaged modutils behaviour and the issues above can easily solved, maybe a few changes in Charles code and it's becoming the best of both worlds... IIRC, the IPSec scripts don't try to load any modules unless IPSec support isn't already enabled. I simply load all required modules at boot. If you really want, you can add new modules to /etc/modules at runtime and simple svi modutils to load them. I understand the difference of opinion here, but would like to make one request: - Can the Bering crew make sure any code that mounts (and leaves mounted) a CD-ROM or other device containing modules be restricted to the modules package? This would allow me (and anyone else who doesn't like permanently mounting the CD-ROM and symlinking to it) to replace just the modules package with a custom version. I really don't want to have to run a hacked version of initrd to leave the CD-ROM unmounted. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] modutils testing
Eric Spakman wrote: Hello Charles, snip I understand the difference of opinion here, but would like to make one request: - Can the Bering crew make sure any code that mounts (and leaves mounted) a CD-ROM or other device containing modules be restricted to the modules package? This would allow me (and anyone else who doesn't like permanently mounting the CD-ROM and symlinking to it) to replace just the modules package with a custom version. I really don't want to have to run a hacked version of initrd to leave the CD-ROM unmounted. Can you help us with a piece of code that can be added in modutils to make it possible to mount a device containing modules? Or do you have an other idea to keep the /lib/modules/kernel-version/ directory and mount/umount the modules device on request? I'm not clearly understanding what you want. If you want to dynamically mount something under user control, refer to the 'bang' command processing in my version of /etc/init.d/modutils. If you just want to mount a CD and leave it mounted (ie: 'classic' Bering behavior), just mount the device and make a symlink to it. The original Bering /linuxrc script looks for /lib/modules on all mounted PKGPATH devices. This functionality could be replicated in modutils, but I'd probably just test for the existance of /dev/cdrom (and maybe leave a commented definition in /etc/init.d/modutils so folks could enter a different device if they're booting off HDD, flash or some other media). I.e: something like (untested): # Change this if necessary MODDEV=/dev/cdrom MNTDIR=/cdmnt if [ -b $MODDEV ] mount -r $MODDEV $MNTDIR ln -s $MNTDIR/lib/modules /lib/modules/`uname -r` fi ...of course, there are lots of 'corner cases' to consider, such as: - What happens if you want to keep your HDD/Flash/whatever mounted at runtime (lots of reasons to do this, maybe to use for persistent logs, maybe to store web content for a small web server, etc). If you want to symlink /lib/modules/kernel somewhere else, the next time you reboot, your symlink will get clobbered by the auto-generation stuff, above. IMHO, the /lib/modules/kernel symlink, if present, should be part of the modules package (ie: not dynamically created), so users can point it somewhere else if desired. Also, to me this whole discussion is somewhat pointless. I would strongly argue that LEAF distributions can *NOT* be assumed to have the full modules heirarchy (including modules.dep, etc) that you would normally find on a full linux install. If there are programs that rely on this structure to be present, they will need to be modified to work with LEAF. This leaves 'large-format' LEAF systems, which may happen to have a full modules tree, as a special case of the simpler default system which only has /lib/modules/handful of files. I'm more interested in making the full modules directory easy to access in a similar method to the default accessing of files in /lib/modules than I am in trying to duplicate the full-blown modprobe functionality of a full disto. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] /linuxrc testing - round 2
Erich Titl wrote: snip No offense intended, I just felt that, if you go to the trouble of naming root.blk.mk explicitly after the type of device it builds, it would be logical to name the one that builds the character device nodes accordingly, e.g. root.chr.mk. None taken. The root.blk.mk name was just something I came up with trying to stick with the previous naming convention and keep the name short. At the time, I couldn't think of a better name. It just occured to me that perhaps the file should be named init.dev.mk. Anyone else like that better than root.blk.mk, or got a better suggestion? -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] /linuxrc testing - round 2
K.-P. Kirchdörfer wrote:
Charles;
I may have found another small problem:
firewall# lrpkg -i squid-2.lrp
Installing squid-2 ... cat: /var/lib/lrpkg//boot.fstype: No such file or
directory
Done.
I was told:
It could be a bug (from the lrpkg script):
echo $fn=-t `cat $lrpkgpath/boot.fstype` $d$lrpkgpath/backdisk
but boot.fstype is obsoleted with new linuxrc.
Any idea how to solve?
This is a known bug. The error message is effectively harmless, and
only appears when manually installing packages.
The result of this bug is you must manually specify the backup disk when
first backing up a package you manually installed (which you'd probably
have to do anyway), rather than having it default to the (no longer
existing) /dev/boot device.
Assuming using the first entry in pkgpath.disks in place of the missing
boot device/fs info is acceptable, the following will fix the problem:
echo $fn=-t `cat $lrpkgpath/boot.fstype` $d$lrpkgpath/backdisk
Replace with (all one line):
echo $fn=-t `sed -n '\:'$d':{s/^.* //;p;}' $lrpkgpath/pkgpath.disks`
$lrpkgpath/backdisk
A bit above this, the handling of $d needs to be tweaked as well:
Was:
if [ -z $2 ]; then
local d=`sed 's/.*boot=/\1/; s/[: ].*//' /proc/cmdline`
else
Replace with:
if [ -z $2 ]; then
local d=`sed -n '1{s/ .*$//;p;}' $lrpkgpath/pkgpath.disks`
else
The (unused) mount.boot procedure should be removed.
...and finally, the mount.back procedure should be tweaked:
Was:
if [ $dev = ]; then
mount -t `cat /var/lib/lrpkg/boot.fstype` /dev/boot $2
else
Replace with (between if/else is one line):
if [ $dev = ]; then
mount -t `sed -n '1{s/\([^ ].*\) \(.*\)$/\2 \1/;p;}'
$lrpkgpath/pkgpath.disks` $2
else
Of course, it wouldn't hurt to s:/var/lib/lrpkg:$lrpkgpath: on the whole
file, to remove any remaining absolute references to the package directory.
NOTE: Mods above have been briefly tested for correct shell quoting and
functionality, but no guarantee is expressed or implied!
--
Charles Steinkuehler
[EMAIL PROTECTED]
---
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] /linuxrc testing - round 2
Eric Spakman wrote: Do you want to go ahead and make these changes and release a new tar.gz file? Attached you will find the updated tar.gz Thanks to Eric, there's a new version of the updated linuxrc package available (posted on my website): http://lrp.steinkuehler.net/files/kernels/misc-stuff/linuxrc-2004-05-05.tgz IIRC, this fixes a few minor bugs, including: - /dev/null in root.dev.mk (should be in root.blk.mk even though it's not a block device, as it's used early in the init scripts). - A mistake in creating devlist and rdevlist that silent errors (umount and rmdir called with no arguments). The errors appear in linuxrc.err if VERBOSE is enabled. Eric: Any other bugs addressed in this update? -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] /linuxrc testing - round 2
Erich Titl wrote: Charles I looked at the new linuxrc, nice, modular, easier to maintain. At 22:14 05.05.2004, Charles Steinkuehler wrote: - /dev/null in root.dev.mk (should be in root.blk.mk even though it's not a block device, as it's used early in the init scripts). Would this not, for consistency's sake, rather go to a root.chr.mk file. Personally, I don't think so... ...if you're worried about a char device showing up in root.blk.mk, I'd either: - Just add a comment in root.blk.mk stating something like /dev/null is here with all the block devices because it's used early in the boot sequence (and in this file!). - If that's too much bloat or doesn't make you happy, you chould rename root.blk.mk something like root.bootdev.mk, root.init.mk or something else that coveys these devices are needed to boot-strap and find the leaf.cfg file -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] new linuxrc - small bug
K.-P. Kirchdörfer wrote: Hi, I built a CD with new linuxrc from Charles and found a problem using whitespace in PKGPATH: This works: PKGPATH=/dev/fd0:msdos,/dev/cdrom:iso9660 This one fails with: /dev/cdrom:iso9960 not found PKGPATH=/dev/fd0:msdos, /dev/cdrom:iso9660 Note it's the whitespace before /dev/cdrom. It may cause some headache for users... Charles, can you pls look into it? Are you using the latest version of my /linuxrc script? If so, did the setting of IFS (IFS='spacetabcr' near the top of the file) get corrupted when downloading/copying? Processing of PKGPATH is done with IFS set to $IFS, so any whitespace or commas should be ignored, as long as IFS is properly set (note this can be confusing, because if IFS is unset or null, the default is spacetabcr, which is what I explicitly set it to). I'm also confused as to why you'd ever see the particular error message you're reporting. The PKGPATH entries should be split at the colon before anything is done with them, so I could see an error about /dev/cdrom, but not about /dev/cdrom:iso9660. Please let me know exactly which /linuxrc file you're using... -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] new linuxrc - small bug
K.-P. Kirchdörfer wrote: Am Donnerstag, 29. April 2004 16:46 schrieb Charles Steinkuehler: K.-P. Kirchdörfer wrote: Hi, I built a CD with new linuxrc from Charles and found a problem using whitespace in PKGPATH: This works: PKGPATH=/dev/fd0:msdos,/dev/cdrom:iso9660 This one fails with: /dev/cdrom:iso9960 not found PKGPATH=/dev/fd0:msdos, /dev/cdrom:iso9660 Note it's the whitespace before /dev/cdrom. It may cause some headache for users... Charles, can you pls look into it? Are you using the latest version of my /linuxrc script? If so, did the I believe I do - linuxrc-2004-03-23 More questions: Where are you setting PKGPATH...in the kernel command line or in leaf.cfg? Can you provide the exact kernel command line and contents of leaf.cfg for me to test with here? Thanks -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id149alloc_id66op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Dachstein-CD - Bering ???
Michael D Schleif wrote: I have noticed in recent months that Charles is migrating from DCD to Bering, and that migration has entailed some sleight-of-hand over straight Bering. Charles, have you published your DCD-Bering ``distribution''? What do you think? Well, I'm not much of a 'magician', but I am upgrading to Bering (at least on my local firewall...I've still got a bunch (6+) of Dachstein based machines in production at various other locations). I have not yet released a version of my Bering-CD for a few reasons: - I want to make sure there are no additional changed required to my new /linuxrc mods - I haven't yet tried the 2.4.24 kernel I want to upgrade to that I built from the uClibc branch but patched with the Bering version of IPSec - I haven't fixed everything related to removing /dev/boot (ie: packaging scripts), but I don't think there are any problems from this other than harmless warnings when manually installing packages. - General lack of time While I am running a 'tweaked' Bering, the main things I modified are available from my posts to leaf-devel. Other than that, I'm running Shorewall 1.4.10c (direct from the Shorewall site, unmodified for 'out-of-the-box' masquerading), and a bunch of packages from DCD (with newer ssh bering versions of IPSec). I can post a 'release-candidate' iso of what I'm currently running in production online, if anyone's interested. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Bering-CD Trial Version
Due to 'popular demand' (OK, one person asked :), I have posted my work-in-progress Bering-CD version online for download. You may grab the ISO image and browse the CD contents at the following URLs: Fast co-located server: http://lrp2.steinkuehler.net/files/diskimages/Bering-CD/ Slow(ish) server behind a 768K SDSL: http://lrp.steinkuehler.net/files/diskimages/Bering-CD/ See the readme file for a quickly hacked together list of what's on the CD, where I got it from, and what I changed from 'stock' Bering-1.2. There is also a readme.cd file in the cd contents/ directory, which is mainly a hacked version of the Dachstein-CD readme (covers linux mkisofs command required to build a new CD and the Dachstein/Bering packaging extentions). Key changes from stock Bering-1.2: - New /linuxrc scripts - Modified module loading script - Shorewall package is 'raw' package directly from shorewall maintainers (ie: no pre-configuration for typicaly SOHO firewall). For anyone used to Dachstein-CD, this will be very familiar. Read up on the /linuxrc mods (see leaf-devel archives, circa: March 23, 2004 and prior), crawl through the execllent shorewall documentation, and read up on the Bering documentation as required. HELP WANTED: I have not fully identified where all the packages came from (I took over this project from a friend, who couldn't manage to make a bootable Bering CD). Help in identifying versions and/or replacing any packages in the contents list with more recent versions would be GREATLY APPRECIATED! I also want to switch to a kernel with modularized ip_conntrack and ip_tables (allowing me to adjust paramters that are otherwise only settable at kernel compile time). I have a 2.4.24 kernel (based on bering-uClibc's kernel) compiled, but have not tested it. Given the recent thread on updating IPSec (which would also need a new kernel), perhaps it's best to combine these two items for the CD-ROM. Maybe someone will even build the new kernel and IPSec, and I won't have to (hint-hint ;-). Sorry for the general lack of release-specific documentation, but with twins I don't have the time I did before to wrap up all the loose ends. DISCLAIMER: There are probably major problems with this CD, but it's been working fine for me for about a month. If you have problems with the CD, I'll cheerefully refund everything you paid me for it. :-) NOTE: Due to the kernel issue, this version doesn't even get release-candidate status (ie: at least 1 major known issue), but it really is working fine, and should work just as well as the currently released Bering-1.2 (which also doesn't allow setting things like ip_conntrack hash table size). -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149alloc_id=8166op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] [Fwd: Re: Mike Noyes]
Mike Noyes wrote: On Tue, 2004-04-13 at 04:09, Charles Steinkuehler wrote: Mike Noyes has been in a bicycle accident (see message below). If I get any more details, I'll let everyone know. Everyone, Sorry for the delay on the website. I just got back from the hospital today. I dot know what problems I'll have, but I intend to start working on our website ASAP. Apparently I got lucky with some good neurosurgeons. They drilled a hole in my brain to relive pressure. Without this they said I was gone. All this from riding head first into a stationary garbage truck at full speed. Not the smartest thing I've done in my life. Glad to hear you're OK! I've had a few bike accidents myself, with the worst knocking me out for about 5 minutes and sending me to the hospital to get my head scanned (yes, that's the only reason I've ever had to have my head examined!). The upside was I was pretty much limp when I hit the ground (my head hit first), so I had very little road rash. Remember to keep the rubber side down, and worry about getting better, not the website! -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Feature Request: Shorewall 2.0 LocalConfDir
Tom Eastep wrote: Erich Titl wrote: As I suggested some time ago could this be solved by falling back to the default shorewall.conf file if the file pointed to by CONFIG_PATH did not exist? Let say that for LEAF, the CONFIG_PATH is: /etc/shorewalluser:/etc/shorewall:/usr/share/shorewall Shorewall continues to release its configuration files into /etc/shorewall. a) It seems like the entries in /var/lib/lrcfg/shorwall.conf need to point to /etc/shorewalluser. b) Shorewall can't release files into /etc/shorewalluser because then a Shorewall upgrade will overwrite those files. So how does /etc/shorewalluser get populated initially? I'm not sure I'm following along completely, but this sounds a lot like the general problem encountered when trying to update any *.lrp package: the configuration files are in the same package as the application, and the whole filesystem is re-created from scratch every boot (so there's no remembering the configuration data from a previously installed package version). I know of two ways to work around this: 1) Put configuration data in a seperate package, ie: swconf.lrp would 'own' files in /etc/shorewalluser (or even /etc/shorewall), so replacing shorewall.lrp with a new version wouldn't overwrite existing configuration data. 2) Use partial backups (implemented in Dachstein and Bering). This isn't a real graceful solution for someone with a single boot disk, but can work well if you're running from CD, HDD, or can otherwise configure two (or more) package repositories. One holds the unconfiugred distribution packages (the CDROM in my case), while the other holds partial backups (typically just the configuration data) that get loaded on top of the default configuration files provided with the base package. There is a new package file in /var/lib/lrpkg (package.local) which defines which files are to be included or excluded when doing a partial backup. If this file doesn't exist, the scripts default to putting any files in /etc or /var/lib/lrpkg that are defined in the package.list file in the partial backup. #2 works really well for CDROM based systems (or systems that can configure two package storage locations). To upgrade shorewall, ssh, or whatever, I simply burn a new CD containing the updated packages, insert it into my firewall (with it's single configuration floppy), and reboot. Excuse the interruption if I'm not correctly understanding your problem...I haven't been closely monitoring this thread. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] Feature Request: Shorewall 2.0 LocalConfDir
Tom Eastep wrote: Erich Titl wrote: Does it have to be populated? I think so if the /var/lib/lrpkg/shorwall.conf file points to it. If Shorewall has a fallback set up which would be overridden by user configuration data then Shorewall would have a default configuration initially unless there is a user configuration file present. The shorewall.list would include the user configuration file but initially this file would be missing in the shorewall.lrp file. Loading a new release would thus not overwrite user configuration data. As soon as this configuration is saved then the newly created shorewall.lrp would contain the user configuration data valid at save time and therefore hold the complete configuration. Is this feasible? I think that Charles's suggestion about using two packages makes this a bit more friendly. The main problem that I see with that approach is that it doesn't allow any way for me to add a new config file in the future and have it reflected in the Shorewall configuration menu. Are you referring to the lrcfg configuration menu, created from the package.conf files in /var/lib/lrpkg? If so, I think you can 'cheat', within limits. If both the main and configuration shorewall packages are distributed as a unit and always used as a pair (except maybe by folks who really know what they're doing), I don't think there would be a problem with making the *.conf file part of the main shorewall package, rather than the config package. While it might seem odd to have the package.conf file in a different package than the actual files it's setup to edit, it really makes sense when you consider the second package is for actual user-modified configuration files, rather than being a true stand-alone package. The package.conf file is *NOT* a user-modified config file, so putting it in the main shorewall package seems reasonable. Essentially, this is doing with two differently named packages what I do with two identically named packages from different sources: Splitting the modifiable configuration files and 'static' content. I've even thought of making a packaging system that would do this sort of thing automatically, using for example package.lrp for the released package, and package.cfg for the user-modified files. This would only take a very slight re-working of my current backup scripts to implement. I have not yet done anything like this because: - I don't really need it personally (the current scripts work well for CD-ROM based systems, which is mainly what I run). - I don't have a lot of time for development (8 month old twins!) - I don't want to pull the rug out from under the new configuration scheme and hopefully a more full-featured packaging system. On the other hand, support for package.cfg files would be very easy to add (maybe a couple hours of scripting, since the bulk of the support is already in place), and would be very handy for folks running on flash, hdd, or similar (I'm not sure if the floppy folks would have enough room for many extra files, especially if partial/.cfg backups of /etc include pretty much the whole directory as they do now (another 20+ KB)). -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] Customizing Bering kernel
I'm trying to build a new Bering kernel (so I can load ip_conntrack as a module and use a larger hash table size), and have a few questions: - Is the procedure in the README.txt file (link below) the latest and greatest? This is the only place I've actually found a .config file... http://leaf.sourceforge.net/devel/jnilo/bering/latest/development/kernel/README.txt - Is the Bering-2.4.20.config in the above directory the proper .config file for the current Bering kernel? - I tried compiling from the patched kernel source tree available in the SF releases area, but it doesn't look like that source code has the IPSec patches. Is that correct? Thanks, -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] /linuxrc testing - round 2
The next version of /linuxrc is ready for testing. Lots of changes in this version (not just to linuxrc)...see the changelogs and README in the tarball for full details: http://lrp2.steinkuehler.net/files/kernels/misc-stuff/linuxrc-2004-03-23.tgz This version requires the use of a 'split' root.dev.mk file (note I renamed root.block.dev provided by Eric Spakman to root.blk.dev, and re-worked the floppy disk device generation code to save space). I have also included the modutils that I'm running (a merged version of Bering and Dachstein), along with a modules file that includes comments on using some of the available options. IMHO, modifying the Bering 'find' feature to limit itself to a particular directory, and error if it finds more than one version of a module are required, as it seems important to be able to unambiguously determine exactly which module is getting installed (I didn't even realize there were two different versions of the tulip driver provided with Bering until I started testing this code!). I also think the 'bang' commands to mount/unmount/chdir are a better solution than blindly mounting /dev/cdrom if it exists and looking for modules there (while that would work for me, it seems pretty inflexible for those running off flash or HDD). Feel free to incorperate some or all of these changes into Bering or ignore, as you see fit (but I'm going to continue using them!). NOTE: I have not yet done the mods to the backup scripts in /usr/sbin. I have personally been running with the 'broken' code, and other than a harmless error when manually installing packages, the worst side effect is you have to specify the package destination for a manually installed package prior to backing it up (which is generally required regardless, so this isn't a big deal). I will get this fixed when I get time, but the functional stuff has been getting priority. linuxrc changelog and modutils changelog details follow sig. -- Charles Steinkuehler [EMAIL PROTECTED] [EMAIL PROTECTED] linuxrc-2004-03-23]# cat changelog 2004-03-23 Fixed extraction of FILESYSTEMS from /proc root.dev.mk split into root.dev.mk and root.block.mk by Eric Spakman root.block.mk renamed root.blk.mk, and floppy device generation folded into for/while loop to save space /dev generation modified to use dual-scripts Fixed parsing of LEAFCFG if optional fstype is omitted Unmount all package path devices (including CDROM) 2004-03-12 snip [EMAIL PROTECTED] linuxrc-2004-03-23]# cat changelog.modutils 2004-03-23 Merged Dachstein (bang commands) and Bering (locate modules with find) features into one script Applied patch for LLADDR support bang command (to set physical MAC addr) Removed automatic mounting of CD-ROM, if present (should be done explicitly via '! mount' ) Modified Bering 'find' feature: - Limited search to current directory and below - Error reported if more than one module matches module name - Removed name mangling code --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New Website
Mike Noyes wrote: Website Update Status: I'm about 50-60% done with the upgrade. I'm not sure how long the remainder of the upgrade will take. I'll keep everyone posted on my progress. Thanks for being patient. Thanks for all your hard work on this Mike! -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
Eric Spakman wrote: Hello Charles, Files like mount.boot, boot.fstype and /dev/boot are removed (which is great btw), but they are used in some of the lrcfg/lrpkg scripts AFAIK. So maybe some of these scripts needs some changes too. I don't think the Dachstein package backup scripts use these anymore (part of the upgrade to supporting multiple devices), so Bering shouldn't be either. I have verified I can properly backup packages, but I have not made an exhaustive search for anything that might reference the 'boot' files. There are some traces of boot.fstype and /dev/boot left in POSIXness.linuxrouter (both Dachstein-1.0.2 and Bering). I just looked at these, and the use of the boot= kernel command line setting, boot.fstype and /dev/boot are not real significant in POSIXNESS.linuxrouter. The boot= setting and boot.fstype are used as 'defaults' for populating the backdisk file when manually installing a package after the system has come up (note is is also possible to optionally specify a backup device when manually installing a package). The /dev/boot symlink and boot.fstype are used in the mount.boot procedure (uncalled by any other POSIXness or lrcfg script), and by the mount.back procedure (as a fallback if the newer backdisk file is not present). There are at least three ways to deal with this: 1) Remove the references to these files from POSIXNESS.linuxrouter, replacing them with references to the newer files (and likely get rid of the mount.boot procedure entirely). 2) Create the files in linuxrc, using the first PKGPATH= device (instead of the depricated boot= device). 3) Ignore the problem with manually adding packages once the system is up and running. :) Any preference? -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
Eric Spakman wrote: Charles, snip There are at least three ways to deal with this: 1) Remove the references to these files from POSIXNESS.linuxrouter, replacing them with references to the newer files (and likely get rid of the mount.boot procedure entirely). 2) Create the files in linuxrc, using the first PKGPATH= device (instead of the depricated boot= device). 3) Ignore the problem with manually adding packages once the system is up and running. :) Any preference? My preference would be option 1, although option 3 also appeals to me :) :) OK, then it's not a linuxrc problem. Should I go ahead and make the mods to POSIXness? If so, are the Bering versions checked in to CVS anywhere (I've got the Dachstein versions in CVS). Are there any differences between the Bering and the Bering-uClibc versions of POSIXness? P.s. Any progression with the rewrite of linuxrc, need any help? It looks like the linuxrc rewrite is pretty much done. I've made a minor tweak or two since the version I posted (removed /bin/bash from initrd.lrp to prevent conflicts when adding a real bash shell, and removed the code that leaves the CD-ROM mounted and creates the /lib/modules symlink from linuxrc). The biggest help at this point would be for others to test the new linuxrc, make sure it works for them, and think about any other features that might need to be added to linuxrc or leaf.cfg. Further work that looks like it needs to get done, but isn't really directly related to just linuxrc: - Merge Dachstein and Bering modutils code. Bang commands from Dachstein are necessary (IMHO) for running cleanly off a CD-ROM, and I like the 'find' feature of the Bering modutils (as long as it's limited to searching only the current directory and below, rather than the whole root filesystem). Of course, the Bering development team might have a different view of this, and want to keep the current modutils. - Add the /bin/bash - /bin/ash symlink to root, or (optionally) create it in /linuxrc (or sometime prior to loading add-on packages, if package loading gets moved to init). - Determine a mechanism for loading packages at init time, rather than in /linuxrc. There are a lot of options here, including adding a couple new rcS.d scripts, creating an entirely new runlevel (maybe rcL.d?) that runs before rcS.d, etc. I'm not sure there's a universal solution to this problem...since LEAF is based on a ramdisk that is populated at boot time, there's a natural conflict between wanting to mount additional devices 'normally' (ie /etc/fstab or similar), and needing to have some directories mounted prior to package installation, since we're rebuilding the entire filesystem every time we boot. I think the package installation issue needs some discussion between the developers to determine what would work well, and the first two issues are minor enough to be ignored until one of the Bering branches switches to the new linuxrc code (I can work around these issues pretty easily for now, and convert to the 'real' Bering way of doing things once there's an official release). -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
Erich Titl wrote: snip 3) Ignore the problem with manually adding packages once the system is up and running. :) or insert backuptype NONE if not specified at lrpkg -i I looked into linuxrc myself and found that it does not use lrpkg to install packages. It is not a big deal but to me this is not extremely consistent. linuxrc doesn't use lrpkg -i to install packages because at boot time the PKGPATH variable is used to install packages from potentially multiple places. The intent of lrpkg -i is to allow manual installation of a specific *.lrp package file once the system is running. While I could be convinced extending lrpkg to deal with the PKGPATH setting would be worthwhile, I think this would mainly be of benifit if package loading is broken into two (or more) steps, with only a limited number of core packages being installed by linuxrc, with the rest being installed by an /etc/init.d script. Also note that I don't believe the POSIXness scripts (lrpkg included) are available currently in the initial ramdisk, but are in root.lrp. -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] New linuxrc mods ready for testing
re: mounting various partitions in /linuxrc I have been thinking more about this issue, and have come to the following conclusion (mantra). Repeat after me: ... linuxrc IS NOT init ... ... linuxrc IS NOT init ... ... linuxrc IS NOT init ... The sole purpose of linuxrc (IMHO) is to build enough of a filesystem so init can run and bring up the system proper. linuxrc is not the place to be mounting additional filesystems that are not required for init to run. Any non-volitle partitions can be mounted through the normal init and rcS.d methods. Note that I am unaware of a single distribution other than Bering that mounts /tmp and /var/log as seperate partitions prior to launching init (although obviously it's possible to mount most anything with the disto of your choice once init is up and running). Even Dachstein mounted /var/log via /etc/init.d scripts (ramdisk.mk and ramdisk.pkg). IMHO, while we're sort of changing everything, what should really happen is the following: - The creation and mounting of /var/log and /tmp should be removed from linuxrc and migrated to general purpose init script(s). - Installation of all but the very core packages (root.lrp, etc.lrp, ???) should be delegated to another new init script that executes once the full filesystem is mounted (avoiding the problem I had with Dachstein of trying to populate a newly mounted ramdisk with data that really belongs in a normal LRP file which was getting installed by linuxrc). - There should still be some procedural 'hooks' added to allow leaf.cfg to run code after the root ramdisk is created. While I don't have a need for this functionality at the moment, it's not hard to add and won't take a lot of space. - Support should be added for either *nix or DOS style EOLs in leaf.cfg Thoughts? -- Charles Steinkuehler [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
