[Clc-crux64] New x86_64 iso available!
Hi all! finished up with my latest x86_64 crux iso! i think it's pretty clean this time. should work just like the vanilla crux installation -- nothing special to do other than follow the normal crux install directions. you can find the iso, as well as my base64.httpup, opt64.httpup, and a readme at: http://www.samnjack.com/crux-amd64 (please be gentle with my bandwith!) Here's the readme: README FOR CRUX64-2.1RC1 The iso image and ports available here are built for the x86_64 architecture only. The iso will not boot on any other architecture, and the ports will not run on any other architecture. They were built on an amd64 3000 development box, using generic x86_64 optimizations; that being said, I _think_ it should boot and install on ia64 architecture, but I have no way of testing. This release aims to remain as close to "vanilla" crux as possible. In some cases there are differences: 1. cvsup does not build on x86_64 systems, and is not included here. for port updates, we need to use httpup 2. the /lib and /usr/lib directories are symkinks to /lib64 and /usr/lib64 respectively. REMEMBER THIS! this has the consequence of breaking "pkginfo -o" when querying files in /lib64 or /usr/lib64, in cases where a port installs files to /lib or /usr/lib. 3. some default crux software packages require minor changes (to the Pkgfile, .footprint, .md5sum, or .nostrip files) for the x86_64 architecture. to accomodate these changes while preserving most of the default crux ports tree, I've decided to use an extension to the default files of .x86_64 where necessary. The pkgutils port includes two wrapper scripts to the pkgmk utility: pkgmk64 and pkgmk64-recursive. The pkgmk64 script checks for the existence of <some_file>.x86_64, and if it exists, copies the vanilla crux version to <some_file>.orig, copies <some_file>.x86_64 to <some_file>, runs pkgmk with options passed to the script, then moves the files back into place. The pkgmk64-recursive calls pkgmk64 recursively in a top-level ports directory. pkgmk64 can't be called with the "-r" option; use pkgmk64-recursive without "-r" for that purpose. This script could more than likely be adapted to a patch for pkgutils directly, which I think would be better than it's current manifestation. In fact, it could be adapted to any alternative architecture crux project, which I think would be the right thing to do. 4. at http://www.samnjack.com/crux-amd64/ are base64.httpup and opt64.httpup, which point to my x86_64 ports repository. The ports will be downloaded to the standard /usr/ports/{base,opt} locations. I will try to keep these as close to synced as possible with vanilla crux, but they will more likely than not be out of sync at some time or other. If you would like to keep up to date yourself, I recommend getting the default base.httpup and opt.httpup files, changing them to download per's ports to an alternate directory (i.e. /usr/ports/{base-i686,opt-i686}, and manually inspect and test any updates you don't get from me. BE WARNED: updating your ports with the default base.httpup and opt.httpup and running something like "prt-get sysup" may kill your system! Make sure you keep your port trees squared away! Other than that, everything ought to work just fine. If you find something terribly wrong, please inform me (you'll find my e-mail address below) or anyone else who decides to take this project on. It may be worth the effort, assuming there's more than three or four people using this, to maintain repositories of contrib and unmaintained ports that require changes for x86_64, similar to what I've done with base and opt. Time will tell. Once again, I think building into pkgutils and the ports system a true multi-arch capability would be wonderful. Maintainers of the ppc and sparc64 branches would probably agree... Thanks, and good luck! jeremy at samnjack dot com
Hi Jeremy, On Fri, Apr 08, 2005 at 15:51:40 -0600, Jeremy Jones wrote:
Hi all!
finished up with my latest x86_64 crux iso! Great!
i think it's pretty clean this time. should work just like the vanilla crux installation -- nothing special to do other than follow the normal crux install directions. you can find the iso, as well as my base64.httpup, opt64.httpup, and a readme at:
http://www.samnjack.com/crux-amd64
(please be gentle with my bandwith!) Both Per and Matt have mirror'red my sparc test images, I'm sure they'll mirror yours if you ask them (if Per answers fast enough, you don't have to bother Matt since he mirrors Per's ftp anyway ;-)).
[...]
Other than that, everything ought to work just fine. If you find something terribly wrong, please inform me (you'll find my e-mail address below) or anyone else who decides to take this project on. It may be worth the effort, assuming there's more than three or four people using this, to maintain repositories of contrib and unmaintained ports that require changes for x86_64, similar to what I've done with base and opt. Time will tell. We've discussed the introduction of subprojects at CLC, and this would definitely be a good candidate. Unfortunately, this is one of those "post 2.1" things.
Once again, I think building into pkgutils and the ports system a true multi-arch capability would be wonderful. Maintainers of the ppc and sparc64 branches would probably agree... Well, we had this discussion some time ago (and also at CRUXCon last year). At first, I was in favour of a multiarch pkgutils too, but I changed my mind. In my opinion, changes should not appear in a arch specific tree unless tested and maintained, not because it's in the $OTHERARCH tree. This implies having independently versioned trees. In order to make that process as easy as possible, the revision control system should support merging from the other branches.
I've written a very small wrapper around subversion to allow this in a (to me) logical way: http://jw.tks6.net/files/crux/xsvn/ To give you an impression what's needed, here a small excerpt how to merge a port from x86 to x86_64: First, the initial setup: #define from and to branches export XSVN_SRC_REPO=svn+ssh://svn.berlios.de/svnroot/repos/clc/x86 export XSVN_BASE_REPO=svn+ssh://svn.berlios.de/svnroot/repos/clc/x86_64 export XSVN_RELEASE=CRUX-2_0 # initial checkout mkdir ~/ports-x86_64 cd ~/ports-x86_64 svn co $XSVN_BASE_REPO/trunk cd trunk Now for the real fun part, the merge xsvn merge-from htop # <- merges port from x86 to working copy ## build port, check whether it works on x86_64, then either 'svn ## revert' or svn ci -m "commit htop to x86_64" finally, to "tag" it for a specific release of CRUX: xsvn release opt htop # add htop to x86_64, collection 'opt' Of course, this would mean that for every port on $ARCH, someone has to maintain it (even though maintainance in this case might just be a matter of checking for updates in another tree, and merging and testing those changes). CRUX PPC does it differently, they let their users use the x86 ports (at least last this discussion was help), which is unfortunate in my eyes. As for CRUX/SPARC, I don't plan to include ports which are not tested on that specific platform. I'm more than happy to provide write access to the berlios subversion tree for persons willing to test this. Unfortunately, I'm not sync'ing Per's cvs repo with subversion yet, but the script is almost done: http://jw.tks6.net/files/crux/sync2svn This would then hourly sync the x86 Subversion branch with Per's CVSUp, and allow us to maintain the other trees against it. There's another nice side effect of this: svn can be used as backend for ports(8), allowing for an efficient way to update ports since only deltas are transferred; furthermore, it's quite portable and builds just fine on sparc's, so I don't expect big problems on x86_64 either. Finally, subversion can be told to use http as transport (not at berlios unfortunately), which would solve the "behind proxy" issue of cvsup. Okay, I'm sorry this got so long, but it's one of my main projects right now since I'm planning to start maintaining a CRUX/SPARC tree in a serious way, and this is the path we've chosen. As always, feedback is highly appreciated. Kind regards and thanks for reading, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
hello jeremy just did a _successful_ install with your new iso! :) it took some work because the cd i burned was defect (as usual), and, because the handbook.txt file on the cd was just an empty file. maybe something to fix for -rc2 ? on another note, the bin86 and emacs ports in your repo are older than the ones that comes with the iso... besides that... great work! cheers, lars On Fri, April 8, 2005 11:51 pm, Jeremy Jones said:
Hi all!
finished up with my latest x86_64 crux iso! i think it's pretty clean this time. should work just like the vanilla crux installation -- nothing special to do other than follow the normal crux install directions. you can find the iso, as well as my base64.httpup, opt64.httpup, and a readme at:
http://www.samnjack.com/crux-amd64
(please be gentle with my bandwith!)
Here's the readme:
README FOR CRUX64-2.1RC1
The iso image and ports available here are built for the x86_64 architecture only. The iso will not boot on any other architecture, and the ports will not run on any other architecture. They were built on an amd64 3000 development box, using generic x86_64 optimizations; that being said, I _think_ it should boot and install on ia64 architecture, but I have no way of testing.
This release aims to remain as close to "vanilla" crux as possible. In some cases there are differences:
1. cvsup does not build on x86_64 systems, and is not included here. for port updates, we need to use httpup 2. the /lib and /usr/lib directories are symkinks to /lib64 and /usr/lib64 respectively. REMEMBER THIS! this has the consequence of breaking "pkginfo -o" when querying files in /lib64 or /usr/lib64, in cases where a port installs files to /lib or /usr/lib. 3. some default crux software packages require minor changes (to the Pkgfile, .footprint, .md5sum, or .nostrip files) for the x86_64 architecture. to accomodate these changes while preserving most of the default crux ports tree, I've decided to use an extension to the default files of .x86_64 where necessary. The pkgutils port includes two wrapper scripts to the pkgmk utility: pkgmk64 and pkgmk64-recursive. The pkgmk64 script checks for the existence of <some_file>.x86_64, and if it exists, copies the vanilla crux version to <some_file>.orig, copies <some_file>.x86_64 to <some_file>, runs pkgmk with options passed to the script, then moves the files back into place. The pkgmk64-recursive calls pkgmk64 recursively in a top-level ports directory. pkgmk64 can't be called with the "-r" option; use pkgmk64-recursive without "-r" for that purpose. This script could more than likely be adapted to a patch for pkgutils directly, which I think would be better than it's current manifestation. In fact, it could be adapted to any alternative architecture crux project, which I think would be the right thing to do. 4. at http://www.samnjack.com/crux-amd64/ are base64.httpup and opt64.httpup, which point to my x86_64 ports repository. The ports will be downloaded to the standard /usr/ports/{base,opt} locations. I will try to keep these as close to synced as possible with vanilla crux, but they will more likely than not be out of sync at some time or other. If you would like to keep up to date yourself, I recommend getting the default base.httpup and opt.httpup files, changing them to download per's ports to an alternate directory (i.e. /usr/ports/{base-i686,opt-i686}, and manually inspect and test any updates you don't get from me. BE WARNED: updating your ports with the default base.httpup and opt.httpup and running something like "prt-get sysup" may kill your system! Make sure you keep your port trees squared away!
Other than that, everything ought to work just fine. If you find something terribly wrong, please inform me (you'll find my e-mail address below) or anyone else who decides to take this project on. It may be worth the effort, assuming there's more than three or four people using this, to maintain repositories of contrib and unmaintained ports that require changes for x86_64, similar to what I've done with base and opt. Time will tell.
Once again, I think building into pkgutils and the ports system a true multi-arch capability would be wonderful. Maintainers of the ppc and sparc64 branches would probably agree...
Thanks, and good luck!
jeremy at samnjack dot com
_______________________________________________ Clc-crux64 mailing list Clc-crux64@lists.berlios.de http://lists.berlios.de/mailman/listinfo/clc-crux64
participants (3)
-
Jeremy Jones -
Johannes Winkelmann -
Lars Helmer