On Fri, Jun 06, 2003 at 04:53:26PM -0400, Camm Maguire wrote: [...] > As you may know, atlas constructs a free optimized blas (and partial > lapack) library by carefully timing and searching through various > algorithms on the building computer. Several ISA instruction sets are > supported, many not yet output by gcc at all. To get good results, it > is essential that the building machine be quiet during the timing > process. > > The Debian package can collect the output of a successfully timed > atlas build, and rerun it during future package builds without > executing any code on the compiling machine. This is important given > our autobuilder setup. So timing builds only need be performed on new > upstream releases, which are infrequent. Timing builds can be very > cpu intensive and take a long time. What does this 'timing' actually mean? Is it imperative that the build of later debian revisions of the same upstream version are built on the same buildd host? If so, you have a problem on the slower architectures, such as m68k, where it is very unlikely for the builds of different versions of the package to happen on the same machine. Also, it's _impossible_ to guarantee that nothing is executed on a buildd machine during the build. Autobuilders are partially cron-driven: 'buildd-watcher' regularly checks whether a buildd process is still running, restarting it as required, also doing various maintenance tasks, such as purging old, no longer required build trees, rotating logs, checking for old files, and so on; 'buildd-uploader' regularly checks a queue on the filesystem, and uploads packages for which a signed .changes has been mailed to buildd by the admin; and last but not least, the most things a buildd admin does with its buildd machine, is give it commands in the form of mails that are sent to it, which might be processed by buildd-mailer when buildd is still running, resulting in files being moved around filesystems, files being removed as a result of katie sending 'ACCEPTED' mails, and so on. It might also be interesting to note that some buildd machines are not only used for autobuilding, but have other jobs to perform. Some happen to be machines on which debian developers have accounts; others, such as one m68k autobuilder of which I am the admin, perform roles in local, private networks. I'm afraid that, if you really need a buildd machine to be doing absolutely nothing but the timing you refer to, you'll have to set up a machine for every architecture where you'd like to install these things, and build the packages yourself. [...] > It would greatly assist me if I could get some feedback on the > following questions. I'm cc'ing this to the ports lists to solicit > opinions from the users of the less common platforms as well. Please > let me know which of the following most accurately reflects your > opinion/preference for atlas on your platform of choice: > > 1) No one in their right mind will run atlas on these boxes -- I want > my platform excluded from the Architecture: list. This option should not be given. It is up to our users to decide whether something is 'useful' on a certain architecture, or not. Please do not exclude any architecture because you, as a maintainer, think of it as useless. Of the other options, I think option #2 or #3 seem to be most prudent for m68k to me; however, since I am not too familiar with either atlas, or ISA extentions, I feel I am not very well placed to say which of the options would be best. As said, I'm afraid none of the autobuilders can be made as 'quiet' as you request on _any_ architecture. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org "An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts." -- National Geographic Channel, in a documentary about large African beasts.
Description: PGP signature