Re: Emulated buildds (for SCC architectures)?
Steve Langasek wrote: Hi Gunnar, On Fri, Mar 18, 2005 at 08:06:47PM -0600, Gunnar Wolf wrote: And I am sure we can find more examples like these - I have not really checked, but I would be surprised if architectures as popular as Sparc, Alpha or ARM wouldn't have an emulator (although probably not currently as reliable as those two). Now, if we face dropping one or more of our architectures (i.e. m68k) because new hardware can not be found anymore (the Vancouver proposal mentions that the release architecture must be publicly available to buy new in order to keep it as a fully supported architecture - I know, SCC != fully supported, but anyway, a buildd can die and create huge problems to a port), why shouldn't we start accepting buildds running under emulated machines? I quite agree with Anthony that if we have to emulate the machine, there's not much sense in supporting it. This makes no sense to me. There is a lot of embedded machines out there that can, for instance, run a web browser (graphical links, w3m or even mini-mo) but are not capable of running g++ (to give an example, and hence they are not capable of /building/ mini-mo). So, if you can emulate this machine in an amd64 1000x faster and with 100x more RAM, you can build an entire Debian system, and permit the installation of a base system with the needed features for the embedded application. I do know, from first-hand experience trying to get ssh running on a Cobalt, that compilation speed is not always correlated with the usefulness of a system; so I'm not completely opposed to using distcc (in moderation!) for release architectures, but I would still first like to see some serious discussion about why it's useful to build all the software we do for all the architectures before agreeing that such a distcc network is warranted. Other question I have is: why the (in moderation!) comment? I think distcc and ccache should be used thoroughly (sorry if this is the wrong spelling) in the buildd process, and I have not seen any moderate, rational and good argument in contrary. Regards, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
Hi, On Fri, Mar 18, 2005 at 08:06:47PM -0600, Gunnar Wolf wrote: safe - Yes, I know we cannot run Debian on a regular UAE because of the lack of a MMU in the official package, but we _can_ run it inside Basilisk2. I was wondering how you are supposed to run Debian inside official BasiliskII. BasiliskII has no MMU support as official UAE. Are you aware of a patch or a project to do so? What you can do is run Debian inside ARAnyM, the Atari emulator, which has a well done MMU implementation. To my mind, it is a great idea to use an emulator, and it suppresses gcc cross-compiling issues with floating point. Using an emulator *DOES NOT* mean the architecture is dead, since some people keep on using it, and m68k hardware is still sold nowadays. It is rather bold to compile stuff on a m68k at an average 40 MHz... That machine is made to be used -- I mean, in a user perspective -- and not to compile for hours/days huge software from source. By the way, using the term Second-Class Citizens to define people who use that aged architecture is not fitting at all the concept of humanity to others which resides in Debian (and in Ubuntu too). By doing so, it classifies people in social classes: a group which is the valuable First-Class Citizens and another composed of uninteresting worthless dropouts who can go dying on scc.debian.org... Why not using another name? Cheers. -- ((__,--,__)) Aurélien GÉRÔME .---. `--)~ ~(--` Free Software Developer / \ .-'( )`-. Unix Sys Net Admin [EMAIL PROTECTED]@./ `~~`@) (@`~~` /`\_/`\ | |.''`. // _ \\ | | : :' : | \ )|_ (8___8) `. `'` /`\_` _/ \ `---` `- \__/'---'\__/ BOFH excuse #348: We're on Token Ring, and it looks like the token got loose. signature.asc Description: Digital signature
Re: Emulated buildds (for SCC architectures)?
On Tue, Mar 22, 2005 at 08:58:41PM -0800, Steve Langasek wrote: Hi Gunnar, I quite agree with Anthony that if we have to emulate the machine, there's not much sense in supporting it. I disagree: porters should be free to use whatever tools they want to do the job. What is important is whether the job is done in a way that give satisfaction to the release team. All the rest is irrelevant. Secondly, Debian is a binary distribution: this means users are not requested to compile anything, so the time it take to compile it is not a criterion of usefulness. In fact, it is the other way round: slower compilation make binary packages more useful (Gentoo proving that we can live without binary packages on the fastest plateforms). I do know, from first-hand experience trying to get ssh running on a Cobalt, that compilation speed is not always correlated with the usefulness of a system; so I'm not completely opposed to using distcc (in moderation!) for release architectures, but I would still first like to see some serious discussion about why it's useful to build all the software we do for all the architectures before agreeing that such a distcc network is warranted. Our current infrastructure does not provide easy ways to restrict the set of architecture a package should be provided in testing, so we tend to have almost every packages for all archs. If it is deemed necessary, a command for the release manager saying remove package 'bar' and all its reverse dependency but only for the architecture foo could be implemented. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
Hi Gunnar, On Fri, Mar 18, 2005 at 08:06:47PM -0600, Gunnar Wolf wrote: And I am sure we can find more examples like these - I have not really checked, but I would be surprised if architectures as popular as Sparc, Alpha or ARM wouldn't have an emulator (although probably not currently as reliable as those two). Now, if we face dropping one or more of our architectures (i.e. m68k) because new hardware can not be found anymore (the Vancouver proposal mentions that the release architecture must be publicly available to buy new in order to keep it as a fully supported architecture - I know, SCC != fully supported, but anyway, a buildd can die and create huge problems to a port), why shouldn't we start accepting buildds running under emulated machines? I quite agree with Anthony that if we have to emulate the machine, there's not much sense in supporting it. I do know, from first-hand experience trying to get ssh running on a Cobalt, that compilation speed is not always correlated with the usefulness of a system; so I'm not completely opposed to using distcc (in moderation!) for release architectures, but I would still first like to see some serious discussion about why it's useful to build all the software we do for all the architectures before agreeing that such a distcc network is warranted. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Emulated buildds (for SCC architectures)?
On Tue, Mar 22, 2005 at 08:58:41PM -0800, Steve Langasek wrote: Now, if we face dropping one or more of our architectures (i.e. m68k) because new hardware can not be found anymore (the Vancouver proposal mentions that the release architecture must be publicly available to buy new in order to keep it as a fully supported architecture - I *cough* You can still buy new Amigas. See http://www.vesalia.de/ for example. Of course, one can start new discussing what's actually is new? Those Amigas are new and unused and include warranty. know, SCC != fully supported, but anyway, a buildd can die and create huge problems to a port), why shouldn't we start accepting buildds running under emulated machines? I quite agree with Anthony that if we have to emulate the machine, there's not much sense in supporting it. Especially when certain things are essential for those archs, like gcc for embedded systems. I do know, from first-hand experience trying to get ssh running on a Cobalt, that compilation speed is not always correlated with the usefulness of a system; so I'm not completely opposed to using distcc (in moderation!) for release architectures, but I would still first like to see some serious discussion about why it's useful to build all the software we do for all the architectures before agreeing that such a distcc network is warranted. I doubt that m68k would gain much profit from using distcc. The preposessing still needs to be done on the m68k. Usually, m68ks only have 10 Mbps ethernet, which is often limited to 300-600 kB/s in real life usage. I don't have a proof, but I think for some NICs there's no DMA supported or so. So, with using distcc (over network) you might buy that remote compiling by raising the CPU load. Basically I agree, that not all packages need to be compiled natively on m68k and that some packages don't need to be considered as RC, such as KDE or other long building ones. For those packages a distcc approach might be useful. I would prefer a reduced release set of packages over even considering the drop of archs. Release a set of packages for basic and server tasks and let all desktop related stuff (X, KDE, Gnome) do their own subreleases on the base of the main (reduced set) release. That way, servers still could run stable for a long time (2 years release cycle f.e.) whereas Desktop users could use newer software for KDE/Gnome with maybe a 6 month release cycle for those subreleases. -- Ciao... // Ingo \X/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
* Anthony Towns (aj@azure.humbug.org.au) wrote: Apparently the feeling wrt distcc is somewhat different and is likely to be a more generally accepted solution to the slow-at-compiling issue. I like distcc -- heck I went to high school with the author -- and I think it's cool. I don't know that it'd be enough to get ports like m68k working quickly enough to meet the 1 or 2 buildds requirement, and it doesn't solve the other issues that arise at all. But hey, I wouldn't have a problem with an m68k+distcc/i386 pairing as a buildd, if all the other requirements were also being dealt with properly. That's also more a DSA/buildd issue though, neither of which are hats of mine. Alright, perhaps I misunderstood the responsibilities a bit. buildds are run by DSA (Which I'm guessing is the 'System Administration' group on w.d.o/intro/organization)? Is access to wanna-build also managed by that group? That's mainly what I was driving at really- will an emulated/distcc buildd be allowed to access wanna-build co. and be acceptable to meet the release criteria? I thought the general feeling was 'emulated - no, distcc - perhaps' but now I've got no idea since it seems the appropriate people havn't commented. Speaking of which, if DSA are the appropriate people, who in that group are active in that role, esp. wrt the buildds? That group has 5 people but I only know of two (James Troup Ryan Murray) who have been active wrt buildds. I'm still a bit confused though since I really thought the buildds fell more under the perview of ftpmasters for whatever reason... Stephen signature.asc Description: Digital signature
Re: Emulated buildds (for SCC architectures)?
On Mon, Mar 21, 2005 at 08:47:41AM -0500, Stephen Frost wrote: * Anthony Towns (aj@azure.humbug.org.au) wrote: Apparently the feeling wrt distcc is somewhat different and is likely to be a more generally accepted solution to the slow-at-compiling issue. I like distcc -- heck I went to high school with the author -- and I think it's cool. I don't know that it'd be enough to get ports like m68k working quickly enough to meet the 1 or 2 buildds requirement, and it doesn't solve the other issues that arise at all. But hey, I wouldn't have a problem with an m68k+distcc/i386 pairing as a buildd, if all the other requirements were also being dealt with properly. That's also more a DSA/buildd issue though, neither of which are hats of mine. Alright, perhaps I misunderstood the responsibilities a bit. buildds are run by DSA No. There's some overlap between the groups of 'buildd admins' and 'DSA', but they are by far not the same. (Which I'm guessing is the 'System Administration' group on w.d.o/intro/organization)? Yes. Is access to wanna-build also managed by that group? Access to wanna-build is managed by James Troup and Ryan Murray. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
* Riku Voipio | Incidentally the first problem should be solvable with the multiarch | proposal, and the toolchains need to be polished anyway. The multiarch proposals out there deal with how to run binaries for multiple architectures, not how to cross-build. That's one of the roads which would be interesting to explore more, but it's not a high priority ATM. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
A much faster solution would be to use distcc or scratchbox for crosscompiling. Debian packages cannot be reliably built with a cross-compiler, because they very frequently need to execute the compiled binaries as well as just compile them. Umm, that is the _exactly_ the problem scratchbox was written to solve. The idea is to have a chroot with crosscompiler and all the flex/bison/document generation/etc tools available as host binaries, while the actual libs linked against are as the target arch debian packages. When a binary actually needs to be run in the target arch, it is executed either with qemu or via sbrsh and nfs on a real target arch machine. As a consequence, most compilations are almost as fast crosscompiled as on the host machine. The ones that are still slow, are the ones that have a complex testsuite, like perl... The are a few drawbacks why it currently can't be really used as debian buildd: First, host tools are somewhat hacked versions of the same tools in debian. For proper debian usage, they should be the same versions as what has been last uploaded to debian. The other one is that the toolchains should also be generated from debian packages.. Currently the build process is kinda ad-hoc.. Incidentally the first problem should be solvable with the multiarch proposal, and the toolchains need to be polished anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
* Gunnar Wolf ([EMAIL PROTECTED]) wrote: Most (although not all) of the architectures facing being downgraded are older, slower hardware, and cannot be readily found. Their build speed is my main argument against John Goerzen's proposal [1]. Now, I understand that up to now we have had the requirement of the builds running in the real hardware. Chances are this wouldn't change for 'official' buildds. While not speaking on behalf of the ftpmaster team the impression I've gotten from Anthony at least is that emulated buildds begs the question of the architecture being useful and aren't exactly likely to be met with open arms. Apparently the feeling wrt distcc is somewhat different and is likely to be a more generally accepted solution to the slow-at-compiling issue. Stephen signature.asc Description: Digital signature
Re: Emulated buildds (for SCC architectures)?
Stephen Frost wrote: * Gunnar Wolf ([EMAIL PROTECTED]) wrote: Most (although not all) of the architectures facing being downgraded are older, slower hardware, and cannot be readily found. Their build speed is my main argument against John Goerzen's proposal [1]. Now, I understand that up to now we have had the requirement of the builds running in the real hardware. Chances are this wouldn't change for 'official' buildds. While not speaking on behalf of the ftpmaster team the impression I've gotten from Anthony at least is that emulated buildds begs the question of the architecture being useful and aren't exactly likely to be met with open arms. You're fine to run emulated buildds, or whatever else for non-release architectures. Do what you like! Go wild! If you screw up, well, that sucks, but you don't hurt anyone else, and you can always fix it later. Heck even the you should never do this, ever, ever, ever procedure of rebuilding everything because of ABI changes a few times isn't so implausible in SCC -- since it doesn't affect other architectures trying to release, or our mirror network. Seriously, if you're even remotely annoyed with the restrictions placed on ports up until now, SCC is *made* for you. But as far as actually *releasing* architectures that aren't usable enough to run as buildds, well, I just can't see the point. That's an issue for the *release team* though. I think unstable+snapshots are more than enough for toy architectures that people are just maintainig for the fun of it, and while that's not being seriously considered I'm not really seeing much point worrying about more complicated solutions. Apparently the feeling wrt distcc is somewhat different and is likely to be a more generally accepted solution to the slow-at-compiling issue. I like distcc -- heck I went to high school with the author -- and I think it's cool. I don't know that it'd be enough to get ports like m68k working quickly enough to meet the 1 or 2 buildds requirement, and it doesn't solve the other issues that arise at all. But hey, I wouldn't have a problem with an m68k+distcc/i386 pairing as a buildd, if all the other requirements were also being dealt with properly. That's also more a DSA/buildd issue though, neither of which are hats of mine. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
On 18 Mar 2005 18:58:50 -0800, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: A much faster solution would be to use distcc or scratchbox for crosscompiling. Debian packages cannot be reliably built with a cross-compiler, because they very frequently need to execute the compiled binaries as well as just compile them. This, and bugs in crosscompiling toolchains prohibit doing this. But what about emulating a buildd with qemu/basilisk2/... and setting up a distcc with crosscompiling gcc on the Host? So the linking/installing/testing/running procedures would run inside the emulated hardware and only the compiling itself (!) would be done using a cross compiler. -- regards, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
On Fri, Mar 18, 2005 at 06:58:50PM -0800, Thomas Bushnell BSG wrote: Peter 'p2' De Schrijver [EMAIL PROTECTED] writes: A much faster solution would be to use distcc or scratchbox for crosscompiling. Debian packages cannot be reliably built with a cross-compiler, because they very frequently need to execute the compiled binaries as well as just compile them. That's exactly the problem which is solved by using distcc or scratchbox. distcc basically sends preprocessed source to another machine and expects an object back. So you run the build on a machine of the target arch (or an emulator), but the compiler part is actually a small program which sends the source to the fast machine running the cross compiler and expects the object code back. Scratchbox provides a sandbox on the machine doing the cross compile, in which target binaries can be executed by either running them on a target board sharing the sandbox filesystem using NFS or by running them in qemu. Cheers, Peter (p2). signature.asc Description: Digital signature
Re: Emulated buildds (for SCC architectures)?
Yes, but the argument against cross-compiling has always been stronger - If you are compiling under an emulator, you can at least test the produced binaries under that same emulator, and you have a high degree of confidence that they work reliably (this is, if an emulator bug leads to gcc miscompiling, it'd be surprising if it allowed for running under the emulator). Using cross-compilers you can't really test it. And, also an important point, you can potentially come up with a resulting package you could not generate in the target architecture. You can always run generated binaries on an emulator or a target board for testing. I have cross compiled a lot of code using gcc and have yet to see wrong binaries caused by cross compiling versus native compiling. I could imagine problems with floating point expressions evaluated at compile time and resulting in slightly different results. The only way to see if cross compiling generates wrong binaries, is to try it and evaluate the results. But, yes, I'd accept a cross-compiler as a solution as well in case we could not run an emulator for a given slow platform. We will probably need both as some build scripts run generated code. Cheers, Peter (p2). signature.asc Description: Digital signature
Re: Emulated buildds (for SCC architectures)?
Karsten Merker [EMAIL PROTECTED] writes: On Fri, Mar 18, 2005 at 06:58:50PM -0800, Thomas Bushnell BSG wrote: Peter 'p2' De Schrijver [EMAIL PROTECTED] writes: A much faster solution would be to use distcc or scratchbox for crosscompiling. Debian packages cannot be reliably built with a cross-compiler, because they very frequently need to execute the compiled binaries as well as just compile them. I suppose the idea is to use distcc and a crosscompiler - that way the .c files are compiled to .o on a fast architecture with a crosscompiler, but the configure scripts, linker and so on run natively. Right, but upstream makefiles don't work this way, and often interleave compilation and execution of native code. Consider a program that has its own source-code-building widget, which it needs to compile and run to generate more code to compile. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
On Sat, Mar 19, 2005 at 08:21:18PM -0800, Thomas Bushnell BSG wrote: Karsten Merker [EMAIL PROTECTED] writes: On Fri, Mar 18, 2005 at 06:58:50PM -0800, Thomas Bushnell BSG wrote: Peter 'p2' De Schrijver [EMAIL PROTECTED] writes: A much faster solution would be to use distcc or scratchbox for crosscompiling. Debian packages cannot be reliably built with a cross-compiler, because they very frequently need to execute the compiled binaries as well as just compile them. I suppose the idea is to use distcc and a crosscompiler - that way the .c files are compiled to .o on a fast architecture with a crosscompiler, but the configure scripts, linker and so on run natively. Right, but upstream makefiles don't work this way, and often interleave compilation and execution of native code. Consider a program that has its own source-code-building widget, which it needs to compile and run to generate more code to compile. That'll work. _All_ distcc sends to the crosscompiler is preprocessed c code to be compiled into object code. So the source-code building widget is compiled remotely, run locally, and the results are sent to compile remotely. -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
Re: Emulated buildds (for SCC architectures)?
[EMAIL PROTECTED] (Paul Hampson) writes: That'll work. _All_ distcc sends to the crosscompiler is preprocessed c code to be compiled into object code. So the source-code building widget is compiled remotely, run locally, and the results are sent to compile remotely. Oh, I see now. I was misunderstanding what distcc did. Very clever! This might not account for much of the time. I know that libc and X compilation spends a huge amount of time in header file inclusion work. It works for those cases. But other cases spend lots of time doing things like outline tracing and other non-compilation activities. But still, something like this could well make a huge dent. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Emulated buildds (for SCC architectures)?
Hi, I haven't followed as thoroughly as I would have liked the recent verborrhea in the list regarding the Vancouver proposal. Anyway, I'd like to raise a point that I brought up during Debconf3, in the light of the changes that we are now facing. Most (although not all) of the architectures facing being downgraded are older, slower hardware, and cannot be readily found. Their build speed is my main argument against John Goerzen's proposal [1]. Now, I understand that up to now we have had the requirement of the builds running in the real hardware. Nowadays, an i386 system emulating a m68k (using either UAE or Basilisk2) is at least comparable to the fastest m68k system ever produced. I have worked with both emulators, and both seem completely safe - Yes, I know we cannot run Debian on a regular UAE because of the lack of a MMU in the official package, but we _can_ run it inside Basilisk2. A completely different problem with the same results arises when using s390 machines: As someone noted recently, most of us cannot afford having a s390 running in the basement. But AFAICT, Hercules is a quite usable s390 emulator. And I am sure we can find more examples like these - I have not really checked, but I would be surprised if architectures as popular as Sparc, Alpha or ARM wouldn't have an emulator (although probably not currently as reliable as those two). Now, if we face dropping one or more of our architectures (i.e. m68k) because new hardware can not be found anymore (the Vancouver proposal mentions that the release architecture must be publicly available to buy new in order to keep it as a fully supported architecture - I know, SCC != fully supported, but anyway, a buildd can die and create huge problems to a port), why shouldn't we start accepting buildds running under emulated machines? Greetings, [1] http://lists.debian.org/debian-devel/2005/03/msg01387.html -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
Gunnar Wolf wrote: SNIP Nowadays, an i386 system emulating a m68k (using either UAE or Basilisk2) is at least comparable to the fastest m68k system ever produced. I have worked with both emulators, and both seem completely safe - Yes, I know we cannot run Debian on a regular UAE because of the lack of a MMU in the official package, but we _can_ run it inside Basilisk2. SNIP AIUI, qemu is pretty good with arches that it does support. That is another possibility. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re: Emulated buildds (for SCC architectures)?
On Fri, Mar 18, 2005 at 08:06:47PM -0600, Gunnar Wolf wrote: Hi, I haven't followed as thoroughly as I would have liked the recent verborrhea in the list regarding the Vancouver proposal. Anyway, I'd like to raise a point that I brought up during Debconf3, in the light of the changes that we are now facing. Most (although not all) of the architectures facing being downgraded are older, slower hardware, and cannot be readily found. Their build speed is my main argument against John Goerzen's proposal [1]. Now, I understand that up to now we have had the requirement of the builds running in the real hardware. Nowadays, an i386 system emulating a m68k (using either UAE or Basilisk2) is at least comparable to the fastest m68k system ever produced. I have worked with both emulators, and both seem completely safe - Yes, I know we cannot run Debian on a regular UAE because of the lack of a MMU in the official package, but we _can_ run it inside Basilisk2. A much faster solution would be to use distcc or scratchbox for crosscompiling. A completely different problem with the same results arises when using s390 machines: As someone noted recently, most of us cannot afford having a s390 running in the basement. But AFAICT, Hercules is a quite usable s390 emulator. And I am sure we can find more examples like these - I have not really checked, but I would be surprised if architectures as popular as Sparc, Alpha or ARM wouldn't have an emulator (although probably not currently as reliable as those two). ARM is supported by both qemu and scratchbox, so you could do a cross compiling buildd without needing actual ARM hardware (scratchbox normally uses a target board to run generated binaries during the buildprocess, but it can also use qemu). OTOH Intel's IOP Xscale series is quite fast and there are faster ARMs coming, so it's probably not necessary to use crosscompiling to keep up. Alpha and Sparc should be fast enough to keep up. Now, if we face dropping one or more of our architectures (i.e. m68k) because new hardware can not be found anymore (the Vancouver proposal mentions that the release architecture must be publicly available to buy new in order to keep it as a fully supported architecture - I know, SCC != fully supported, but anyway, a buildd can die and create huge problems to a port), why shouldn't we start accepting buildds running under emulated machines? If you don't tell people, how would they know ? :) Cheers, Peter (p2). signature.asc Description: Digital signature
Re: Emulated buildds (for SCC architectures)?
Peter 'p2' De Schrijver dijo [Sat, Mar 19, 2005 at 03:41:46AM +0100]: Nowadays, an i386 system emulating a m68k (using either UAE or Basilisk2) is at least comparable to the fastest m68k system ever produced. I have worked with both emulators, and both seem completely safe - Yes, I know we cannot run Debian on a regular UAE because of the lack of a MMU in the official package, but we _can_ run it inside Basilisk2. A much faster solution would be to use distcc or scratchbox for crosscompiling. Yes, but the argument against cross-compiling has always been stronger - If you are compiling under an emulator, you can at least test the produced binaries under that same emulator, and you have a high degree of confidence that they work reliably (this is, if an emulator bug leads to gcc miscompiling, it'd be surprising if it allowed for running under the emulator). Using cross-compilers you can't really test it. And, also an important point, you can potentially come up with a resulting package you could not generate in the target architecture. But, yes, I'd accept a cross-compiler as a solution as well in case we could not run an emulator for a given slow platform. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Emulated buildds (for SCC architectures)?
Peter 'p2' De Schrijver [EMAIL PROTECTED] writes: A much faster solution would be to use distcc or scratchbox for crosscompiling. Debian packages cannot be reliably built with a cross-compiler, because they very frequently need to execute the compiled binaries as well as just compile them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
