[leaf-devel] Glitch in initrd backup when using alternative initrd file
Hi folks I have multiple LEAF systems on the same hardware booting from the same medium. This requires the use of different initrd files, I call the secondary file initrd2.lrp. In the backup menu this is displayed correctly whereas in the /var/lib/lrpkg directory the corresponding files are still named initrd. This is because these files are not built/named dynamically but are contained in the initrd file itself (as they are in all other .lrp packages) It might be nice if the files controlling the backup could be dynamically named (as the backup target is). This could be done rather easily with the files loaded by lrpkg -i, it may be a trifle more tricky for initrd though. I am tempted to do this for my recent system. Thoughts 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] Glitch in initrd backup when using alternative initrd file
Hi Erich, The question is, how useful is it to backup initrd? Life could be made very easy when the option to backup initrd is removed. There are different initrd packages which makes booting of of most systems possible (floppy, usb, cdrom and hd) and if anything is missing a new initrd can be added. Note that the initrd is installed by linuxrc, not lrpkg -I. Eric Hi folks I have multiple LEAF systems on the same hardware booting from the same medium. This requires the use of different initrd files, I call the secondary file initrd2.lrp. In the backup menu this is displayed correctly whereas in the /var/lib/lrpkg directory the corresponding files are still named initrd. This is because these files are not built/named dynamically but are contained in the initrd file itself (as they are in all other .lrp packages) It might be nice if the files controlling the backup could be dynamically named (as the backup target is). This could be done rather easily with the files loaded by lrpkg -i, it may be a trifle more tricky for initrd though. I am tempted to do this for my recent system. Thoughts 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 --- 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] Glitch in initrd backup when using alternative initrd file
Hi Eric Eric Spakman wrote: Hi Erich, The question is, how useful is it to backup initrd? Life could be made very easy when the option to backup initrd is removed. There are different initrd packages which makes booting of of most systems possible (floppy, usb, cdrom and hd) and if anything is missing a new initrd can be added. OK, I can agree on that, then why not remove the option of backing up initrd entirely? If one can specify initrd at boot _and_ there is anoption to back it up, then IMHO it should work. Note that the initrd is installed by linuxrc, not lrpkg -I. If I am not mistaken, initrd is read by the kernel at boot, is it installed one more time? 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] Glitch in initrd backup when using alternative initrdfile
Hi Erich, The question is, how useful is it to backup initrd? Life could be made very easy when the option to backup initrd is removed. There are different initrd packages which makes booting of of most systems possible (floppy, usb, cdrom and hd) and if anything is missing a new initrd can be added. OK, I can agree on that, then why not remove the option of backing up initrd entirely? If one can specify initrd at boot _and_ there is anoption to back it up, then IMHO it should work. That's what I meant ;-) If that option is removed, the initrd can also made smaller, because the code needed to backup (mkfs.minix) can be removed. Note that the initrd is installed by linuxrc, not lrpkg -I. If I am not mistaken, initrd is read by the kernel at boot, is it installed one more time? You are right, what I meant is that the initrd(_*) is installed with / var/lib/lrpkg/initrd.* names at early bootstage. cheers Erich 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] Glitch in initrd backup when using alternative initrdfile
Hi Eric Eric Spakman wrote: Hi Erich, The question is, how useful is it to backup initrd? Life could be made very easy when the option to backup initrd is removed. There are different initrd packages which makes booting of of most systems possible (floppy, usb, cdrom and hd) and if anything is missing a new initrd can be added. OK, I can agree on that, then why not remove the option of backing up initrd entirely? If one can specify initrd at boot _and_ there is anoption to back it up, then IMHO it should work. That's what I meant ;-) If that option is removed, the initrd can also made smaller, because the code needed to backup (mkfs.minix) can be removed. I believe this would be the best solution. I have no problem custom tailoring my initrd, but for the average user it might be handy to have a tool to configure initrd like modules.lrp. Who would be the one to decide on this? Another question 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? thanks 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] Glitch in initrd backup when using alternative initrdfile
Hello Erich, That's what I meant ;-) If that option is removed, the initrd can also made smaller, because the code needed to backup (mkfs.minix) can be removed. I believe this would be the best solution. I have no problem custom tailoring my initrd, but for the average user it might be handy to have a tool to configure initrd like modules.lrp. I also think this is the best solution. I don't think the average user would custom tailoring its initrd, why would that be necessary? There isn't anything that I know of in the initrd which could or should be changed in the initrd by an average user. If anyone wants to change the initrd it can easely be done on a linux machine with loopmounting it. Who would be the one to decide on this? If no one objects :) Another question 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. thanks Erich 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] Glitch in initrd backup when using alternative initrdfile
Eric Spakman wrote: There currently aren't any release tags unfortuanatly. But everything in CVS is exactly 2.4.1, so if you build buildenv you would have version 2.4.1. Just to clarify - the main reason that there releases aren't tagged in CVS was not simply because of oversight, but because buildtool currently doesn't support fetching tagged files (and adding would only solve part of the problem - to be of real use, buildtool would need to support branches, so maintenance fixes would be fetched). When making a checkout from CVS, remember to use a SF developer account - synching between the real CVS server and the backup server (which is used for anonymous access) still doesn't seem to work (I infer that from the fact that commits from 2 days ago are still not visible on the backup server). 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] Glitch in initrd backup when using alternative initrdfile
Martin Martin Hejl wrote: Eric Spakman wrote: There currently aren't any release tags unfortuanatly. But everything in CVS is exactly 2.4.1, so if you build buildenv you would have version 2.4.1. Just to clarify - the main reason that there releases aren't tagged in CVS was not simply because of oversight, but because buildtool currently doesn't support fetching tagged files (and adding would only solve part of the problem - to be of real use, buildtool would need to support branches, so maintenance fixes would be fetched). Thanks for the clarification. The release tags would not hurt though. When making a checkout from CVS, remember to use a SF developer account - synching between the real CVS server and the backup server (which is used for anonymous access) still doesn't seem to work (I infer that from the fact that commits from 2 days ago are still not visible on the backup server). M... without release tags noone can be sure to fetch code that _exactly_ matches a certain version, unless you publish a catalog with all individual file versions. It would be a lot of work though. 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] Glitch in initrd backup when using alternative initrdfile
Hi Erich, Thanks for the clarification. The release tags would not hurt though. Sure. When making a checkout from CVS, remember to use a SF developer account - synching between the real CVS server and the backup server (which is used for anonymous access) still doesn't seem to work (I infer that from the fact that commits from 2 days ago are still not visible on the backup server). M... without release tags noone can be sure to fetch code that _exactly_ matches a certain version, unless you publish a catalog with all individual file versions. It would be a lot of work though. Actually, (from a CVS perspective, not that buildtool has support for that) it's quite easy. Simply check out by date (the date of a release is known after all). But as I said, without branching you would get the exact state of the CVS at that point in time, rather than the release plus maintenance/security fixes. 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] Glitch in initrd backup when using alternative initrdfile
Martin Hejl wrote: Hi Erich, Thanks for the clarification. The release tags would not hurt though. Sure. When making a checkout from CVS, remember to use a SF developer account - synching between the real CVS server and the backup server (which is used for anonymous access) still doesn't seem to work (I infer that from the fact that commits from 2 days ago are still not visible on the backup server). M... without release tags noone can be sure to fetch code that _exactly_ matches a certain version, unless you publish a catalog with all individual file versions. It would be a lot of work though. Actually, (from a CVS perspective, not that buildtool has support for that) it's quite easy. Simply check out by date (the date of a release is known after all). But as I said, without branching you would get the exact state of the CVS at that point in time, rather than the release plus maintenance/security fixes. Right, so you are all working in one linear branch. However, inserting a release tag would not hurt current operation at all, even if it cannot be handled by buildtool to date. 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
[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] Glitch in initrd backup when using alternative initrdfile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Hejl wrote: Eric Spakman wrote: There currently aren't any release tags unfortuanatly. But everything in CVS is exactly 2.4.1, so if you build buildenv you would have version 2.4.1. Just to clarify - the main reason that there releases aren't tagged in CVS was not simply because of oversight, but because buildtool currently doesn't support fetching tagged files (and adding would only solve part of the problem - to be of real use, buildtool would need to support branches, so maintenance fixes would be fetched). When making a checkout from CVS, remember to use a SF developer account - synching between the real CVS server and the backup server (which is used for anonymous access) still doesn't seem to work (I infer that from the fact that commits from 2 days ago are still not visible on the backup server). This might be one benefit to subversion. tags and branches in subversion are not special case items, as they are in CVS, but full-fledged repositories in their own right. Assuming buildtool could talk to a subversion repository, it would be a simple matter of specifying the appropriate base repository in a config file somewhere and any desired version (with applicable patches/updates, if it's been maintained) can be built. The difference would be simply (using the somewhat standard CVS-like repository layout): Latest Version: base-URL/trunk Previous release version with updates: base-URL/branches/v1.2.3 Previous release snapshot: base-URL/tags/v1.x.y ...also, since branches and tags are free (zero-copy) in subversion, they don't suffer from the performance penalties encountered with CVS, meaning it's faster/easier to create them as well as easier to use them, so they're more likely to be properly taken advantage of. - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEW3RWLywbqEHdNFwRAp85AKCo4C8FwJLNz/43aY/DgeaQz9lVPwCfS6T0 n8ztyvK2IEpIkRb8eSlTH4U= =vOkC -END PGP SIGNATURE- --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] CVS tags
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] Glitch in initrd backup when using alternative initrdfile
Hi Charles, This might be one benefit to subversion. It might be (I don't know, I've not used subversion so far). But the problem I see for buildtool is not so much that it's too hard to fetch a file for a specific branch, but rather that buildtool currently isn't fetching anything other than HEAD. So, one would have to make pretty much the same changes to buildtool, wether we're using subversion or not. Wether the url created is base-URL/tags/something/filename (for subversion) or base-URLfilename?rev=HEADonly_with_tag=something (for viewcvs) seems to be an implementation detail to me. Actually, that could be something to try: * add a branch in CVS for each release * append only_with_tag=something to each URL to fetch from viewcvs (based on wether the user supplied a branch tag or not). Of course, this would only work if the initial checkout of buildtool was done for the right branch too. This _could_ work (basically, it's along the lines of what Erich suggested). ...also, since branches and tags are free (zero-copy) in subversion, they don't suffer from the performance penalties encountered with CVS, meaning it's faster/easier to create them as well as easier to use them, so they're more likely to be properly taken advantage of. Add to that the fact that the subversion servers might work reliably more often than the CVS servers. The reason I'm not spending my evenings trying to port everything to subversion is not because I think CVS is superior to subversion (I know it fixes some of the issues CVS has) - it's simply that the benefits we might get don't outweigh the amount of time that would be needed to do the port (to me, I'm not speaking for anybody but myself - somebody else might have other priorities, and possibly also more spare time, and might even get a kick out of switching one source control system with another. To me, a source control system is simply a tool to do a job, and unless it causes more pain that it's worth, I'm unlikely to change it, unless I am _extremely_ bored). 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] Glitch in initrd backup when using alternative initrdfile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Hejl wrote: Hi Charles, This might be one benefit to subversion. It might be (I don't know, I've not used subversion so far). But the problem I see for buildtool is not so much that it's too hard to fetch a file for a specific branch, but rather that buildtool currently isn't fetching anything other than HEAD. So, one would have to make pretty much the same changes to buildtool, wether we're using subversion or not. Wether the url created is base-URL/tags/something/filename (for subversion) or base-URLfilename?rev=HEADonly_with_tag=something (for viewcvs) seems to be an implementation detail to me. Actually, that could be something to try: * add a branch in CVS for each release * append only_with_tag=something to each URL to fetch from viewcvs (based on wether the user supplied a branch tag or not). Of course, this would only work if the initial checkout of buildtool was done for the right branch too. This _could_ work (basically, it's along the lines of what Erich suggested). You don't understand how subversion works. It's like a file-system and making a tag or branch is like copying a directory. Everything underneath is copied too. Sorry for the long e-mail...executive summary: *HEAD* (latest version on this branch) is not the same as *TRUNK* (main-line development branch), at least in subversion. :) A brief example, start with a minimal subversion repository, accessed via the following url: https://my.svn.org/svn/ Now let's add a project (bering-uclibc) and the 'default' structure used when importing stuff from CVS. We now have the following URLs: https://my.svn.org/svn/bering-uclibc/ https://my.svn.org/svn/bering-uclibc/branches/ https://my.svn.org/svn/bering-uclibc/tags/ https://my.svn.org/svn/bering-uclibc/trunk/ After adding lots of stuff to the repository (under trunk/), you've got a major release ready: https://my.svn.org/svn/bering-uclibc/trunk/dir1 https://my.svn.org/svn/bering-uclibc/trunk/file1 https://my.svn.org/svn/bering-uclibc/trunk/file2 https://my.svn.org/svn/bering-uclibc/trunk/... You're now ready to make a branch, so you do a *COPY* within subersion: Copy from: https://my.svn.org/svn/bering-uclibc/trunk/ ...to: https://my.svn.org/svn/bering-uclibc/branches/Release_1.0 Now you have: https://my.svn.org/svn/bering-uclibc/Release_1.0/dir1 https://my.svn.org/svn/bering-uclibc/Release_1.0/file1 https://my.svn.org/svn/bering-uclibc/Release_1.0/file2 https://my.svn.org/svn/bering-uclibc/Release_1.0/... So...you can set the repository root in buildtool to either: https://my.svn.org/svn/bering-uclibc/trunk/ ...or... https://my.svn.org/svn/bering-uclibc/Release_1.0/ ...and *BOTH* will work just the same, without buildtool knowing anything about revision numbers. The caveat is that you will always get the *HEAD* of the particular branch you're using, but you don't always have to get the *TRUNK*. NOTE: The initial copy in subversion is fast and 'free' (doesn't take any extra repository space). Only changes to the resulting branches increase the repository size, and it should go without saying (but I'll say it anyway! :) that after copying, changes made to one branch (ie: trunk/file1) will not affect another branch (ie: branches/Release_1.0) unless you explicitly merge the changes (with the various merge commands or by manually backporting). - -- Charles Steinkuehler [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEW7HHLywbqEHdNFwRAhmQAKDwiBmaCdJ7/dk3a9tu/vjxPNknCgCeIsYS n9/hPyqmxVTDinQ5h0SKsig= =qOdf -END PGP SIGNATURE- ___ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [leaf-devel] 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] Glitch in initrd backup when using alternative initrdfile
Hi Charles, You don't understand how subversion works. I never claimed otherwise ;-) It's like a file-system and making a tag or branch is like copying a directory. Everything underneath is copied too. Well, to me, the way things are stored in the backend are pretty much meaningless (looking at CVS from an API point of view, one would never guess that it stores diffs). I'll repeat, that all I know about subversion is hearsay, but from what I heard, the command line interface can be used pretty much interchangeably instead of cvs - so how exactly does it matter that subversion handles branches differently internally? It seems that the difference you're referring to below is mainly in the web-interface (from a user's perspective), right? So...you can set the repository root in buildtool to either: https://my.svn.org/svn/bering-uclibc/trunk/ ...or... https://my.svn.org/svn/bering-uclibc/Release_1.0/ From what you describe, it would indeed make it a lot easier to add support for building something for a specific branch in buildtool. and it should go without saying (but I'll say it anyway! :) that after copying, changes made to one branch (ie: trunk/file1) will not affect another branch (ie: branches/Release_1.0) unless you explicitly merge the changes (with the various merge commands or by manually backporting). Well, I guess that's what branches are all about ;-) Martin -- You think that's tough? Try herding cats! ___ 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
