Re: [leaf-devel] CVS
Am 30.01.2012 21:31, schrieb Mike Noyes: Everyone, I backed up our old CVS repository, uploaded it to the SF FRS, truncated CVS with adminrepo, hid our leaf-cvs-commits mailing list (delete?), and disabled CVS. Revision *1.4* - (*show annotations* http://leaf.cvs.sourceforge.net/viewvc/leaf/README?annotate=1.4) (*download* http://leaf.cvs.sourceforge.net/viewvc/leaf/README?revision=1.4) /Mon Jan 30 20:24:04 2012 UTC/ (70 seconds ago) by /mhnoyes/ Branch: *MAIN* CVS Tags: *HEAD* Changes since *1.3: +10 -57 lines* CVS archived, published in FRS, and truncated. 1 REPOSITORY MOVED TO GIT 2 3 Git 4 http://leaf.git.sourceforge.net/ 5 https://sourceforge.net/mailarchive/forum.php?forum_name=leaf-git-commits 6 https://sourceforge.net/apps/trac/sourceforge/wiki/Git 7 8 CVS Archive 9 /home/frs/project/l/le/leaf/OldFiles/leaf-cvs.tar.gz 10SHA1: 2502a994c4c0b2ca92b1ac186a08ddacca5e2c1b 11MD5: 5bbd3f3ba7b0bd4d1ccb54fb7936c654 12 Mike; this move raises are lot problems. the cvs tarball is not downloadable on FRS - at least yestersday, when I checked the last time. Developer files are lost: http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Bering-uClibc_4.x_-_User_Guide_-_Advanced_Topics_-_Setting_Up_Zeroconf_Networking (search for Implementing mDNS using Avahi) http://leaf.sourceforge.net/devel/ and the page of packages for Bering-uClibc 3.1 points also to nowhere. http://leaf.sourceforge.net/bering-uclibc/index.php?module=pagemasterPAGE_user_op=view_pagePAGE_id=12MMN_position=32:32 I can fix the last one with movingthe 3.1 packages to git, for the others pages we can offer git branches, but the webpages needs to be reworked accordingly. kp -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] CVS
Everyone, I backed up our old CVS repository, uploaded it to the SF FRS, truncated CVS with adminrepo, hid our leaf-cvs-commits mailing list (delete?), and disabled CVS. Revision *1.4* - (*show annotations* http://leaf.cvs.sourceforge.net/viewvc/leaf/README?annotate=1.4) (*download* http://leaf.cvs.sourceforge.net/viewvc/leaf/README?revision=1.4) /Mon Jan 30 20:24:04 2012 UTC/ (70 seconds ago) by /mhnoyes/ Branch: *MAIN* CVS Tags: *HEAD* Changes since *1.3: +10 -57 lines* CVS archived, published in FRS, and truncated. 1 REPOSITORY MOVED TO GIT 2 3 Git 4 http://leaf.git.sourceforge.net/ 5 https://sourceforge.net/mailarchive/forum.php?forum_name=leaf-git-commits 6 https://sourceforge.net/apps/trac/sourceforge/wiki/Git 7 8 CVS Archive 9 /home/frs/project/l/le/leaf/OldFiles/leaf-cvs.tar.gz 10 SHA1: 2502a994c4c0b2ca92b1ac186a08ddacca5e2c1b 11 MD5: 5bbd3f3ba7b0bd4d1ccb54fb7936c654 12 -- Mike Noyes http://sourceforge.net/users/mhnoyes https://profiles.google.com/mhnoyes -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ 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] cvs cleanup
Am Dienstag, 28. Dezember 2010, um 23:36:10 schrieb KP Kirchdoerfer: Am Dienstag, 30. November 2010, 15:55:23 schrieb KP Kirchdoerfer: Am Samstag, 27. November 2010, 22:30:13 schrieb davidMbrooke: On Sat, 2010-11-27 at 15:58 +, davidMbrooke wrote: On Sat, 2010-11-27 at 07:28 -0800, Mike Noyes wrote: On Fri, 2010-11-26 at 08:07 -0800, Mike Noyes wrote: On Thu, 2010-11-25 at 00:20 +0100, KP Kirchdoerfer wrote: Am Dienstag, 23. November 2010, 20:38:07 schrieb KP Kirchdoerfer: What cvs cleanup is pending? I'd like to take care of all of it at one time with adminrepo. Pending http://leaf.cvs.sourceforge.net/leaf/ Removal/Deletion buildtool.cfg/ r1000/ Hi Mike, A few requests to delete directories from CVS have been posted to this list of late: Erich: src/bering-uclibc4/source/openswan/openswan-2.6.31 Me: src/bering-uclibc4/buildtool/image/Bering-uClibc-isolinux-std Me: src/bering-uclibc4/buildtool/image/Bering-uClibc-syslinux-std ...and now two more while you are at it: src/bering-uclibc4/buildtool/tools/image/fd/ src/bering-uclibc4/buildtool/tools/image/iso/ Mike; found another one src/bering-uclibc4/source/shorewall-shell/ Mike; any news about cvs cleanup? best wishes for 2011! kp Mike; I guess this is still a pending request. Any timeframe you can take care of it? kp -- 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
[leaf-devel] cvs cleanup
Am Dienstag, 30. November 2010, 15:55:23 schrieb KP Kirchdoerfer: Am Samstag, 27. November 2010, 22:30:13 schrieb davidMbrooke: On Sat, 2010-11-27 at 15:58 +, davidMbrooke wrote: On Sat, 2010-11-27 at 07:28 -0800, Mike Noyes wrote: On Fri, 2010-11-26 at 08:07 -0800, Mike Noyes wrote: On Thu, 2010-11-25 at 00:20 +0100, KP Kirchdoerfer wrote: Am Dienstag, 23. November 2010, 20:38:07 schrieb KP Kirchdoerfer: What cvs cleanup is pending? I'd like to take care of all of it at one time with adminrepo. Pending http://leaf.cvs.sourceforge.net/leaf/ Removal/Deletion buildtool.cfg/ r1000/ Hi Mike, A few requests to delete directories from CVS have been posted to this list of late: Erich: src/bering-uclibc4/source/openswan/openswan-2.6.31 Me: src/bering-uclibc4/buildtool/image/Bering-uClibc-isolinux-std Me: src/bering-uclibc4/buildtool/image/Bering-uClibc-syslinux-std ...and now two more while you are at it: src/bering-uclibc4/buildtool/tools/image/fd/ src/bering-uclibc4/buildtool/tools/image/iso/ Mike; found another one src/bering-uclibc4/source/shorewall-shell/ Mike; any news about cvs cleanup? best wishes for 2011! kp -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] cvs structure
On Mon, 2010-11-22 at 23:11 +0100, KP Kirchdoerfer wrote: Am Montag, 1. November 2010, 22:04:59 schrieb davidMbrooke: On Mon, 2010-11-01 at 21:32 +0100, KP Kirchdoerfer wrote: David; Am Sonntag, 31. Oktober 2010, 22:09:54 schrieb davidMbrooke: On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote: Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew: Ok; I propose: - just core and contrib repository (names are not fixed), testing isn't needed - we can also put packages in contrib which we consider for testing or provided as-is. Just to make sure I understand 100%, some examples: etc.lrp: Certainly part of core. No debate. Maybe this also debatable :) The most radical way (besides opening it all) would be just to define core just as buildenv and buildtool itself. Which is the bare minimum to build packages on a definded base (uclibc version). Though even that raises pb's. What if a user wants to provide a complete new kernel arch? And in the developer guidelines and policies we asked to provide modules not in the package, but with modules.tgz During 2.x and 3.x we thought about core mainly as packages that are provided on the floppy image - but as that donÄt exist any longer..., and it doesn't work very well in the long term. asterisk.lrp: Certainly part of contrib (only if it is fixed?) aiccu.lrp: Not part of core, since only relevant to some users, but you (kp) and I (dMb) would be willing to upgrade, test, repair etc. Both belongs shurely to contrib Should we distinguish supported contrib from unsupported contrib? Something like primary (instead of core - approx 10 packages that EVERY user will need), secondary (tested and supported, but not core), then contrib for the others? Hmm, the idea of approx 10 packages that every users need is a good one. Your secondary and contrib maybe rephrased as packages and testing? (primary/packages/testing) kp Hi kp, To me, testing implies a temporary state: will move somewhere else when testing is successful, which isn't quite what I had in mind. A package in contrib will always stay in contrib... In terms of packages (i.e. ignoring buildenv and buildtool) then core or primary is: - kernel (OK, not really a package as such...) - initrd - root - etc - modules Would a system actually run with just this list (+ moddb + configdb)? Then there are mainstream add-on packages: - iptables - shorwall - Hence also libm, perl - ip6tables - shorwall6 - dropbear - dhcpcd - dnsmasq - mhttpd - webconf - A few more perhaps? Others would be contrib. So maybe 3 categories: core, mainstream, contrib ??? dMb David; I've slept and thought over this the past weeks. In the meantime Erich has been added to the list of developers being able to commit and it worked out pretty well. I've made the experience in the past that too restrictive settings are more a loss than a win. So I think we may go with a more open-minded and easy-to-understand rule. Current cvs should be open to every LEAF developers who asks for write permission - assuming everyone is aware of the responsibility having write permissions. A contrib section should be added with write permissions for everyone who has been added as LEAF developer. Sounds easy and effetive to me :) kp Hi kp, I like to keep things simple so sure, let's go with what you propose. In terms of write access there would be no difference between my core and mainstream anyway. (Only difference would have been the level of support and testing, and the intent to widen the development team.) dMb -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] cvs structure
Am Montag, 1. November 2010, 22:04:59 schrieb davidMbrooke: On Mon, 2010-11-01 at 21:32 +0100, KP Kirchdoerfer wrote: David; Am Sonntag, 31. Oktober 2010, 22:09:54 schrieb davidMbrooke: On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote: Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew: Ok; I propose: - just core and contrib repository (names are not fixed), testing isn't needed - we can also put packages in contrib which we consider for testing or provided as-is. Just to make sure I understand 100%, some examples: etc.lrp: Certainly part of core. No debate. Maybe this also debatable :) The most radical way (besides opening it all) would be just to define core just as buildenv and buildtool itself. Which is the bare minimum to build packages on a definded base (uclibc version). Though even that raises pb's. What if a user wants to provide a complete new kernel arch? And in the developer guidelines and policies we asked to provide modules not in the package, but with modules.tgz During 2.x and 3.x we thought about core mainly as packages that are provided on the floppy image - but as that donÄt exist any longer..., and it doesn't work very well in the long term. asterisk.lrp: Certainly part of contrib (only if it is fixed?) aiccu.lrp: Not part of core, since only relevant to some users, but you (kp) and I (dMb) would be willing to upgrade, test, repair etc. Both belongs shurely to contrib Should we distinguish supported contrib from unsupported contrib? Something like primary (instead of core - approx 10 packages that EVERY user will need), secondary (tested and supported, but not core), then contrib for the others? Hmm, the idea of approx 10 packages that every users need is a good one. Your secondary and contrib maybe rephrased as packages and testing? (primary/packages/testing) kp Hi kp, To me, testing implies a temporary state: will move somewhere else when testing is successful, which isn't quite what I had in mind. A package in contrib will always stay in contrib... In terms of packages (i.e. ignoring buildenv and buildtool) then core or primary is: - kernel (OK, not really a package as such...) - initrd - root - etc - modules Would a system actually run with just this list (+ moddb + configdb)? Then there are mainstream add-on packages: - iptables - shorwall - Hence also libm, perl - ip6tables - shorwall6 - dropbear - dhcpcd - dnsmasq - mhttpd - webconf - A few more perhaps? Others would be contrib. So maybe 3 categories: core, mainstream, contrib ??? dMb David; I've slept and thought over this the past weeks. In the meantime Erich has been added to the list of developers being able to commit and it worked out pretty well. I've made the experience in the past that too restrictive settings are more a loss than a win. So I think we may go with a more open-minded and easy-to-understand rule. Current cvs should be open to every LEAF developers who asks for write permission - assuming everyone is aware of the responsibility having write permissions. A contrib section should be added with write permissions for everyone who has been added as LEAF developer. Sounds easy and effetive to me :) kp -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] cvs structure
On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote: -snip- Ok; I propose: - just core and contrib repository (names are not fixed), testing isn't needed - we can also put packages in contrib which we consider for testing or provided as-is. - lrp's and sources are required for both to be inline with the SF requirements. About write permissons: contrib should be open to all leaf-developers, what about the core? We may give write permissions to core by request... Everyone, Current CVSROOT/avail global access. Modify as necessary. # Global access for all project members avail||bin/packages/glibc-2.0 avail||bin/packages/glibc-2.1 avail||bin/packages/glibc-2.2 avail||bin/packages/nolibc avail||bin/packages/uclibc-0.9/20/contrib avail||bin/packages/uclibc-0.9/28/contrib avail||doc/docmanager avail||doc/howto avail||doc/man avail||doc/network_diagrams avail||src/bering-uclibc/contrib opinions? -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, sourceforge/sitedocs -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] cvs structure
David; Am Sonntag, 31. Oktober 2010, 22:09:54 schrieb davidMbrooke: On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote: Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew: Ok; I propose: - just core and contrib repository (names are not fixed), testing isn't needed - we can also put packages in contrib which we consider for testing or provided as-is. Just to make sure I understand 100%, some examples: etc.lrp: Certainly part of core. No debate. Maybe this also debatable :) The most radical way (besides opening it all) would be just to define core just as buildenv and buildtool itself. Which is the bare minimum to build packages on a definded base (uclibc version). Though even that raises pb's. What if a user wants to provide a complete new kernel arch? And in the developer guidelines and policies we asked to provide modules not in the package, but with modules.tgz During 2.x and 3.x we thought about core mainly as packages that are provided on the floppy image - but as that donÄt exist any longer..., and it doesn't work very well in the long term. asterisk.lrp: Certainly part of contrib (only if it is fixed?) aiccu.lrp: Not part of core, since only relevant to some users, but you (kp) and I (dMb) would be willing to upgrade, test, repair etc. Both belongs shurely to contrib Should we distinguish supported contrib from unsupported contrib? Something like primary (instead of core - approx 10 packages that EVERY user will need), secondary (tested and supported, but not core), then contrib for the others? Hmm, the idea of approx 10 packages that every users need is a good one. Your secondary and contrib maybe rephrased as packages and testing? (primary/packages/testing) kp -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] cvs structure
On Mon, 2010-11-01 at 21:32 +0100, KP Kirchdoerfer wrote: David; Am Sonntag, 31. Oktober 2010, 22:09:54 schrieb davidMbrooke: On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote: Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew: Ok; I propose: - just core and contrib repository (names are not fixed), testing isn't needed - we can also put packages in contrib which we consider for testing or provided as-is. Just to make sure I understand 100%, some examples: etc.lrp: Certainly part of core. No debate. Maybe this also debatable :) The most radical way (besides opening it all) would be just to define core just as buildenv and buildtool itself. Which is the bare minimum to build packages on a definded base (uclibc version). Though even that raises pb's. What if a user wants to provide a complete new kernel arch? And in the developer guidelines and policies we asked to provide modules not in the package, but with modules.tgz During 2.x and 3.x we thought about core mainly as packages that are provided on the floppy image - but as that donÄt exist any longer..., and it doesn't work very well in the long term. asterisk.lrp: Certainly part of contrib (only if it is fixed?) aiccu.lrp: Not part of core, since only relevant to some users, but you (kp) and I (dMb) would be willing to upgrade, test, repair etc. Both belongs shurely to contrib Should we distinguish supported contrib from unsupported contrib? Something like primary (instead of core - approx 10 packages that EVERY user will need), secondary (tested and supported, but not core), then contrib for the others? Hmm, the idea of approx 10 packages that every users need is a good one. Your secondary and contrib maybe rephrased as packages and testing? (primary/packages/testing) kp Hi kp, To me, testing implies a temporary state: will move somewhere else when testing is successful, which isn't quite what I had in mind. A package in contrib will always stay in contrib... In terms of packages (i.e. ignoring buildenv and buildtool) then core or primary is: - kernel (OK, not really a package as such...) - initrd - root - etc - modules Would a system actually run with just this list (+ moddb + configdb)? Then there are mainstream add-on packages: - iptables - shorwall - Hence also libm, perl - ip6tables - shorwall6 - dropbear - dhcpcd - dnsmasq - mhttpd - webconf - A few more perhaps? Others would be contrib. So maybe 3 categories: core, mainstream, contrib ??? dMb -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] cvs structure
Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew: 29.10.2010 20:29, KP Kirchdoerfer пишет: - Shall we provide compiled packages, as we did with Bering-uClibc (packages page), better ideas? IMHO it'll be good to provide separate packages and prebuilt full image - like it was earlier. ok; - What about write permissions in cvs, shall we revive the contrib section (see http://sourceforge.net/apps/mediawiki/leaf/index.php?title=Talk:Bering- uClibc_4.x_-_Developer_Guide_-_Policies_and_Guidelines) Yes, IMHO it'll be good. Ok; I propose: - just core and contrib repository (names are not fixed), testing isn't needed - we can also put packages in contrib which we consider for testing or provided as-is. - lrp's and sources are required for both to be inline with the SF requirements. About write permissons: contrib should be open to all leaf-developers, what about the core? We may give write permissions to core by request... opinions? kp -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] cvs structure
On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote: Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew: Ok; I propose: - just core and contrib repository (names are not fixed), testing isn't needed - we can also put packages in contrib which we consider for testing or provided as-is. Just to make sure I understand 100%, some examples: etc.lrp: Certainly part of core. No debate. asterisk.lrp: Certainly part of contrib (only if it is fixed?) aiccu.lrp: Not part of core, since only relevant to some users, but you (kp) and I (dMb) would be willing to upgrade, test, repair etc. Should we distinguish supported contrib from unsupported contrib? Something like primary (instead of core - approx 10 packages that EVERY user will need), secondary (tested and supported, but not core), then contrib for the others? - lrp's and sources are required for both to be inline with the SF requirements. About write permissons: contrib should be open to all leaf-developers, what about the core? We may give write permissions to core by request... Access to core works OK by current mechanism, IMHO. opinions? kp -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] CVS structure and buildtool
Hi Martin on 29.09.2010 20:12, Martin Hejl wrote: Hi Erich, Either way, what is the canonical way to keep an existing build environment in sync with CVS. Buildtool does not check for modifications once a package is built. since nobody else chimed in (and since I'm partly to blame for some of the shortcomings of buildtool), I'll respond - I'm not aware of any means of doing that, without starting from scratch. Thanks, I will dig a little into the structure and see what I can do. Erich -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] CVS access problems - No write permission
Hi, I have been trying to check in some changes to package ntp as per my postings to leaf-user in January. I tried a couple of times on Monday and again yesterday since I know that sometimes SourceForge has issues. I can write to leaf/devel/davidmbrooke/src/bering-uclibc/apps but seemingly not to leaf/src/bering-uclibc/apps/ntp Is someone able to check my access permissions, or can someone check-in the changes if I email the files? Thanks, davidMbrooke -- 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] CVS access problems - No write permission
On Wed, 2010-03-10 at 18:06 +, davidMbrooke wrote: Hi, I have been trying to check in some changes to package ntp as per my postings to leaf-user in January. I tried a couple of times on Monday and again yesterday since I know that sometimes SourceForge has issues. I can write to leaf/devel/davidmbrooke/src/bering-uclibc/apps but seemingly not to leaf/src/bering-uclibc/apps/ntp Is someone able to check my access permissions, or can someone check-in the changes if I email the files? David, I suspect you lack commit rights for that directory in cvsroot/avail. -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, sourceforge/sitedocs -- 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] CVS access problems - No write permission
On Wed, 2010-03-10 at 10:18 -0800, Mike Noyes wrote: On Wed, 2010-03-10 at 18:06 +, davidMbrooke wrote: Hi, I have been trying to check in some changes to package ntp as per my postings to leaf-user in January. I tried a couple of times on Monday and again yesterday since I know that sometimes SourceForge has issues. I can write to leaf/devel/davidmbrooke/src/bering-uclibc/apps but seemingly not to leaf/src/bering-uclibc/apps/ntp Is someone able to check my access permissions, or can someone check-in the changes if I email the files? David, I suspect you lack commit rights for that directory in cvsroot/avail. Mike, OK. Is that something I can fix myself? If so I need some more clues I'm afraid... dMb -- 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] cvs commits
Hi kp, it seems that the cvs-commit mailinglist or the feature that commits activate a message on that list is broken. I've heard of various pb's with the latest SF platform update, maybe this ir related? as discussed off list, the missing cvs-commit messages from our new team memeber were due to the sender filter not including that user. This is fixed by now. If cvs commits don't make it to the list in the future, please let me know - every now and then, the mailing list stops functioning and needs a gentle push by somebody from the Sourceforge team. Martin -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] cvs commits
Hello; it seems that the cvs-commit mailinglist or the feature that commits activate a message on that list is broken. I've heard of various pb's with the latest SF platform update, maybe this ir related? kp -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS migration to SVN?
On Thu, 2009-03-12 at 20:57 +0100, KP Kirchdoerfer wrote: I do not see a real need to migrate. The current cvs usage just works and I haven't heart complains from users that there are any difficulties using cvs. Not to mention performance pb's with the few checkouts a week. a simple user (me) note: I see one benefit. Script updates would pull in new files automagically. Given that I'm the one, who has done most of the commits the last two years and every tag since we started to use cvs seriously, I'd like to stick to what I'm used to. understandable, I'v only worked with svn and find cvs tricky, and confusing :) And keep in mind a few tools to make release rely on cvs, these has to reworked, if we switch to svn. Thanks for all the great work you put into this project! kind regards Ronny Aasen -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS migration to SVN?
Hi all, -Original Message- From: KP Kirchdoerfer [mailto:kap...@users.sourceforge.net] Sent: Thursday, March 12, 2009 7:58 PM To: leaf-devel@lists.sourceforge.net Subject: Re: [leaf-devel] CVS migration to SVN? Am Donnerstag, 12. März 2009 18:56:09 schrieb Mike Noyes: Everyone, I think we should migrate to SVN. SVN integrates with Track well, and: moorman 1. Availability will be better on other services; we have a more scalable and resilient infrastructure under them moorman 2. Performance will be substantially better for any ops that actually involve data compares or over the wire communication moorman 3. Non-developers behind a firewall won't need to talk to their admin about punching a hole for 2401 to get pserver access to your repo Mike; I do not see a real need to migrate. Same here. Altough I no longer use CVS in any of my favorite projects. As most, I've switched to SVN completely. The current cvs usage just works and I haven't heart complains from users that there are any difficulties using cvs. Not to mention performance pb's with the few checkouts a week. Given that I'm the one, who has done most of the commits the last two years and every tag since we started to use cvs seriously, I'd like to stick to what I'm used to. And keep in mind a few tools to make release rely on cvs, these has to reworked, if we switch to svn. Yes, there is no time to go and break what is currently working. Besides, we will only change something if sf.net forces us to change. kp Luis Correia -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] CVS migration to SVN?
Everyone, I think we should migrate to SVN. SVN integrates with Track well, and: moorman 1. Availability will be better on other services; we have a more scalable and resilient infrastructure under them moorman 2. Performance will be substantially better for any ops that actually involve data compares or over the wire communication moorman 3. Non-developers behind a firewall won't need to talk to their admin about punching a hole for 2401 to get pserver access to your repo -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, sitedocs -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS status
On Wed, 2009-03-11 at 12:17 -0700, Mike Noyes wrote: 2009-03-10: Service CVS unplanned downtime - UPDATE http://apps.sourceforge.net/wordpress/sourceforge/2009/03/11/2009-03-10-service-cvs-unplanned-downtime-update/ 2009-03-10: Service CVS unplanned downtime - UPDATE 2 http://apps.sourceforge.net/wordpress/sourceforge/2009/03/12/2009-03-10-service-cvs-unplanned-downtime-update-2/ -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, sitedocs -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS migration to SVN?
Am Donnerstag, 12. März 2009 18:56:09 schrieb Mike Noyes: Everyone, I think we should migrate to SVN. SVN integrates with Track well, and: moorman 1. Availability will be better on other services; we have a more scalable and resilient infrastructure under them moorman 2. Performance will be substantially better for any ops that actually involve data compares or over the wire communication moorman 3. Non-developers behind a firewall won't need to talk to their admin about punching a hole for 2401 to get pserver access to your repo Mike; I do not see a real need to migrate. The current cvs usage just works and I haven't heart complains from users that there are any difficulties using cvs. Not to mention performance pb's with the few checkouts a week. Given that I'm the one, who has done most of the commits the last two years and every tag since we started to use cvs seriously, I'd like to stick to what I'm used to. And keep in mind a few tools to make release rely on cvs, these has to reworked, if we switch to svn. kp -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS status
On Thu, 2009-03-12 at 12:43 -0700, Mike Noyes wrote: On Wed, 2009-03-11 at 12:17 -0700, Mike Noyes wrote: 2009-03-10: Service CVS unplanned downtime - UPDATE http://apps.sourceforge.net/wordpress/sourceforge/2009/03/11/2009-03-10-service-cvs-unplanned-downtime-update/ 2009-03-10: Service CVS unplanned downtime - UPDATE 2 http://apps.sourceforge.net/wordpress/sourceforge/2009/03/12/2009-03-10-service-cvs-unplanned-downtime-update-2/ 2009-03-12: CVS service restored http://apps.sourceforge.net/wordpress/sourceforge/2009/03/13/2009-03-12-cvs-service-restored/ -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, sitedocs -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] CVS status
2009-03-10: Service CVS unplanned downtime - UPDATE http://apps.sourceforge.net/wordpress/sourceforge/2009/03/11/2009-03-10-service-cvs-unplanned-downtime-update/ -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, sitedocs -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS checkin glitch
On Tue, 2007-07-03 at 02:09, KP Kirchdoerfer wrote: On Tuesday 03 July 2007 09:08:29 Erich Titl wrote: Hi Folks I just happened to look into CVS and found a r1000 directory right at the root. This is certainly due to me doing an inapropriate checkin to the wrong location some time ago. Could someone with admin rights please move the thing to a better position within the tree? Thanks Erich you have first to checkin at the correct place, delete the files from the wring directory and ask SF support to remove the directory. cvs dos not allow to remove a directory for users (what we are from the perpective of cvs). KP Erich, I noticed that issue a while ago. I'll try to attend to it next week. Note: my track record for attending to recent project tasks in a timely manner is poor. :-( -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, sitedocs - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS checkin glitch
Mike Noyes schrieb: .. KP Erich, I noticed that issue a while ago. I'll try to attend to it next week. Thanks that would be great, there is a copy of r1000 in the contribute limb so removing the wrong one at the root should be enough Note: my track record for attending to recent project tasks in a timely manner is poor. :-( You are not n a race Thanks Erich - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] CVS checkin glitch
Hi Folks I just happened to look into CVS and found a r1000 directory right at the root. This is certainly due to me doing an inapropriate checkin to the wrong location some time ago. Could someone with admin rights please move the thing to a better position within the tree? Thanks Erich - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS checkin glitch
On Tuesday 03 July 2007 09:08:29 Erich Titl wrote: Hi Folks I just happened to look into CVS and found a r1000 directory right at the root. This is certainly due to me doing an inapropriate checkin to the wrong location some time ago. Could someone with admin rights please move the thing to a better position within the tree? Thanks Erich you have first to checkin at the correct place, delete the files from the wring directory and ask SF support to remove the directory. cvs dos not allow to remove a directory for users (what we are from the perpective of cvs). kp - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS Pbm
Mike Mike Noyes wrote: On Wed, 2007-04-11 at 15:06, Erich Titl wrote: Hi Mike, KP if you read along there is more to it, I changed the server name in sources.cfg to see where it leads to... snip It appears that the path on the server has changed too. Looks like cgi-bin moved somewhere else. Erich, When the SF staff changed the cvs server domain name, ViewCVS was replaced with a newer version called ViewVC. ViewVC has a slightly different url: http://leaf.cvs.sourceforge.net/leaf/ Thanks, please forward this to the buildtool maintainer Erich - 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS Pbm
Hi Erich Titl wrote: Mike Mike Noyes wrote: On Wed, 2007-04-11 at 15:06, Erich Titl wrote: Hi Mike, KP if you read along there is more to it, I changed the server name in sources.cfg to see where it leads to... snip It appears that the path on the server has changed too. Looks like cgi-bin moved somewhere else. Erich, When the SF staff changed the cvs server domain name, ViewCVS was replaced with a newer version called ViewVC. ViewVC has a slightly different url: http://leaf.cvs.sourceforge.net/leaf/ Thanks, please forward this to the buildtool maintainer I solved the probelem temporarily by using the cvsext method to download the sources. Now when trying to build buildenv I get linker problems ./gengenrtl -h tmp-genrtl.h ./gengenrtl: can't load library 'libc.so.0' I believe to remember this is just a link to the respective library, could someone give me a hint? Thanks Erich - 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS Pbm
Am Donnerstag, 12. April 2007 08:13:58 schrieb Erich Titl: Mike Mike Noyes wrote: On Wed, 2007-04-11 at 15:06, Erich Titl wrote: Hi Mike, KP if you read along there is more to it, I changed the server name in sources.cfg to see where it leads to... snip It appears that the path on the server has changed too. Looks like cgi-bin moved somewhere else. Erich, When the SF staff changed the cvs server domain name, ViewCVS was replaced with a newer version called ViewVC. ViewVC has a slightly different url: http://leaf.cvs.sourceforge.net/leaf/ Thanks, please forward this to the buildtool maintainer Erich Erich; I did a fresh chckout and started to build buildenv - the onyl pb's I had was an unavailable ftp.gnu.org - downloading from our SF repository worked. kp - 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS Pbm
luna ./buildtool.pl build buildenv make the list of required source packages: linux,buildenv [0.K.] source/package: linux downloading: buildtool.cfg from server cvs-sourceforge type viewcvs wget failed: /data/leaf/bering-uclibc/devel/latest/src/bering-uclibc/buildtool/source/linux/buildtool.cfg could not be found you might find useful information in log/buildtoollog buildtool::Download::download:file key: buildtool.cfg Warning: wildcards not supported in HTTP. --13:39:39-- http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/src/bering-uclibc/apps/linux/buildtool.cfg?rev=HEADcontent-type=application/octet-stream = `/data/leaf/bering-uclibc/devel/latest/src/bering-uclibc/buildtool/source/linux/buildtool.cfg' Resolving cvs.sourceforge.net... 66.35.250.207 Connecting to cvs.sourceforge.net|66.35.250.207|:80... failed: No route to host. apparently what is in CVS, e.g. sources.cfg is _not_ up to date, see the url tried above cheers Erich - 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS Pbm
Am Donnerstag, 12. April 2007 13:41:33 schrieb Erich Titl: luna ./buildtool.pl build buildenv make the list of required source packages: linux,buildenv [0.K.] source/package: linux downloading: buildtool.cfg from server cvs-sourceforge type viewcvs wget failed: /data/leaf/bering-uclibc/devel/latest/src/bering-uclibc/buildtool/source/li nux/buildtool.cfg could not be found you might find useful information in log/buildtoollog buildtool::Download::download:file key: buildtool.cfg Warning: wildcards not supported in HTTP. --13:39:39-- http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/src/bering-u clibc/apps/linux/buildtool.cfg?rev=HEADcontent-type=application/octet-strea m = `/data/leaf/bering-uclibc/devel/latest/src/bering-uclibc/buildtool/source/l inux/buildtool.cfg' Resolving cvs.sourceforge.net... 66.35.250.207 Connecting to cvs.sourceforge.net|66.35.250.207|:80... failed: No route to host. apparently what is in CVS, e.g. sources.cfg is _not_ up to date, see the url tried above I think it is up to date. Pls double-check your sources.cfg; see also: http://leaf.cvs.sourceforge.net/leaf/src/bering-uclibc/buildtool/conf/sources.cfg?revision=1.148view=markup kp - 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS Pbm
KP KP Kirchdoerfer wrote: Am Donnerstag, 12. April 2007 13:41:33 schrieb Erich Titl: luna ./buildtool.pl build buildenv make the list of required source packages: linux,buildenv [0.K.] source/package: linux downloading: buildtool.cfg from server cvs-sourceforge type viewcvs wget failed: /data/leaf/bering-uclibc/devel/latest/src/bering-uclibc/buildtool/source/li nux/buildtool.cfg could not be found you might find useful information in log/buildtoollog buildtool::Download::download:file key: buildtool.cfg Warning: wildcards not supported in HTTP. --13:39:39-- http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/src/bering-u clibc/apps/linux/buildtool.cfg?rev=HEADcontent-type=application/octet-strea m = `/data/leaf/bering-uclibc/devel/latest/src/bering-uclibc/buildtool/source/l inux/buildtool.cfg' Resolving cvs.sourceforge.net... 66.35.250.207 Connecting to cvs.sourceforge.net|66.35.250.207|:80... failed: No route to host. apparently what is in CVS, e.g. sources.cfg is _not_ up to date, see the url tried above I think it is up to date. Yep, I found the glitch, not downloading HEAD at the CVS download of buildenv. Sorry for the noise. Will test the r1000 stuff against the latest kernel now. Thanks Erich - 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] cvs pb's
Am Mittwoch, 11. April 2007 19:40:51 schrieb Mike Noyes: On Wed, 2007-04-11 at 07:56, Erich Titl wrote: Sorry again, even more info 16:55:45.633503 IP cvs.sourceforge.net luna.think.ch: icmp 68: host cvs.sourceforge.net unreachable - admin prohibited Erich, I just checked with the SF staff on irc, and the only known issue with pserver is from the SF project shell. Mike; I can confirm that situation has improved - I just committed, which wasn't possible earlier today. So the pserver is essential to finally update the guides. BTW: have you been able to fix the verbatim stylesheets issue? kp - 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 pb's
On Wed, 2007-04-11 at 12:13, KP Kirchdoerfer wrote: Am Mittwoch, 11. April 2007 19:40:51 schrieb Mike Noyes: On Wed, 2007-04-11 at 07:56, Erich Titl wrote: Sorry again, even more info 16:55:45.633503 IP cvs.sourceforge.net luna.think.ch: icmp 68: host cvs.sourceforge.net unreachable - admin prohibited Erich, I just checked with the SF staff on irc, and the only known issue with pserver is from the SF project shell. Mike; I can confirm that situation has improved - I just committed, which wasn't possible earlier today. So the pserver is essential to finally update the guides. KP, Essentially. I don't believe developer access is available from the SF project shell. BTW: have you been able to fix the verbatim stylesheets issue? I'm working on it. I believe it's a change in styling. They moved most of it to css. I have to generate a stylesheet and enable a docbook xslt param. -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, sitedocs - 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 Pbm
Hi Mike Mike Noyes schrieb: On Wed, 2007-04-11 at 13:12, Erich Titl wrote: Erich Titl schrieb: You are more familiar to the SF procedures than I am. I would not even know where to look. Could you give me a hand? I somehow managed to enter an SR. Will see where this leads to. Erich, Sorry. I was away from my computer for a while. I noticed burley commented re: your SR on irc when I returned. I apologize for missing the old cvs server in your posts. The new server is: leaf.cvs.sourceforge.net https://sourceforge.net/tracker/index.php?func=detailaid=1698752group_id=1atid=21 I see, then we need to fix the buildtool stuff, as all I do is buildtool.pl build buildenv which obviously uses configuration from the buildtool environment cheers Erich - 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 Pbm
Hi Mike, KP if you read along there is more to it, I changed the server name in sources.cfg to see where it leads to... Erich Titl schrieb: Hi Mike Mike Noyes schrieb: On Wed, 2007-04-11 at 13:12, Erich Titl wrote: Erich Titl schrieb: You are more familiar to the SF procedures than I am. I would not even know where to look. Could you give me a hand? I somehow managed to enter an SR. Will see where this leads to. Erich, Sorry. I was away from my computer for a while. I noticed burley commented re: your SR on irc when I returned. I apologize for missing the old cvs server in your posts. The new server is: leaf.cvs.sourceforge.net https://sourceforge.net/tracker/index.php?func=detailaid=1698752group_id=1atid=21 Warning: wildcards not supported in HTTP. --23:57:53-- http://leaf.cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/src/bering-uclibc/apps/linux/buildtool.cfg?rev=HEADcontent-type=application/octet-stream = `/data/leaf/bering-uclibc/devel/latest/src/bering-uclibc/buildtool/source/linux/buildtool.cfg' Resolving leaf.cvs.sourceforge.net... 66.35.250.86 Connecting to leaf.cvs.sourceforge.net|66.35.250.86|:80... connected. HTTP request sent, awaiting response... 404 Not Found 23:57:54 ERROR 404: Not Found. It appears that the path on the server has changed too. Looks like cgi-bin moved somewhere else. Erich - 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 Pbm
On Wed, 2007-04-11 at 15:06, Erich Titl wrote: Hi Mike, KP if you read along there is more to it, I changed the server name in sources.cfg to see where it leads to... snip It appears that the path on the server has changed too. Looks like cgi-bin moved somewhere else. Erich, When the SF staff changed the cvs server domain name, ViewCVS was replaced with a newer version called ViewVC. ViewVC has a slightly different url: http://leaf.cvs.sourceforge.net/leaf/ -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, sitedocs - 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] CVS tags
Charles Steinkuehler wrote: -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. I must have misunderstood you then, probably mistook tagging for branching Thanks for setting this right Erich ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS tags
On Sun, 2006-05-07 at 10:07, Erich Titl wrote: Mike Noyes wrote: On Fri, 2006-05-05 at 13:17, Martin Hejl wrote: 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! :). Well, that's what the whole we supply a tarball of everything you need, and put it into FRS approach was all about. But it seems that is not an approved approach. Martin, That approach is fine. I just thought the tag approach was easier. May I suggest to add a tag anyway for the following reasons - tags do not hurt CVS operation in any way, just make it easier to retrieve a certain version. - tags are easy to add - tags will work with the current buildtool although it is not used by it - adding a tag is faster than to build a tar file, such an archive is a nice shortcut though - adding a tag does not create overhead to the CVS archive (unless we use subversion) Erich, I agree with all the above, and have advocated tag use since 2002. http://www.mail-archive.com/leaf-devel@lists.sourceforge.net/msg05183.html -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] CVS tags
Subject was: Re: [leaf-devel] Glitch in initrd backup when using alternative initrdfile On Fri, 2006-05-05 at 02:58, Eric Spakman wrote: How does one to go about building the buildenv for a specific release, e.g. does CVS have release tags? For example, if I wanted to have a buildenv which matches _exactly_ the one for 2.4.1 how to proceed? 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. The Bering-uClibc team will make a snapshot of the current tree and put the sources in a tarball in the File release area. Eric, Please reconsider this decision. Tagging the release in cvs is easier. http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_4.html#SEC48 -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
Hi Mike, The Bering-uClibc team will make a snapshot of the current tree and put the sources in a tarball in the File release area. Eric, Please reconsider this decision. Tagging the release in cvs is easier. http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_4.html#SEC48 If this is easier to do, it's definitly preferable. Eric --- 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
Hi Mike, Mike Noyes wrote: Subject was: Re: [leaf-devel] Glitch in initrd backup when using alternative initrdfile On Fri, 2006-05-05 at 02:58, Eric Spakman wrote: How does one to go about building the buildenv for a specific release, e.g. does CVS have release tags? For example, if I wanted to have a buildenv which matches _exactly_ the one for 2.4.1 how to proceed? 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. The Bering-uClibc team will make a snapshot of the current tree and put the sources in a tarball in the File release area. Eric, Please reconsider this decision. Tagging the release in cvs is easier. http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_4.html#SEC48 Adding the tag is not the problem. Updating buildtool to use the tag/branch is. That's why creating a snapshot of a buildenv base (all the sources downloaded, but nothing compiled yet) is much easier for us than tagging the release, creating a maintenance branch (up to here I agree that it would be painfully easy) and modifying buildtool to be able to use the tags/branches for downloading filew via viewcvs. the way it is right now, buildtool simply downloads everything from HEAD - the code to let buildtool know which release branch to download packages for is simply not written at this point, and I don't see anybody who has time/is willing to write that code right now. Martin --- 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
On Fri, 2006-05-05 at 09:10, Martin Hejl wrote: Mike Noyes wrote: Tagging the release in cvs is easier. http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_4.html#SEC48 Adding the tag is not the problem. Martin, Agreed, and this is probably causing me confusion. Updating buildtool to use the tag/branch is. That's why creating a snapshot of a buildenv base (all the sources downloaded, but nothing compiled yet) is much easier for us than tagging the release, creating a maintenance branch (up to here I agree that it would be painfully easy) and modifying buildtool to be able to use the tags/branches for downloading filew via viewcvs. the way it is right now, buildtool simply downloads everything from HEAD - the code to let buildtool know which release branch to download packages for is simply not written at this point, Ok. I think I finally see the issue. Is buildtool able to use a checked out working copy to build from? Isn't building from checked out working copies best? I can't imagine pulling content from anonymous/developer cvs during the build process is painless. and I don't see anybody who has time/is willing to write that code right now. I wasn't asking for that. I thought it was a simple matter of adding the cvs tag for releases. I mistakenly(?) thought buildtool used a working copy for building. -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
Martin Martin Hejl wrote: .. Adding the tag is not the problem. Updating buildtool to use the tag/branch is. That's why creating a snapshot of a buildenv base (all the sources downloaded, but nothing compiled yet) is much easier for us than tagging the release, creating a maintenance branch (up to here I agree that it would be painfully easy) and modifying buildtool to be able to use the tags/branches for downloading filew via viewcvs. the way it is right now, buildtool simply downloads everything from HEAD - the code to let buildtool know which release branch to download packages for is simply not written at this point, and I don't see anybody who has time/is willing to write that code right now. 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). I agree it might not be the most elegant method, but might work. cheers Erich --- 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
Hi Mike; Am Freitag, 5. Mai 2006 19:24 schrieb Mike Noyes: On Fri, 2006-05-05 at 09:10, Martin Hejl wrote: Mike Noyes wrote: Tagging the release in cvs is easier. http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_4.html#SEC48 Adding the tag is not the problem. Martin, Agreed, and this is probably causing me confusion. Updating buildtool to use the tag/branch is. That's why creating a snapshot of a buildenv base (all the sources downloaded, but nothing compiled yet) is much easier for us than tagging the release, creating a maintenance branch (up to here I agree that it would be painfully easy) and modifying buildtool to be able to use the tags/branches for downloading filew via viewcvs. the way it is right now, buildtool simply downloads everything from HEAD - the code to let buildtool know which release branch to download packages for is simply not written at this point, Ok. I think I finally see the issue. Is buildtool able to use a checked out working copy to build from? Isn't building from checked out working copies best? I can't imagine pulling content from anonymous/developer cvs during the build process is painless. It isn't; and even using the restricted area can be harmful (broken downloads). But it is the current approach. And it was a step forward to build a LEAF router from the sources. and I don't see anybody who has time/is willing to write that code right now. I wasn't asking for that. I thought it was a simple matter of adding the cvs tag for releases. I mistakenly(?) thought buildtool used a working copy for building. I will test, if it's possible... kp --- 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
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. I agree it might not be the most elegant method, but might work. It might (I really don't know if it would catch everything, or miss some special cases nobody is thinking about right now). If somebody is willing to give it a shot, [s]he is more than welcome to do so. Martin --- 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
Hi again, Martin Hejl wrote: * Check out src/bering-uclibc/buildtool for the release branch of 2.4.1 * check out src/bering-uclibc/apps for the release branch of 2.4.1 * modify cvs-sourceforge use the file target for server cvs-sourceforge and make it point to the cvs checkout of src/bering-uclibc/apps made above * hope that we didn't forget to remove the cvs-sourceforge server specification in any of the buildtool.cfg files (and that none of the sources point to cvs-devel or some other site that doesn't use proper versioning - the latter is unlikely, but possible). just to clarify - there is no release branch at this time, so one would have to do the checkout based on date (2006-04-24 for 2.4.1, unless I'm mistaken). Martin ___ 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] CVS tags
Hi Charles, 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). Ah, ok, I get it. Thanks for the clarification. 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. Right. 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! :). Well, that's what the whole we supply a tarball of everything you need, and put it into FRS approach was all about. But it seems that is not an approved approach. 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 don't disagree with any of that, but you need to see it from my point of view. I do not have the time to make that migration, and to me, building old sources is not a priority (I already can do that for the old packages I need to support, because I have backups of my old buildenvs stashed away somewhere). So, to me, the whole thing would mean spending time I don't have on something that lets me do things I can already do. Now, believe me, I surely understand that there's more to software development than doing just the cool stuff that one is interested in - but since that pretty much sums up my day at work, I'll opt to not do so in my evenings as well, at least for something I don't consider to be something critical. I'm not going to debate the fact that it would surely be nice if somebody did it though 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. You are very welcome to try (and don't hesitate to ask if you run into trouble - at leat, the non-subversion kind of trouble ;-)) - I just don't have the time to do the work (and worse, the testing - doing a fresh checkout of everything and a rebuild uses up a whole evening on my internet connection/build environment). Martin ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS tags
On Fri, 2006-05-05 at 13:17, Martin Hejl wrote: 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! :). Well, that's what the whole we supply a tarball of everything you need, and put it into FRS approach was all about. But it seems that is not an approved approach. Martin, That approach is fine. I just thought the tag approach was easier. -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS Nighly tar.bz2
On Sun, 2004-06-27 at 04:38, Charles Steinkuehler wrote: Mike Noyes wrote: 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. Charles, Thanks for sending me the CDs. I was able to rsync, and I now have a current backup. :-) 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. -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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] cvs ssh keys?
Is it possible to use a key and ssh-agent to access the sourceforge cvs repository? Thanks, Chad --- 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 ssh keys?
On Mon, 2004-07-05 at 10:46, Chad Carr wrote: Is it possible to use a key and ssh-agent to access the sourceforge cvs repository? Chad, Yes, as far as I know. Please let me know if these documents fail to answer your question(s). SF Site Docs E5. Guide to generating, posting and using SSH keys https://sourceforge.net/docman/display_doc.php?docid=761group_id=1 I1. SSH Host Key Fingerprints for SSH-Accessible Hosts https://sourceforge.net/docman/display_doc.php?docid=3088group_id=1 -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
Charles FYI here is the output of the rsync job, looks like it takes 8 seconds to complete (without changes) Maybe you want to upgrade your rsync server someday. From [EMAIL PROTECTED] Tue Jun 29 10:00:08 2004 Date: Tue, 29 Jun 2004 10:00:01 +0200 From: [EMAIL PROTECTED] (Cron Daemon) To: [EMAIL PROTECTED] Subject: Cron [EMAIL PROTECTED] rsync -avz rsync.leaf-project.org::leaf-cvs/leaf /home/mega/leaf/leaf-cvs X-Cron-Env: SHELL=/bin/sh X-Cron-Env: HOME=/home/mega X-Cron-Env: PATH=/usr/bin:/bin X-Cron-Env: LOGNAME=mega All transfers logged Server is very old version of rsync, upgrade recommended. receiving file list ... done wrote 79 bytes read 104836 bytes 12342.94 bytes/sec total size is 1303946798 speedup is 12428.60 cheers Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- 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
Hi everyone At 04:17 27.06.2004, K.-P. Kirchdörfer wrote: Am Samstag, 26. Juni 2004 19:40 schrieb Mike Noyes: On Sat, 2004-06-26 at 09:44, K.-P. Kirchdörfer wrote: Am Samstag, 26. Juni 2004 18:27 schrieb Mike Noyes: We should have multiple backups of our repository. My limited bandwidth prevents me from downloading leaf-cvsroot.tar.bz2. Charles is the only project member I'm aware of that regularly downloads our repository. G3. SourceForge.net Data Backup and Restoration Policy https://sourceforge.net/docman/display_doc.php?docid=6840group_id=1 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. 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. 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. cheers Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- 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
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. -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
On Sun, 2004-06-27 at 04:38, Charles Steinkuehler wrote: Mike Noyes wrote: 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. Charles, Thank you, that would be a great help. :-) 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. I think you have my address, but I'll send it to you again if needed. -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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 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 Thanks Erich THINK Püntenstrasse 39 8143 Stallikon mailto:[EMAIL PROTECTED] PGP Fingerprint: BC9A 25BC 3954 3BC8 C024 8D8A B7D4 FF9D 05B8 0A16 --- 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
[leaf-devel] CVS Nighly tar.bz2
Everyone, How many of you periodically download our nightly repository? http://cvs.sourceforge.net/cvstarballs/leaf-cvsroot.tar.bz2 -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
Am Samstag, 26. Juni 2004 17:39 schrieb Mike Noyes: Everyone, How many of you periodically download our nightly repository? http://cvs.sourceforge.net/cvstarballs/leaf-cvsroot.tar.bz2 Mike; I'm not aware that a member of the Bering-uClibc team does it. Why do you ask? kp --- 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
On Sat, 2004-06-26 at 08:40, K.-P. Kirchdrfer wrote: Am Samstag, 26. Juni 2004 17:39 schrieb Mike Noyes: Everyone, How many of you periodically download our nightly repository? http://cvs.sourceforge.net/cvstarballs/leaf-cvsroot.tar.bz2 I'm not aware that a member of the Bering-uClibc team does it. Why do you ask? K.-P., We should have multiple backups of our repository. My limited bandwidth prevents me from downloading leaf-cvsroot.tar.bz2. Charles is the only project member I'm aware of that regularly downloads our repository. G3. SourceForge.net Data Backup and Restoration Policy https://sourceforge.net/docman/display_doc.php?docid=6840group_id=1 Charles makes our repository available for rsync. rsync rsync.leaf-project.org:: leaf-cvsLEAF Project CVS Archives -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
Am Samstag, 26. Juni 2004 18:27 schrieb Mike Noyes: On Sat, 2004-06-26 at 08:40, K.-P. Kirchdrfer wrote: Am Samstag, 26. Juni 2004 17:39 schrieb Mike Noyes: Everyone, How many of you periodically download our nightly repository? http://cvs.sourceforge.net/cvstarballs/leaf-cvsroot.tar.bz2 I'm not aware that a member of the Bering-uClibc team does it. Why do you ask? K.-P., We should have multiple backups of our repository. My limited bandwidth prevents me from downloading leaf-cvsroot.tar.bz2. Charles is the only project member I'm aware of that regularly downloads our repository. G3. SourceForge.net Data Backup and Restoration Policy https://sourceforge.net/docman/display_doc.php?docid=6840group_id=1 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? A side note: The tarball link on main page is broken (still points to tar.gz) kp --- 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
Re: [leaf-devel] CVS Nighly tar.bz2
Am Samstag, 26. Juni 2004 19:40 schrieb Mike Noyes: On Sat, 2004-06-26 at 09:44, K.-P. Kirchdrfer wrote: Am Samstag, 26. Juni 2004 18:27 schrieb Mike Noyes: We should have multiple backups of our repository. My limited bandwidth prevents me from downloading leaf-cvsroot.tar.bz2. Charles is the only project member I'm aware of that regularly downloads our repository. G3. SourceForge.net Data Backup and Restoration Policy https://sourceforge.net/docman/display_doc.php?docid=6840group_id=1 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. 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. A side note: The tarball link on main page is broken (still points to tar.gz) You'll note it's correct on the preview of our new website. http://leaf.steinkuehler.net/ If this is the actual page, I'll complain again that the current Releases/Branches entry should be added - the Derivation is IMHO not clear enough. kp --- 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
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. A side note: The tarball link on main page is broken (still points to tar.gz) You'll note it's correct on the preview of our new website. http://leaf.steinkuehler.net/ If this is the actual page, I'll complain again that the current Releases/Branches entry should be added - the Derivation is IMHO not clear enough. It is the same page you originally made that comment on. I haven't uploaded a new version yet. Your comment is noted, and will be addressed in the next preview. Thanks for your feedback. -- Mike Noyes mhnoyes at users.sourceforge.net http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs --- 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
Am Sonntag, 27. Juni 2004 05:23 schrieb Mike Noyes: 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. ok; I will setup a cron job to backup every three days. kp --- 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] CVS update
Everyone, Yesterday I updated 'syncmail', and applied a patch to 'cvs_acls' that simplified 'avail'. Please let me know if you run into any problems. Thanks. -- Mike Noyes mhnoyes @ users.sourceforge.net http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] CVS repository module update
Everyone, I made significant changes to our defined modules. See the cvs-commit message for details. CVSROOT modules,1.5,1.6 https://sourceforge.net/mailarchive/forum.php?thread_id=1835246forum_id=12138 -- Mike Noyes mhnoyes @ users.sourceforge.net http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] CVS repository update
Everyone, I just made some significant changes to our CVS repository. I defined modules for all of our releases/branches and packages. I gave global write access for all project members to the following trees: doc/docmanager doc/howto doc/man doc/network_diagrams bin/packages I added a README file to the toplevel of our repository. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/ -- Mike Noyes mhnoyes @ users.sourceforge.net http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS Question
Chad, Thanks for all your help with my CVS qustions. I think I have the hang of it now. Greg Morgan --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS Question
Mike Noyes wrote: On Tue, 2003-02-11 at 23:56, Greg Morgan wrote: I followed the CVS document Mike Noyes wrote at http://sourceforge.net/docman/display_doc.php?docid=9960group_id=13751. Greg, That may be the cause, but I'd need the exact import command you used to The fatal captain's log from the history file: cd /home/edrive/leaf/devel/dr_kludge/GilaMonster cd .. ls cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/leaf import -I ! devel/dr_kludge/GilaMonster vendor start I read the docs at SF and the CVS home page. I think this a cvs newbie error. verify it. Have you looked at the new SF Site Docs for CVS? They are very good. F1. Basic Introduction to CVS and SourceForge.net Project CVS Services https://sourceforge.net/docman/display_doc.php?docid=14033group_id=1 F2. Introduction to SourceForge.net Project CVS Services for Developers https://sourceforge.net/docman/display_doc.php?docid=768group_id=1 Would you like me to open a support request with the SF staff to correct the problem? Mike, please have SF staff remove the lowest directory in the path below. The lowest GilaMonster directory was created in error. I checked in copies of the files to the directory above the one I would like removed. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/dr_kludge/GilaMonster/GilaMonster/ Thanks, Greg Morgan --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS Question
On Thu, 2003-02-13 at 03:32, Greg Morgan wrote: Mike Noyes wrote: That may be the cause, but I'd need the exact import command you used to The fatal captain's log from the history file: cd /home/edrive/leaf/devel/dr_kludge/GilaMonster Greg, Is this a checked out cvs tree/module? Imports should not be performed from a checked out tree/module. You can cause all sorts of problems doing that. cd .. This was the error. You jumped up from the tree you wished to import. CVS creates a directory specified in the module when importing. You specified GilaMonster as the new module, and had GilaMonster in the current directory. This caused: devel/dr_kludge/GilaMonster/GilaMonster ls cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/leaf import -I ! devel/dr_kludge/GilaMonster vendor start This import command was fine. :-) Would you like me to open a support request with the SF staff to correct the problem? Mike, please have SF staff remove the lowest directory in the path below. The lowest GilaMonster directory was created in error. I checked in copies of the files to the directory above the one I would like removed. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/dr_kludge/GilaMonster/GilaMonster/ Understood. I'll open a SF support request to correct the problem. -- Mike Noyes mhnoyes @ users.sourceforge.net http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS Question
On Tue, 2003-02-11 at 23:56, Greg Morgan wrote: I followed the CVS document Mike Noyes wrote at http://sourceforge.net/docman/display_doc.php?docid=9960group_id=13751. I wound up with two problems. One I have two directories in my checkin. Two, I must of fouled up something because I received a trace back. Does anyone see what I did wrong? On the first question it appears that I may have been two high up in the directory? Greg, That may be the cause, but I'd need the exact import command you used to verify it. Have you looked at the new SF Site Docs for CVS? They are very good. F1. Basic Introduction to CVS and SourceForge.net Project CVS Services https://sourceforge.net/docman/display_doc.php?docid=14033group_id=1 F2. Introduction to SourceForge.net Project CVS Services for Developers https://sourceforge.net/docman/display_doc.php?docid=768group_id=1 Would you like me to open a support request with the SF staff to correct the problem? ValueError: unpack list of wrong size This is a known snycmail bug. It usually happens when importing empty directories. Other things can trigger it too. The only result of this error is a failure to generate a commit email to our cvs-commits list. ref. Syncmail bug report 583345 https://sourceforge.net/tracker/?func=detailaid=583345group_id=47611atid=450019 -- Mike Noyes mhnoyes @ users.sourceforge.net http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ http://sitedocs.sf.net/ http://ffl.sf.net/ --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[leaf-devel] CVS Question
Is this correct? I understand you can do many things with CVS. I want to checkin some of my stuff. Do I just want to think in directory structure under my directory? ..\devel\dr_kludge\thingtwo ..\devel\dr_kludge\and ..\devel\dr_kludge\thingone In other words, I don't need to think about tags right now? Thanks, Greg Morgan --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS Question
On Mon, 2003-02-10 at 05:21, Greg Morgan wrote: Is this correct? I understand you can do many things with CVS. I want to checkin some of my stuff. Do I just want to think in directory structure under my directory? ..\devel\dr_kludge\thingtwo ..\devel\dr_kludge\and ..\devel\dr_kludge\thingone Yes. You can take a look at mine for pointers, but the structure is for the developer, usually. Makefiles generally take care of moving the stuff around on the target to its proper place. In other words, I don't need to think about tags right now? Tags are usually used for symbolically tagging code in a repository for releasing, or tying separate individual revisions of files together as a checkpoint like alpha or beta like so: myproj/Makefile - rev 1.1 - tag 1_0_REL myproj/foo.txt - rev 1.4 - tag 1_0_REL myproj/bar.sh - rev 1.11 - tag 1_0_REL myproj/baz.cc - rev 1.47 - tag 1_0_REL That way you can check out 1_0_REL and get the proper revisions of each file without having to remember. Then file revisions are just mechanical; tags, rtags and branches become symbolic. -- --- Chad Carr [EMAIL PROTECTED] --- --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] cvs src tree
On Mon, 26 Aug 2002 14:11:13 -0500 guitarlynn [EMAIL PROTECTED] wrote: +packages +glibc-2.0 +glibc-2.1 +glibc-none +binaries I believe the seperation of glibc within packages will avoid confusion between packages with the same package name that actually differ in end use. If we use David's build system for our packages tree, isn't the glibc separation unnecessary? Has anyone evaluated David's build system yet? I'm sure he would appreciate some feedback. Is it a usable system for our packages tree? The tree looks great, however there is no source that I could find located within the tree itself. It appeared able to pull the source from a remote location from the tree, however I thought that we found that doing that would be unacceptable under the GPL anyway (possibly fine within the MIT licensing, I dunno). The GPL does not support linking remote source as I believe we discovered and the reasoning for getting the LEAF source tree up in the first place. As I understand it, we simply need the source posted for compiled binaries and linked from where the compiled binary is available for download AND the source must be located locally. Does this really need to be done? If the source is unmodified, why would we create another internet residence for it (other than mirroring needs, in which case that's how we should handle it, although I don't think the LEAF project is in a disk space position to be mirroring upstream packages). I haven't seen anything in the GPL that says we need to duplicate unmodified source on our site. The last paragraph of section three seems to make linking to upstream sources okay. The distribution method for sources should match the distribution method of the binaries, but the purpose of the GPL is not to force multiple destinations to be available for downloading a single source package. It is to attempt to put legal constraints on the spirit of a community. Since it almost never behooves a company to become a true part of a community, the license tries to enforce the proper behavior from them. Companies (and some people, I should be fair) do not understand communities; they only understand free source code and shortened project timelines. Frankly, the true spirit of the GPL is being followed as long as we allow people to easily do exactly as we have done: download upstream sources, modify them to suit their needs (by patching) and compile them into machine-readable code for their platform. Doing these things will help us as developers sharing a common methodology, too. Also, if we make a modification to a source package (such as Bering has done with the scripts from freeswan) we need to have a proper way to make those modifications available so that people can use them (probably shell script mods are not a good example in this case, since technically they are available in the binary distribution). It should be easy for people to find and separate our modifications so that they can use some or all of them, in conjunction with their own. For instance, if someone wanted to use the freeswan modifications, but they had the regular route program, and they were masochists and had their own modification to remove the 300-line awk script in the manual script, they should be able to identify and modify our changes easily. They should be able to find a patch and exactly how to apply it, so that they can remove the parts of our patch that they don't need and find instructions and a build environment so that they can apply their own patch. Whew, that was pretty long winded. Essentially, we need to understand what the GPL means. It is not meant to be a burden on developers (which disk space is, in our circumstance, it seems) but to be a legal invocation of some concepts. We need to follow those concepts. It is sad when people come onto the list and make GPL developers afraid of ridicule or losing some privilege, when all they need to do is cover some accounting work. Yes, we should consider this a primary effort, but it is not trivial to do it right, people understand that. Our development has grown faster than we have kept up with the details, that's all. The addition of a binary tree will allow for compiled executables/utilities that are not part of any core image or package that are available for LEAF. Please explain the need for a binary tree in src. Its purpose is not clear to me from your explanation above. Is it for source tarballs from other projects? There are several binaries that various people offer that are not part of a LEAF package (su, telnet, etc). It would be strange to stick a non-packaged src in the package src, but another thought would be to simply offer the binary src and not the entire LEAF package since everything else in the packages are script and their own src code. Thoughts? This would be source code that may
RE: [Leaf-devel] cvs src tree
This seems to be about the same as what was proposed last time this thread went around. I think this solution makes perfect sense. It has my vote! Regards, Eric -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of guitarlynn Sent: Saturday, August 24, 2002 11:43 PM To: [EMAIL PROTECTED] Subject: [Leaf-devel] cvs src tree I've been doing some thinking about a good way to setup the LEAF src tree, as there is still nothing there. As I need to upload my own src for a package binary and working on others, I need somewhere to put it within the tree. My thoughts on a tree structure are as follows: src +bering +dachstein +oxygen +packetfilter +wisp-dist +packages +glibc-2.0 +glibc-2.1 +glibc-none +binaries I believe the seperation of glibc within packages will avoid confusion between packages with the same package name that actually differ in end use. The addition of a binary tree will allow for compiled executables/utilities that are not part of any core image or package that are available for LEAF. Any thoughts, as we need to have the src tree up and populated! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] cvs src tree
src +bering +dachstein +oxygen +packetfilter +wisp-dist +packages +glibc-2.0 +glibc-2.1 +glibc-none +glibc-2.2 For WISP-Dist ;) Actually WISP-Dist CFSLRP packages are not backwards compatible with LRP. Any ideas about a good place for them? -- Best Regards, Vladimir Systems Engineer (RHCE) --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] cvs src tree
On Mon, 2002-08-26 at 10:06, Vladimir I. wrote: Actually WISP-Dist CFSLRP packages are not backwards compatible with LRP. Any ideas about a good place for them? Vladimir, Anything release/branch specific should be in the release/branch trees. Example: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/ bin/wisp-dist/ src/wisp-dist/ Note: I just created the src/wisp-dist tree for you, and gave you write access to it. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] cvs src tree
On Sat, 2002-08-24 at 20:42, guitarlynn wrote: I've been doing some thinking about a good way to setup the LEAF src tree, as there is still nothing there. snip Lynn, Thank you for opening this topic for discussion again. :-) Remember I'm not a programmer when reading my comments below. src +bering +dachstein +oxygen +packetfilter +wisp-dist Agreed. I'm with you so far. +packages +glibc-2.0 +glibc-2.1 +glibc-none +binaries I believe the seperation of glibc within packages will avoid confusion between packages with the same package name that actually differ in end use. If we use David's build system for our packages tree, isn't the glibc separation unnecessary? http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/ddouthitt/base/ Has anyone evaluated David's build system yet? I'm sure he would appreciate some feedback. Is it a usable system for our packages tree? The addition of a binary tree will allow for compiled executables/utilities that are not part of any core image or package that are available for LEAF. Please explain the need for a binary tree in src. Its purpose is not clear to me from your explanation above. Is it for source tarballs from other projects? Any thoughts, as we need to have the src tree up and populated! Agreed. We have discussed this tree for over a year now, and little has come of it. We can't cooperate effectively on releases/branches or packages until we have a working src tree. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] cvs src tree
On Monday 26 August 2002 12:49, Mike Noyes wrote: Lynn, Thank you for opening this topic for discussion again. :-) Remember I'm not a programmer when reading my comments below. No problem, as discussed many times over the last yearthis needs to be done! +packages +glibc-2.0 +glibc-2.1 +glibc-none +binaries I believe the seperation of glibc within packages will avoid confusion between packages with the same package name that actually differ in end use. If we use David's build system for our packages tree, isn't the glibc separation unnecessary? Has anyone evaluated David's build system yet? I'm sure he would appreciate some feedback. Is it a usable system for our packages tree? The tree looks great, however there is no source that I could find located within the tree itself. It appeared able to pull the source from a remote location from the tree, however I thought that we found that doing that would be unacceptable under the GPL anyway (possibly fine within the MIT licensing, I dunno). The GPL does not support linking remote source as I believe we discovered and the reasoning for getting the LEAF source tree up in the first place. As I understand it, we simply need the source posted for compiled binaries and linked from where the compiled binary is available for download AND the source must be located locally. I may have missed another interpretration. David may have the source local on the SF site, but I was unable to locate the downloadable tarball. The addition of a binary tree will allow for compiled executables/utilities that are not part of any core image or package that are available for LEAF. Please explain the need for a binary tree in src. Its purpose is not clear to me from your explanation above. Is it for source tarballs from other projects? There are several binaries that various people offer that are not part of a LEAF package (su, telnet, etc). It would be strange to stick a non-packaged src in the package src, but another thought would be to simply offer the binary src and not the entire LEAF package since everything else in the packages are script and their own src code. Thoughts? This would be source code that may not belong to any project. I will need to include atleast one (that I have already compiled) within the webconfig package I am playing with. Any thoughts, as we need to have the src tree up and populated! Agreed. We have discussed this tree for over a year now, and little has come of it. We can't cooperate effectively on releases/branches or packages until we have a working src tree. Well, there can be many ramifications if the src tree is not up. These concerns may include ridicule and loss of hosting, which I would rather not see. SF has been exceptionally nice in the free hosting and services offered. -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ???
On Wed, Jul 10, 2002 at 02:19:58PM -0500, Michael D. Schleif wrote: [1] Should I have separate trees for different underlying versions of net-snmp? For example, I committed net-snmp v4.2.4. I am contemplating building and committing both v4.2.5 and the totally different distribution v5.x. So, one line of thinking is like this: devel/helices/net-snmp/v4.2.4/netsnmp.lrp devel/helices/net-snmp/v4.2.4/netsnmpd.lrp Looks good to me, would allow for recursive wget --no-parent or ncftp -R and version management would be a simpler. A copy of the current as devel/helices/net-snmp/current/netsnmpd.lrp or a zero legnth file devel/helices/net-snmp/current-is-v5.0.2 are also helpful; get devel/helices/net-snmp/current-* | sed | ncftpget -R v5.0.2 http://leaf.sourceforge.net/devel/helices/net-snmp/ presents several TXT files that, once clicked on, present descriptive text regarding the LRP's that reside in versioned directories below this one. Another example is Jacques Nilo's http://leaf.sourceforge.net/devel/jnilo/ wonderful page that links to installation and troubleshooting information. How are we to do this under cvs? I would put the txt files in the version directores for which they belong. At some point (maybe even by a cgi to select components) a custom disk image might be generated, such a program would have no trouble separating out .txt and .lrp files. // George -- GEORGE GEORGALIS, System Admin/Architectcell: 347-451-8229 Security Services, Web, Mail,mailto:[EMAIL PROTECTED] File, Print, DB and DNS Servers. http://www.galis.org/george --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ???
On Wed, Jul 10, 2002 at 01:01:27PM -0700, Jeff Newmiller wrote: On Wed, 10 Jul 2002, Michael D. Schleif wrote: CVS is designed to handle directories full of information... so a directory tree of html documents is a natural thing to enter. An idea... net-snmp/ README.txt package/ net-snmp.lrp target/ etc/ blahblah usr/ bin/ snmpbinary ... doc/ index.html images/ image1.jpg ... src/ sourcefiles... Let CVS deal with versioning. Yeah, I was thinking about http/ftp access. Looks good. // George -- GEORGE GEORGALIS, System Admin/Architectcell: 347-451-8229 Security Services, Web, Mail,mailto:[EMAIL PROTECTED] File, Print, DB and DNS Servers. http://www.galis.org/george --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS src tree structure
On Tue, 2002-07-16 at 14:41, David Douthitt wrote: On Mon, Jul 15, 2002 at 10:28:00AM -0700, Mike Noyes wrote: I think a system similar to BSD Ports or Gentoo Portage would be great. David already has sample implementation available. http://cvs.leaf-project.org/cgi-bin/viewcvs.cgi/leaf/devel/ddouthitt/base/ Now I've actually (with Mike's help) been able to properly update this to reflect the current state of my ports configuration. Be aware that I must go over these again to refresh my memory and to update any thing that needs updating. That directory archive isn't supposed to be there; I'm going to try and delete it... David, The archives directory was removed. Your tree should be correct now. Let me know if you need any other assistance. -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ???
Jeff Newmiller wrote: On Wed, 10 Jul 2002, Michael D. Schleif wrote: [ snip ] I am starting to realize that, perhaps, I should take a directory based approach to helices' cvs tree. I have not settled on any particular structure. However, I am wondering about several things: [ snip ] CVS is designed to handle directories full of information... so a directory tree of html documents is a natural thing to enter. An idea... net-snmp/ README.txt package/ net-snmp.lrp target/ etc/ blahblah usr/ bin/ snmpbinary ... doc/ index.html images/ image1.jpg ... src/ sourcefiles... [ snip ] I took a liking to this structure, which you can see here: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/helices/ I appreciate *ALL* feedback on this infrastructure, before I get carried away with further additions to cvs. What do you think? -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] cvs-commits-list
Everyone, Project members should subscribe to our leaf-cvs-commits list. http://lists.sourceforge.net/lists/listinfo/leaf-cvs-commits -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ???
On Wed, Jul 17, 2002 at 03:21:32PM -0500, Michael D. Schleif wrote:
Jeff Newmiller wrote:
CVS is designed to handle directories full of information... so a
directory tree of html documents is a natural thing to enter.
An idea...
net-snmp/
README.txt
package/
net-snmp.lrp
target/
etc/
blahblah
usr/
bin/
snmpbinary
...
doc/
index.html
images/
image1.jpg
...
src/
sourcefiles...
[ snip ]
I took a liking to this structure, which you can see here:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/helices/
I appreciate *ALL* feedback on this infrastructure, before I get carried
away with further additions to cvs.
What do you think?
My model has been the following:
archives/
somearchive.tar.gz
otherarchive.bz2
...
iproute2/
distinfo
Makefile
patches/
somepatchname.diff
somepatchname2.diff
...
work/ {temporary dir; created and used to compile within}
binaries/ {temporary dir; created and stores binaries ONLY (no path)}
world/{temporary dir; created and used to store full paths
and all files needed within the structure}
otherpkg/
...
My current lrp package setup was to have the following:
iproute2-sourcedir/
lrp/ {created}
...
Under lrp/ there is a Makefile which contains all of the targets to make packages, etc.
There is also a directory like world/ above which contains all paths and a Makefile
in each directory that needs to have a binary in it.
After this lrp/ directory is correctly configured, then the entire directory is
wrapped up into a *.diff file and saved with the unmodified source archive. Examples
of this can be found in the Oxygen/LEAF Resource CDROM.
Perhaps what I will do is to use this patch as a regular patch in the CVS ports tree
and add the patch to the source code, then use it to create packages at will.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ???
David Douthitt wrote:
[ snip ]
My model has been the following:
archives/
somearchive.tar.gz
otherarchive.bz2
...
iproute2/
distinfo
Makefile
patches/
somepatchname.diff
somepatchname2.diff
...
work/ {temporary dir; created and used to compile within}
binaries/ {temporary dir; created and stores binaries ONLY (no path)}
world/{temporary dir; created and used to store full paths
and all files needed within the structure}
otherpkg/
...
My current lrp package setup was to have the following:
iproute2-sourcedir/
lrp/ {created}
...
Under lrp/ there is a Makefile which contains all of the targets to make packages,
etc.
There is also a directory like world/ above which contains all paths and a Makefile
in each directory that needs to have a binary in it.
After this lrp/ directory is correctly configured, then the entire directory is
wrapped up into a *.diff file and saved with the unmodified source archive.
Examples
of this can be found in the Oxygen/LEAF Resource CDROM.
Perhaps what I will do is to use this patch as a regular patch in the CVS ports tree
and add the patch to the source code, then use it to create packages at will.
I've been considering using whatever structure I settle on as my
development environment. I have cvs setup on my own network and hope to
integrate leaf development into my other development projects. However,
cvs doesn't lend itself to this end for several reasons:
[1] Each sandbox includes cvs directories under each directory in the
project. So, rolling up the hierarchy directly into an LRP is
cumbersome. cvs export only adds to the kludge.
[2] Since cvs does not retain group, mode nor ownership attributes, [1]
is further complicated and requires another kludge to correct directory
and files attributes.
[3] I still have not figured out how to force synchronization between
cvs revision numbers and project source revision numbers.
[4] All of this makes inclusion of package/package/package.lrp an
absolute must!
If anybody has overcome any of these obstacles, I'd appreciate
enlightenment . . .
--
Best Regards,
mds
mds resource
888.250.3987
Dare to fix things before they break . . .
Our capacity for understanding is inversely proportional to how much we
think we know. The more I know, the more I know I don't know . . .
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] CVS structure ???
On Wed, 2002-07-17 at 15:50, Michael D. Schleif wrote: [2] Since cvs does not retain group, mode nor ownership attributes, [1] is further complicated and requires another kludge to correct directory and files attributes. Michael, This should only be an issue when exporting for public distribution. The recommended solution is a script to export, configure, and package your release. # Exporting For Public Distribution http://cvsbook.red-bean.com/cvsbook.html#Exporting_For_Public_Distribution -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] cvs commit directory structure ???
On Mon, 2002-07-15 at 22:39, Michael D. Schleif wrote: No matter how hard I try, I cannot commit a directory structure to cvs. Michael, You need to use import to add a directory of files. You can use add to make new directories. I get lock failures, even when I try to commit them one directory at a time. Where in our repository are you trying to commit/add/import files? Clearly, there is some approved process for doing this and I do not know what that is. Also, what is this limitation that all files must use *ONLY* lowercase letters??? This was explained recently. http://www.mail-archive.com/leaf-devel%40lists.sourceforge.net/msg05217.html -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] cvs commit directory structure ???
On Mon, 2002-07-15 at 22:39, Michael D. Schleif wrote: No matter how hard I try, I cannot commit a directory structure to cvs. I get lock failures, even when I try to commit them one directory at a time. Clearly, there is some approved process for doing this and I do not know what that is. Michael, I looked at your commit messages, and I think I understand what you were trying to accomplish. Here is a sequence that I believe would have worked. From a directory out side of your checked out cvs tree (devel/helices). Create the directory hierarchy that you wish to add to our repository. Then from inside the root of this new hierarchy execute: $ cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/leaf import \ -I ! devel/helices/ntpclnt vendor start Note: naming conventions aren't enforced on imports. Note: this command will not work now, as there is already a directory with that name in our repository. Would you like me to open a SF support request, and have them clean your devel/helices tree out? You can start fresh that way. ref. CVS Setup - Importing Directories http://sourceforge.net/docman/display_doc.php?docid=9960group_id=13751 Open Source Development with CVS - Starting A New Project http://cvsbook.red-bean.com/cvsbook.html#Starting_A_New_Project -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] cvs commit directory structure ???
I now believe that all of my cvs study led me to conclude that I was creating and modifying ``modules''; but, modules can only exist at the top level under CVSROOT. Therefore, you are probably correct that cvs import is the solution here. In an effort to correct my miscreant behaviour, I tried using cvs remove. Under some conditions, cvs remove works as expected. However, see failed transaction, at end, to see problems with inability to generate locked files. Are there limitations to cvs remove? What is the cause of the lock problem? Mike Noyes wrote: On Mon, 2002-07-15 at 22:39, Michael D. Schleif wrote: No matter how hard I try, I cannot commit a directory structure to cvs. I get lock failures, even when I try to commit them one directory at a time. Clearly, there is some approved process for doing this and I do not know what that is. Michael, I looked at your commit messages, and I think I understand what you were trying to accomplish. Here is a sequence that I believe would have worked. From a directory out side of your checked out cvs tree (devel/helices). Create the directory hierarchy that you wish to add to our repository. Then from inside the root of this new hierarchy execute: $ cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/leaf import \ -I ! devel/helices/ntpclnt vendor start Note: naming conventions aren't enforced on imports. Note: this command will not work now, as there is already a directory with that name in our repository. Would you like me to open a SF support request, and have them clean your devel/helices tree out? You can start fresh that way. Yes, have somebody purge/delete/remove devel/helices/ntpclnt and everything below that. [ snip ] # ls devel/helices/ CVS netsnmp.lrp netsnmpd.lrp nettrapd.lrp ntpclnt # cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/leaf remove devel/helices/ntpclnt [EMAIL PROTECTED]'s password: cvs remove: warning: directory CVS specified in argument cvs remove: but CVS uses CVS for its own purposes; skipping CVS directory ? devel/helices/ntpclnt/package/ntpclnt.lrp ? devel/helices/ntpclnt/target/etc/ntpclient.conf ? devel/helices/ntpclnt/target/etc/init.d/ntpclient ? devel/helices/ntpclnt/target/var/lib/lrpkg/ntpclnt.bktype ? devel/helices/ntpclnt/target/var/lib/lrpkg/ntpclnt.conf ? devel/helices/ntpclnt/target/var/lib/lrpkg/ntpclnt.help ? devel/helices/ntpclnt/target/var/lib/lrpkg/ntpclnt.list ? devel/helices/ntpclnt/target/var/lib/lrpkg/ntpclnt.local ? devel/helices/ntpclnt/target/var/lib/lrpkg/ntpclnt.version cvs server: Removing devel/helices/ntpclnt cvs server: file `devel/helices/ntpclnt/readme.txt' still in working directory cvs server: Removing devel/helices/ntpclnt/package cvs server: Removing devel/helices/ntpclnt/target cvs server: Removing devel/helices/ntpclnt/target/etc cvs server: failed to create lock directory for `/cvsroot/leaf/devel/helices/ntpclnt/target/etc' (/cvsroot/leaf/devel/helices/ntpclnt/target/etc/#cvs.lock): No such file or directory cvs server: failed to obtain dir lock in repository `/cvsroot/leaf/devel/helices/ntpclnt/target/etc' cvs [server aborted]: read lock failed - giving up -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] cvs commit directory structure ???
On Tue, 2002-07-16 at 06:32, Michael D. Schleif wrote: I now believe that all of my cvs study led me to conclude that I was creating and modifying ``modules''; but, modules can only exist at the top level under CVSROOT. Therefore, you are probably correct that cvs import is the solution here. Michael, We have no modules defined at this time. If you would like a module defined, please send me the appropriate information for CVSROOT/modules. http://cvs.leaf-project.org/cgi-bin/viewcvs.cgi/leaf/CVSROOT/ In an effort to correct my miscreant behaviour, I tried using cvs remove. Under some conditions, cvs remove works as expected. However, see failed transaction, at end, to see problems with inability to generate locked files. I would need to see the commands you typed in to understand the lock file problem. It may have something to do with a prior command leaving your tree in an unstable state. Are there limitations to cvs remove? What is the cause of the lock problem? Yes. It will not remove directories. Again, I'm unsure. Would you post the commands you used? The information I'm working from is obtained from our leaf-cvs-commits list. http://www.mail-archive.com/leaf-cvs-commits%40lists.sourceforge.net/ -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ --- This sf.net email is sponsored by: Jabber - The world's fastest growing real-time communications platform! Don't just IM. Build it in! http://www.jabber.com/osdn/xim ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
