Re: [Cooker] Development extranet for non-intel builds [ALPHA:SPARC:PPC:X86_64]
On Sun, Jun 08, 2003 at 12:49:30PM +0200, Marcel Pol wrote: I also have an oldworld PowerMac 185 Mhz, 96 Mb ram. It's mostly too slow to compile anything, but it does run cooker. I believe Ben Reser has a few ppc machines, but I don't know if he runs cooker on it. I've tried to run cooker on PPC. It's normally so seriously broken that it is utterly unusable. I don't have many PPC boxes so I run stable releases. Additionally I don't have tons of disk space on them to throw at cooker. I already have to maintain 8.2/PPC and 9.1/PPC on them for security update testing. Since only myself and Vincent are the only people who do PPC testing I set that as a priority over cooker. Regarding SPARC, I have several Ultra Sparcs but they're otherwise occupied with other operating systems. I might be willing to run a chroot under it for building Mandrake and switch to running Mandrake if we get a stable release, but I'm only really interested in doing that if we are going to have a officially supported release (meaning security updates). If we don't do that it's more work than it is worth to me. Especially given the fact that very few people use Sparcs for desktop machines and that is what most people see Mandrake as. -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org What upsets me is not that you lied to me, but that from now on I can no longer believe you. -- Nietzsche
Re: [Cooker] Development extranet for non-intel builds [ALPHA:SPARC:PPC:X86_64]
On Sun Jun 08, 2003 at 09:49:20AM +0200, Stefan van der Eijk wrote:
Also, don't forget updates. Unless the people who build these ports are
willing to maintain a system/chroot/whatever dedicated for 18mos for
building updates for these ports, it won't happen. As Stefan says, making
this stuff official means it needs to be maintained; without having
access
to these various machines for the duration of the lifecycle, it's not even
worth starting it.
Yes.
That being said, there is nothing from stopping a community built/community
hosted unofficial port; the community builds the port, the community
maintains the port, and MandrakeSoft doesn't have any official dealings
with
it (ie. the community completely and 100% supports it themselves).
Yes.
Glad you understnad this... hopefully, others will understand this as well.
For alpha, mips, pa-risc, and sparc, I think that would be the best shot.
You could like talk ibiblio or someone into hosting the port if you wanted
to make an unofficial 9.2/pa-risc release (or whatever).
We first need to get our act together :-) The alpha port is still on the
mdk mirrors at the moment. I can imaging that mdk perhaps won't do the
same for the other ports that have sprung up lately.
Well, you never know. There could be a clear Mandrake-unsupported
directory. Or it could be something that people need to contact ibiblio or
something directly. That's probably the least of your concerns right now.
For PPC, I'd love to see it released in tangent with x86 (as well as x86-64
and ia64 I guess).
Yes. Have release schedules been published for these products?
Not to my knowledge.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
lynx -source http://linsec.ca/vdanen.asc | gpg --import
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp0.pgp
Description: PGP signature
Re: [Cooker] Development extranet for non-intel builds [ALPHA:SPARC:PPC:X86_64]
But, we might be getting to the point where we actually need a cooker extranet. For example, I would like to be able to remove build output on an automated build host to get a package rebuilt, but we wouldn't want anyone to be able to remove build output ... It seems installer need works on sparc/alpha; Guillaume Cottenceau seems to agree about working on port be he need a computer to test, of course. About network, I have an athlon as frontend which host chroot for plf, it have lot of disk space, host unique home/repository for all development (i586/ppc/sparc). I've got a ix86 box as frontend. Mirrors directly off of mdk. It's behind a cablemodem (down: 1.5Mbit, up 128kbit). I've got a second ix86 in an Internet datacentre doing nothing at the moment. About buildoutput, I have a personnal script to rebuild package on ppc/sparc. log are put in a directory, maybe we can a unique repository where all rebuilder can upload automatically those files. With a standard convention naming for automatically removing obsoletes log. I suggest we merge the scripts in the near future. Well, SPARC's (and at some point Alpha and Opteron 240 SMP) at CSC are on private network behind 9.1 i586 box. I can't see anything that should stop us from creating the extranet and have the builds automated and coordinated. Some centralised user authentication might be a good idea at some point if we have more developers. The only drawback would be probably the fact, that single development machines without dedicated front-end might need some more work to configure everything, but I think that it'll be worth it. Stefan? Olivier? Gwenole? What do you think? At the moment, to my knowledge we have the following machines _dedicated_ to non-intel cooker development (please, developers, fill in all blanks): Alpha - 2 x XP1000 - CSC still 7.1b - need help with this - 1 x PWS433au - Stefan Van Der Eijk - 1 x PCI33 - mpol - 1 x ??? - Juan - 1 x DP264 - Paris office (same as Juan's?) - others? SPARC - 1 x SparcStation 10 SMP - Olivier Thauvin - 1 x SparcClassic - CSC (unused - 32 bit system) - 2 x Ultra 10 - CSC - 1 x Ultra 5 - CSC - others? PPC - 1 x Titanium G4 500, 512 Mo Ram - Olivier Thauvin - others? x86_64 - 1 x Dual Opteron 240 - CSC (ETA 15 days) - others? PA-RISC - 1 x HP 9000 D-class model D390/800 - Stefan van der Eijk (on loan during the summer) I have one HP box but don't know if linux can run on it. Will looking. I booted the debian installer on it yesterday. So it should run Linux. The box has 2* 8200 CPU's (240MHz, 4Mb cache each), 1Gb RAM and 2* 9Gb disk. And it's huge (60*26*55cm) heavy (45kg). I wasn't seriously thinking about porting mdk to it. The plan was to install debian and hand it back to it's owner (the local scouting group) but since they don't need it till after the summer, I might try mdk anyway :-) MIPS - 1 x SGI IRIS Indigo - Stefan van der Eijk (RAM defect?) This box is probably too slow to do anything usefull. I think, that only computers solely dedicated (i.e. not used in any other way) may be listed here and eventually included in the extranet. Because CSC uses Mandrake on all workstations and servers, and we're very happy with it (kudos to both cooker and core development teams!) our position is to support development of the distribution by providing hardware and network resources in return. Naturally we're aware that hosting the machines is serious commitment (especially sustaining the support over time) and we're ready to fulfil it. Maybe if we manage to pull this off before 9.2 and have all the packages rebuilt, MandrakeSoft will be interested in releasing 9.2 for i586, x86_64, Alpha, Sparc64 and PPC? IMHO Releasing means supporting. supporting a product requires an organisation and knowledge being available. It also needs to be worthwhile -- bring some $$$ to the company. For the alpha, mips, pa-risc and sparc the market is too small. Right, but look at ppc, mandrake exactly the same product as you can find on mirror ( 3 isos ). Mandrake never make somethings to promote the distro on non i586. They can't -- they won't have the resources to support it and it won't be profitable. I think making an installable distro for sparc/alpha/ppc will make publicity and prove a mandrake activity. Perhaps. Since I'm more or less the maintainer of the alpha port, I've had some interesting discussions with mdk employees on this topic. I don't have the illusion that the alpha port will ever turn into a product that will be supported and even bring revenue to mdk. I see it as my personal research project -- I want to prove that maintaining multiple ports can be done efficiently... /IMHO Well maybe I can explain why I restart sparc ports: - I like play - I like to works on non standards things. Is it usefull, not sure ;) Wouldn't it be the first commercial distribution (in couple of years) that allows to run the same system across 5
Re: [Cooker] Development extranet for non-intel builds [ALPHA:SPARC:PPC:X86_64]
IMHO Releasing means supporting. supporting a product requires an organisation and knowledge being available. It also needs to be worthwhile -- bring some $$$ to the company. For the alpha, mips, pa-risc and sparc the market is too small. Since I'm more or less the maintainer of the alpha port, I've had some interesting discussions with mdk employees on this topic. I don't have the illusion that the alpha port will ever turn into a product that will be supported and even bring revenue to mdk. I see it as my personal research project -- I want to prove that maintaining multiple ports can be done efficiently... /IMHO Also, don't forget updates. Unless the people who build these ports are willing to maintain a system/chroot/whatever dedicated for 18mos for building updates for these ports, it won't happen. As Stefan says, making this stuff official means it needs to be maintained; without having access to these various machines for the duration of the lifecycle, it's not even worth starting it. Yes. That being said, there is nothing from stopping a community built/community hosted unofficial port; the community builds the port, the community maintains the port, and MandrakeSoft doesn't have any official dealings with it (ie. the community completely and 100% supports it themselves). Yes. For alpha, mips, pa-risc, and sparc, I think that would be the best shot. You could like talk ibiblio or someone into hosting the port if you wanted to make an unofficial 9.2/pa-risc release (or whatever). We first need to get our act together :-) The alpha port is still on the mdk mirrors at the moment. I can imaging that mdk perhaps won't do the same for the other ports that have sprung up lately. For PPC, I'd love to see it released in tangent with x86 (as well as x86-64 and ia64 I guess). Yes. Have release schedules been published for these products? Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] Development extranet for non-intel builds [ALPHA:SPARC:PPC:X86_64]
On Sun, 08 Jun 2003 09:36:05 +0200 Stefan van der Eijk [EMAIL PROTECTED] wrote: At the moment, to my knowledge we have the following machines _dedicated_ to non-intel cooker development (please, developers, fill in all blanks): Alpha - 2 x XP1000 - CSC still 7.1b - need help with this - 1 x PWS433au - Stefan Van Der Eijk - 1 x PCI33 - mpol - 1 x ??? - Juan - 1 x DP264 - Paris office (same as Juan's?) - others? SPARC - 1 x SparcStation 10 SMP - Olivier Thauvin - 1 x SparcClassic - CSC (unused - 32 bit system) - 2 x Ultra 10 - CSC - 1 x Ultra 5 - CSC - others? PPC - 1 x Titanium G4 500, 512 Mo Ram - Olivier Thauvin I also have an oldworld PowerMac 185 Mhz, 96 Mb ram. It's mostly too slow to compile anything, but it does run cooker. I believe Ben Reser has a few ppc machines, but I don't know if he runs cooker on it. - others? x86_64 - 1 x Dual Opteron 240 - CSC (ETA 15 days) - others? PA-RISC - 1 x HP 9000 D-class model D390/800 - Stefan van der Eijk (on loan during the summer) I have one HP box but don't know if linux can run on it. Will looking. I booted the debian installer on it yesterday. So it should run Linux. The box has 2* 8200 CPU's (240MHz, 4Mb cache each), 1Gb RAM and 2* 9Gb disk. And it's huge (60*26*55cm) heavy (45kg). I wasn't seriously thinking about porting mdk to it. The plan was to install debian and hand it back to it's owner (the local scouting group) but since they don't need it till after the summer, I might try mdk anyway :-) MIPS - 1 x SGI IRIS Indigo - Stefan van der Eijk (RAM defect?) This box is probably too slow to do anything usefull. -- Marcel Pol
Re: [Cooker] Development extranet for non-Intel builds [ALPHA:SPARC:PPC:X86_64]
Hello, Thanks for the feedback on the idea. Now, I would like to summarise some points that aroused in your replies. 1) MandrakeSoft might be reluctant to take the non-Intel ports under it's wings. This of course makes sense (as Stefan noticed, support = money, and we cannot ask the company for it in it's current state). I (and I think we all do) understand this (unofficial) position and respect it. 2) We (the community) have resources to keep the cooker tree up to date, with exception of Drak* tools. Thou they are important, they're not absolutely essential for development of the port 'per se'. What we need is up to date tree of cooker, and probably plf packages. With current resources this is doable. I've seen the schedule of 9.2 and realised, that syncing ports to it would be a bit of Hercules' job. However with more machines to rebuild packages (and with centralised and automated extranet) we may be able to make it for the next release. At this point, about 12 months in the future we might be able to talk again to MandrakeSoft about possible non-official releases, that would stay community supported, but with worksing Drak* suite. Up to this point, CSC can provide required space for the ports on it's ftp server. 3) Most of the development machines are (or could be) located behind a front-end computer that would act as proposed extranet gateway and temporary storage. I think, that central storage node could be located at CSC, as we can a) guarantee the support for the system for the following 12 months by some sort of public agreement (think Debian's contract) b) provide ftp server for the ports (we have both computer and network resources to do that). 4) Machines in other locations will have the same, unrestricted access through the extranet. All rebuild packages could be automatically copied to the storage node (30GB makes sense, I think). 5) From your mail, it seems that we /MIGHT/ be able to run the porting for the following architectures: Alpha, (Mips?), PPC, Sparc64 (32?) and X86_64. 6) The access to the extranet would be granted both to community developers and core, MandrakeSoft developers. 7) It's important to realise, that even if we successfully port everything to other architectures, MandrakeSoft might not be able to offer the ports as officially supported products. In that case we should have enough resources to supply patched packages for at least 18 months. This of course is personal decision of every developer, however I would strongly encourage you to pursue this goal (again, think Debian :). Mandrake Linux has strong community and I'm sure that some of us would do it. Where do we go from here, is up to you. PS. I'm working on that XP1000 :) -- Jaroslaw Zachwieja Centre for Scientific Computing University of Warwick
Re: [Cooker] Development extranet for non-Intel builds [ALPHA:SPARC:PPC:X86_64]
2) We (the community) have resources to keep the cooker tree up to date, with exception of Drak* tools. Not all, only the ones who deals with the hardware. However with more machines to rebuild packages (and with centralised and automated extranet) we may be able to make it for the next release. what about using a cross compiler ? If done properly, people just have to install a rpm on a i586 box, and compile for alpha or mips or what they want. and, when you say a extranet, do you mean some kind of vpn, with access for the community ? if so, then using a crosscompiler and , maybe distcc will allow to have more ressources avaliaible, but i don't know if this is possible. -- Michal Scherer
Re: [Cooker] Development extranet for non-Intel builds [ALPHA:SPARC:PPC:X86_64]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sunday 08 June 2003 15:59, Michael Scherer wrote: and, when you say a extranet, do you mean some kind of vpn, with access for the community ? if so, then using a crosscompiler and , maybe distcc will allow to have more ressources avaliaible, but i don't know if this is possible. we have distcc on the sparc cluster:) - -- Regards, Per yvind Karlsen Sintrax Solutions http://www.sintrax.net - +47 41681061 - GPG Key: http://sintrax.net/~hawkeye/key.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+40lZv8F7V9JOSuURAlMDAJ44zlIoG5JAmH+TscK9AtvteUDZqwCeMn6a BLNdyWWP8yk2EOYo8wYXey4= =1Mpb -END PGP SIGNATURE-
Re: [Cooker] Development extranet for non-Intel builds [ALPHA:SPARC:PPC:X86_64]
On nie 8. czerwca 2003 14:59, Michael Scherer wrote: However with more machines to rebuild packages (and with centralised and automated extranet) we may be able to make it for the next release. what about using a cross compiler ? If done properly, people just have to install a rpm on a i586 box, and compile for alpha or mips or what they want. I'm not a software developer, but I'm not sure if using cross compiler would always work. Feel free to correct me :) and, when you say a extranet, do you mean some kind of vpn, with access for the community ? if so, then using a crosscompiler and , maybe distcc will allow to have more ressources avaliaible, but i don't know if this is possible. Yes, by extranet, I meant VPN. And as you can see, we already have distcc working on the sparcs. (Thanks Per Oyvind! :) BTW, What are our options for building the VPN? IP-IP, IP-GRE (easy to configure, but unencrypted) and IPSec (freeswan), thou I have no idea about the latter ;) Regards, -- Jaroslaw Zachwieja Centre for Scientific Computing University of Warwick
Re: [Cooker] Development extranet for non-Intel builds [ALPHA:SPARC:PPC:X86_64]
Yes, by extranet, I meant VPN. And as you can see, we already have distcc working on the sparcs. (Thanks Per Oyvind! :) Mhh, do you think that distcc could work on a vpn ? isn't there some issues about the bandwidth ? BTW, What are our options for building the VPN? IP-IP, IP-GRE (easy to configure, but unencrypted) and IPSec (freeswan), thou I have no idea about the latter ;) I suggest using openvpn ( http://openvpn.sourceforge.net/ ), and I think it has several advantages over ipsec. It is a userland software, which mean there is no need for a kernel patch it order to upgrade or to set up a new host. It is based on openssl, which allow the use of certificat, and a wide range of cryptographic algorithms. IpSec can do it too, I think. It work by using udp, which is easier to control on a firewall , and provides good performance when a tcp connection is made. It is robust, a host can be disconnected without any problem or need to reload any service. It also work when a host change his ip address. Is is portable on all unices, and of course, is free software. -- Michal Scherer
Re: [Cooker] Development extranet for non-intel builds [ALPHA:SPARC:PPC:X86_64]
On Fri, 6 Jun 2003, Jaroslaw Zachwieja wrote: At the moment, to my knowledge we have the following machines _dedicated_ to non-intel cooker development (please, developers, fill in all blanks): PPC - 1 x ?? - Olivier Thauvin - others? I've let Olivier take over cooker PPC build because our official release schedule for PPC (subject to change/review of the business needs) is every other release. My experience in 3 PPC releases is that very few people actually use PPC cooker, unless there are ISOs. So aside from personal curiosity that things build or not, it hardly seems worth the bandwidth/machine time to build cooker for PPC now, when the next release is 9 months out, if the business decides it's worth pursuing at all. While interest in all these ports is very nice, if MandrakeSoft doesn't bless them and negotiate space on the mirrors for them, then you're going to have to end up hosting them from some other server. Rebuilding packages for other arches is fairly straightforward, but in my opinion what makes the distribution Mandrake is the integration of the installer and drak tools to behave appropriately for the architecture. -- Stew Benedict
Re: [Cooker] Development extranet for non-intel builds [ALPHA:SPARC:PPC:X86_64]
Jaroslaw Zachwieja wrote: But, we might be getting to the point where we actually need a cooker extranet. For example, I would like to be able to remove build output on an automated build host to get a package rebuilt, but we wouldn't want anyone to be able to remove build output ... Well, SPARC's (and at some point Alpha and Opteron 240 SMP) at CSC are on private network behind 9.1 i586 box. I can't see anything that should stop us from creating the extranet and have the builds automated and coordinated. Some centralised user authentication might be a good idea at some point if we have more developers. The only drawback would be probably the fact, that single development machines without dedicated front-end might need some more work to configure everything, but I think that it'll be worth it. Stefan? Olivier? Gwenole? What do you think? At the moment, to my knowledge we have the following machines _dedicated_ to non-intel cooker development (please, developers, fill in all blanks): Alpha - 2 x XP1000 - CSC still 7.1b - need help with this - 1 x ?? - Stefan Van Der Eijk PWS 433au - others? mpol has an alpha. Juan has one. there used to be one at the Paris office (same as Juan's?) SPARC - 1 x SparcStation 10 SMP - Olivier Thauvin - 1 x SparcClassic - CSC (unused - 32 bit system) - 2 x Ultra 10 - CSC - 1 x Ultra 5 - CSC - others? PPC - 1 x ?? - Olivier Thauvin - others? x86_64 - 1 x Dual Opteron 240 - CSC (ETA 15 days) - others? PA-RISC - 1 x HP 9000 D-class model D390/800 - Stefan van der Eijk (on loan during the summer) MIPS - 1 x SGI IRIS Indigo - Stefan van der Eijk (RAM defect?) I think, that only computers solely dedicated (i.e. not used in any other way) may be listed here and eventually included in the extranet. Because CSC uses Mandrake on all workstations and servers, and we're very happy with it (kudos to both cooker and core development teams!) our position is to support development of the distribution by providing hardware and network resources in return. Naturally we're aware that hosting the machines is serious commitment (especially sustaining the support over time) and we're ready to fulfil it. Maybe if we manage to pull this off before 9.2 and have all the packages rebuilt, MandrakeSoft will be interested in releasing 9.2 for i586, x86_64, Alpha, Sparc64 and PPC? IMHO Releasing means supporting. supporting a product requires an organisation and knowledge being available. It also needs to be worthwhile -- bring some $$$ to the company. For the alpha, mips, pa-risc and sparc the market is too small. Since I'm more or less the maintainer of the alpha port, I've had some interesting discussions with mdk employees on this topic. I don't have the illusion that the alpha port will ever turn into a product that will be supported and even bring revenue to mdk. I see it as my personal research project -- I want to prove that maintaining multiple ports can be done efficiently... /IMHO Wouldn't it be the first commercial distribution (in couple of years) that allows to run the same system across 5 architectures? We'll have to see... :-) It would even be nice if we (the community) can maintain these ports and learn a bit have some fun... Comments/ideas anyone? smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] Development extranet for non-intel builds [ALPHA:SPARC:PPC:X86_64]
Le Samedi 07 Juin 2003 20:55, Stefan van der Eijk a écrit : Jaroslaw Zachwieja wrote: But, we might be getting to the point where we actually need a cooker extranet. For example, I would like to be able to remove build output on an automated build host to get a package rebuilt, but we wouldn't want anyone to be able to remove build output ... It seems installer need works on sparc/alpha; Guillaume Cottenceau seems to agree about working on port be he need a computer to test, of course. About network, I have an athlon as frontend which host chroot for plf, it have lot of disk space, host unique home/repository for all development (i586/ppc/sparc). About buildoutput, I have a personnal script to rebuild package on ppc/sparc. log are put in a directory, maybe we can a unique repository where all rebuilder can upload automatically those files. With a standard convention naming for automatically removing obsoletes log. Well, SPARC's (and at some point Alpha and Opteron 240 SMP) at CSC are on private network behind 9.1 i586 box. I can't see anything that should stop us from creating the extranet and have the builds automated and coordinated. Some centralised user authentication might be a good idea at some point if we have more developers. The only drawback would be probably the fact, that single development machines without dedicated front-end might need some more work to configure everything, but I think that it'll be worth it. Stefan? Olivier? Gwenole? What do you think? At the moment, to my knowledge we have the following machines _dedicated_ to non-intel cooker development (please, developers, fill in all blanks): Alpha - 2 x XP1000 - CSC still 7.1b - need help with this - 1 x ?? - Stefan Van Der Eijk PWS 433au - others? mpol has an alpha. Juan has one. there used to be one at the Paris office (same as Juan's?) SPARC - 1 x SparcStation 10 SMP - Olivier Thauvin - 1 x SparcClassic - CSC (unused - 32 bit system) - 2 x Ultra 10 - CSC - 1 x Ultra 5 - CSC - others? PPC - 1 x ?? - Olivier Thauvin Titanium G4 500, 512 Mo Ram - others? x86_64 - 1 x Dual Opteron 240 - CSC (ETA 15 days) - others? PA-RISC - 1 x HP 9000 D-class model D390/800 - Stefan van der Eijk (on loan during the summer) I have one HP box but don't know if linux can run on it. Will looking. MIPS - 1 x SGI IRIS Indigo - Stefan van der Eijk (RAM defect?) I think, that only computers solely dedicated (i.e. not used in any other way) may be listed here and eventually included in the extranet. Because CSC uses Mandrake on all workstations and servers, and we're very happy with it (kudos to both cooker and core development teams!) our position is to support development of the distribution by providing hardware and network resources in return. Naturally we're aware that hosting the machines is serious commitment (especially sustaining the support over time) and we're ready to fulfil it. Maybe if we manage to pull this off before 9.2 and have all the packages rebuilt, MandrakeSoft will be interested in releasing 9.2 for i586, x86_64, Alpha, Sparc64 and PPC? IMHO Releasing means supporting. supporting a product requires an organisation and knowledge being available. It also needs to be worthwhile -- bring some $$$ to the company. For the alpha, mips, pa-risc and sparc the market is too small. Right, but look at ppc, mandrake exactly the same product as you can find on mirror ( 3 isos ). Mandrake never make somethings to promute the distro on non i586. I think making an installable distro for sparc/alpha/ppc will make publicity and prove a mandrake activity. Since I'm more or less the maintainer of the alpha port, I've had some interesting discussions with mdk employees on this topic. I don't have the illusion that the alpha port will ever turn into a product that will be supported and even bring revenue to mdk. I see it as my personal research project -- I want to prove that maintaining multiple ports can be done efficiently... /IMHO Well maybe I can explain why I restart sparc ports: - I like play - I like to works on non standards things. Is it usefull, not sure ;) Wouldn't it be the first commercial distribution (in couple of years) that allows to run the same system across 5 architectures? We'll have to see... :-) It would even be nice if we (the community) can maintain these ports and learn a bit have some fun... Fully agree Comments/ideas anyone? -- Linux pour Mac !? Enfin le moyen de transformer une pomme en véritable ordinateur. - JL. Olivier Thauvin - http://nanardon.homelinux.org/
Re: [Cooker] Development extranet for non-intel builds [ALPHA:SPARC:PPC:X86_64]
On Sat Jun 07, 2003 at 08:55:46PM +0200, Stefan van der Eijk wrote:
IMHO
Releasing means supporting. supporting a product requires an
organisation and knowledge being available. It also needs to be
worthwhile -- bring some $$$ to the company. For the alpha, mips,
pa-risc and sparc the market is too small.
Since I'm more or less the maintainer of the alpha port, I've had some
interesting discussions with mdk employees on this topic. I don't have
the illusion that the alpha port will ever turn into a product that
will be supported and even bring revenue to mdk. I see it as my personal
research project -- I want to prove that maintaining multiple ports can
be done efficiently...
/IMHO
Also, don't forget updates. Unless the people who build these ports are
willing to maintain a system/chroot/whatever dedicated for 18mos for
building updates for these ports, it won't happen. As Stefan says, making
this stuff official means it needs to be maintained; without having access
to these various machines for the duration of the lifecycle, it's not even
worth starting it.
That being said, there is nothing from stopping a community built/community
hosted unofficial port; the community builds the port, the community
maintains the port, and MandrakeSoft doesn't have any official dealings with
it (ie. the community completely and 100% supports it themselves).
For alpha, mips, pa-risc, and sparc, I think that would be the best shot.
You could like talk ibiblio or someone into hosting the port if you wanted
to make an unofficial 9.2/pa-risc release (or whatever).
For PPC, I'd love to see it released in tangent with x86 (as well as x86-64
and ia64 I guess).
--
MandrakeSoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
lynx -source http://linsec.ca/vdanen.asc | gpg --import
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp0.pgp
Description: PGP signature
Re: [Cooker] Development extranet for non-intel builds [ALPHA:SPARC:PPC:X86_64]
Well, SPARC's (and at some point Alpha and Opteron 240 SMP) at CSC are on private network behind 9.1 i586 box. I can't see anything that should stop us from creating the extranet and have the builds automated and coordinated. Some centralised user authentication might be a good idea at some point if we have more developers. I think this needs to be addressed for Mandrakesoft's uses anyway. Why do I have seperate accounts for bugzilla (ok, at least the account works for the wiki), build machines, MandrakeClub, MandrakeExpert (I should be able to merge MandrakeExpert and MandrakeClub, but it doesn't get the MandrakeExpert account I wanted, since I had two ...)? I also think that applying the technology that we are shipping should be done more. A better implementation of something like this: http://www.mandrakesecure.net/en/docs/samba-ldap-advanced.php may be an idea ... each facility hosting an extranet member server could have an LDAP slave and authenticate any necessary services against it. The only drawback would be probably the fact, that single development machines without dedicated front-end might need some more work to configure everything, but I think that it'll be worth it. Stefan? Olivier? Gwenole? What do you think? At the moment, to my knowledge we have the following machines _dedicated_ to non-intel cooker development (please, developers, fill in all blanks): - others? Sorry, we only have x86 :-(. I think, that only computers solely dedicated (i.e. not used in any other way) may be listed here and eventually included in the extranet. Because CSC uses Mandrake on all workstations and servers, and we're very happy with it (kudos to both cooker and core development teams!) our position is to support development of the distribution by providing hardware and network resources in return. Naturally we're aware that hosting the machines is serious commitment (especially sustaining the support over time) and we're ready to fulfil it. BTW, this is very cool! Maybe if we manage to pull this off before 9.2 and have all the packages rebuilt, MandrakeSoft will be interested in releasing 9.2 for i586, x86_64, Alpha, Sparc64 and PPC? Wouldn't it be the first commercial distribution (in couple of years) that allows to run the same system across 5 architectures? I think there's a lot of work to be done before that happens, but a nice dream ... Regards, Buchan
