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
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] 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] 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] 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
