Hi there, As recently pointed out by Fredrik [1] the demand for 64-bit OSes is only getting bigger, and as more and more of us have access to 64-bit hardware it would be nice to work towards an official crux 64-bit port. To prepare for this, we've discussed about the possible ways to manage ports, and came up with the following suggestion: - we'll keep separate core-x86_64.git and opt-x86_64.git - we'll add post commit hooks to all repositories, allowing to track changes to a port easily - ports will appear in opt-x86_64.git because they have a maintainer on this platform, not because they're in opt.git In other words, there won't be an automatic way to merge changes, however in most situations updates should be straight forward anyway, and for the rest I'd suggest to write a script which fetches the primary port, and runs some merge tool. I also suggest that we use the term "primary maintainer" (tracks upstream & makes the call whether a release should be used in CRUX, equivalent to the current maintainer) and "arch maintainer" (tracks the primary port). Being an arch maintainer should be a lot less work, and might in the future also be a good way to get into CRUX. In order to get things going, it would be nice to hear how many of you would be willing to help on this project. We can probably start with one of the existing 64-bit versions, so the initial release should be ready fairly quickly. More interesting would be to get a feeling what the costs of maintaining ports on two platforms are. Looking forward to hearing from you. Thanks, Johannes [1] http://crux.nu/bugs/index.php?do=details&task_id=280 -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Mon, Jun 16, 2008 at 08:35:26 +0200, Johannes Winkelmann wrote: [...]
In other words, there won't be an automatic way to merge changes, however in most situations updates should be straight forward anyway, and for the rest I'd suggest to write a script which fetches the primary port, and runs some merge tool. I've quickly put together a script that fetches a port from another arch, and runs diff: http://jw.smts.ch/files/crux/get_port Adding hooks similar to rejmerge (merge/keep/overwrite) would be fairly easy.
Will of course not work for 'x86_64' for now, since there's git repo (and thus no rsyncable directory) available. Regards, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
Johannes Winkelmann [2008-06-16 09:44]:
On Mon, Jun 16, 2008 at 08:35:26 +0200, Johannes Winkelmann wrote: [...]
In other words, there won't be an automatic way to merge changes, however in most situations updates should be straight forward anyway, and for the rest I'd suggest to write a script which fetches the primary port, and runs some merge tool. I've quickly put together a script that fetches a port from another arch, and runs diff: http://jw.smts.ch/files/crux/get_port Adding hooks similar to rejmerge (merge/keep/overwrite) would be fairly easy.
Will of course not work for 'x86_64' for now, since there's git repo (and thus no rsyncable directory) available.
I've set up {core,opt,xorg}-x86_64.git today. So opt.rsync looks like this eg: host=crux.nu collection=ports/crux-2.4/opt-x86_64/ destination=/usr/ports/opt ... so just append "-x86_64" to the URLs ;) The repos are still pretty empty, but will probably be populated soonish :D Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Hello, Johannes. On Mon, 16 Jun 2008 08:35:26 +0200 Johannes Winkelmann <jw@smts.ch> wrote:
In order to get things going, it would be nice to hear how many of you would be willing to help on this project.
We can probably start with one of the existing 64-bit versions, so the initial release should be ready fairly quickly. More interesting would be to get a feeling what the costs of maintaining ports on two platforms are.
It would be great to see CRUX being actively maintained on amd64. It's good time to join efforts and produce a well-supported version. I can offer my help (at least) in testing server-side software ports (still don't have a spare amd64 workstation with X server nearby). I am not a developer, but it is a kind of topic some users might be interested in. Should we involve others not subscribed to crux-devel at some point? By the way, is there any job/task list planned? -- Mikhail Kolesnik ICQ: 260259143 IRC: mike_k at freenode/#crux, rusnet/#yalta
Hi Mikhail, On Tue, Jun 17, 2008 at 12:48:23 +0300, Mikhail Kolesnik wrote:
Hello, Johannes. [...] It would be great to see CRUX being actively maintained on amd64. It's good time to join efforts and produce a well-supported version.
I can offer my help (at least) in testing server-side software ports (still don't have a spare amd64 workstation with X server nearby). Cool, that's good to hear.
I am not a developer, but it is a kind of topic some users might be interested in. Should we involve others not subscribed to crux-devel at some point? Since we want to get a feeling whether the approach works out, we'll definitely need some testers once we're familiar (and happy!) with the setup.
That said, at this point in time this is a purely technical experiment, and there's a lot of open, non-technical questions which have to be answered
By the way, is there any job/task list planned? Not so far, but maybe we can start it here:
- decide which CRUX64 version we want to start with (pure vs multilib) - set up the git repositories - set up the git commit hooks to allow arch maintainers tracking other arch's ports - get a feeling of maintaining arch ports Once that's done and if we're happy with it, we should announce the test run to crux@ and ask for testers. At the same time, we can start discussion about the structure of the project, i.e. how archs should be coordinated etc. Once that's clear (and assuming all goes well), we can hopefully put out a 2.5 release supporting both 32 and 64 bit x86 :-). That's just my personal view BTW :-). Cheers, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
A pure 64Bit version or 32 and 64 multilib? The first will be very easy. I working with my crux 64bit Version since over one year. I have only 30 new / different ports. Just get them if you like. http://ecarux.de/crux86_64/
Hannes Mayer [2008-06-17 16:20]: Hi Hannes,
A pure 64Bit version or 32 and 64 multilib? The first will be very easy. I working with my crux 64bit Version since over one year. I have only 30 new / different ports. Just get them if you like. http://ecarux.de/crux86_64/
At the moment it looks like we'll be getting started with an updated version of your ISO, i.e. a pure 64 bit system. I don't know yet whether a multilib system would be better[tm]; we'll have to make up our minds later on this one :) Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Tue, 17 Jun 2008 18:27:37 +0200 Tilman Sauerbeck <tilman@crux.nu> wrote:
Hannes Mayer [2008-06-17 16:20]:
Hi Hannes,
A pure 64Bit version or 32 and 64 multilib? The first will be very easy. I working with my crux 64bit Version since over one year. I have only 30 new / different ports. Just get them if you like. http://ecarux.de/crux86_64/
At the moment it looks like we'll be getting started with an updated version of your ISO, i.e. a pure 64 bit system.
I don't know yet whether a multilib system would be better[tm]; we'll have to make up our minds later on this one :)
Sure pure64 has it's advantages in that it's a single library set, but there are a number of sacrifices you have to be willing to make in terms of applications that are 32 bit only. Of course flash and acroread come to mind. But there's also proprietary media codecs, you can also say goodbye to wine, and any games out there you might like to play. Until recently there was no java plugin for 64 bit browsers as well. However I just discovered that RedHat is developing one in OpenJDK. Personally I feel rather than targeting a specific alternative platform, we should be coming up with a solution for any number of systems. We have had people targeting other systems other than amd64 such as a port to openbsd and even versions for the PPC and ARM processor. While I'll be the first to agree that my multiarch solution is probably not the best, however, it has allowed me to keep in sync with the official crux repos with relative ease as it makes changes required of me to make minimal, git merges are always conflict free aswell. I have a set of 110 ports that require compat32 and or x86_64 changes across core/opt/xorg/contrib. Most of time I will only need to edit these is when there is a change to the build script otherwise it's just a matter of fetch/merge/push. Again, I think a more holistic approach should be taken if CRUX officially decided to adopt another platform such as amd64. -- Lucas Hazel <lucas@die.net.au>
Lucas Hazel [2008-06-18 12:35]:
On Tue, 17 Jun 2008 18:27:37 +0200 Tilman Sauerbeck <tilman@crux.nu> wrote:
Hannes Mayer [2008-06-17 16:20]:
Hi Hannes,
A pure 64Bit version or 32 and 64 multilib? The first will be very easy. I working with my crux 64bit Version since over one year. I have only 30 new / different ports. Just get them if you like. http://ecarux.de/crux86_64/
At the moment it looks like we'll be getting started with an updated version of your ISO, i.e. a pure 64 bit system.
I don't know yet whether a multilib system would be better[tm]; we'll have to make up our minds later on this one :)
Sure pure64 has it's advantages in that it's a single library set, but there are a number of sacrifices you have to be willing to make in terms of applications that are 32 bit only. Of course flash and acroread come to mind. But there's also proprietary media codecs, you can also say goodbye to wine, and any games out there you might like to play. Until recently there was no java plugin for 64 bit browsers as well. However I just discovered that RedHat is developing one in OpenJDK.
True... I still need to finish Doom3, and I probably don't want to wait until it's GPLd :|
Personally I feel rather than targeting a specific alternative platform, we should be coming up with a solution for any number of systems. We have had people targeting other systems other than amd64 such as a port to openbsd and even versions for the PPC and ARM processor.
While I'll be the first to agree that my multiarch solution is probably not the best, however, it has allowed me to keep in sync with the official crux repos with relative ease as it makes changes required of me to make minimal, git merges are always conflict free aswell.
I have a set of 110 ports that require compat32 and or x86_64 changes across core/opt/xorg/contrib. Most of time I will only need to edit these is when there is a change to the build script otherwise it's just a matter of fetch/merge/push.
Again, I think a more holistic approach should be taken if CRUX officially decided to adopt another platform such as amd64.
We'd like to achieve omg-awesome portability (I care much more about other architectures than operating systems though). Hopefully the scheme we have in mind will allow for the needed flexibility. We have of course looked at your multiarch solution, but found it to be kind of ugly. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Wed, 18 Jun 2008 17:06:42 +0200 Tilman Sauerbeck <tilman@crux.nu> wrote:
We'd like to achieve omg-awesome portability (I care much more about other architectures than operating systems though). Hopefully the scheme we have in mind will allow for the needed flexibility.
Is it just me or does there appear to be a "CRUX SECRET UNDERGROUND", it seems there's a lot of discussion that doesn't even make it to -devel...
We have of course looked at your multiarch solution, but found it to be kind of ugly.
Well yeah, it is kinda ugly I guess. But it did make life easy for me by allowing automatic merging with the official repos, and being perhaps the only 64bit multilib CRUX user I'm sure the reasons for such a feature are apparent. I initially looked at using the repo-per-architecture setup, but there was too much hand editing involved, I had to essentially edit 2 ports every time there was a version change. This also made writing compat32 ports rather tedious. But it seems this is the way we are going, so I guess I'll start splitting up my multiarch repos. Perhaps git-rebase -i can make merging a bit less hassle. -- Lucas Hazel <lucas@die.net.au>
Lucas Hazel [2008-06-19 01:42]:
On Wed, 18 Jun 2008 17:06:42 +0200 Tilman Sauerbeck <tilman@crux.nu> wrote:
We'd like to achieve omg-awesome portability (I care much more about other architectures than operating systems though). Hopefully the scheme we have in mind will allow for the needed flexibility.
Is it just me or does there appear to be a "CRUX SECRET UNDERGROUND", it seems there's a lot of discussion that doesn't even make it to -devel...
Johannes and me had a private chat about this crux64 test thingie a couple of days ago. It was a little bit undergroundish, but since the topic made it to the list I don't feel very bad ;o Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
participants (5)
-
Hannes Mayer -
Johannes Winkelmann -
Lucas Hazel -
Mikhail Kolesnik -
Tilman Sauerbeck