Re: sparc32 and sparc64-only packages
* Jurij Smakov ([EMAIL PROTECTED]) [060713 04:39]: On Wed, 12 Jul 2006, Goswin von Brederlow wrote: How about creating a sparc64 package (probably part of dpkg's internal type-handling support) and depending on that? That would at least make the package uninstallable on sparc32. Is there some mechanism to enforce it? I don't see anything which would prevent the installation of the proposed sparc64 package on sparc32 box. Anyway, before working on a solution I would like to hear the release team opinion on the matter. Well, what do the porters think that our sparc port is? I think that's basically a central part of the question. From the release team's point of view, I think we have the following requirements: - The current users of the port must not be left in the cold all of sudden (i.e. document any changes, EOLs etc), and the almost all of practical installations need to keep working; - Upgrades from sarge to etch must work I'm not too sure if that's all, and that's just my personal opinion now, but basically the porters define what the arch looks like. Of course, there is a natural point in life where the definition changes (e.g. we EOLed 80386 with sarge), and that's ok if documented properly. Of course, something like e.g. droppen support of all but the lastest i386-compatible CPUs wouldn't have been acceptable. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc32 and sparc64-only packages
Reinhard Tartler wrote: I agree. SPARC-32 might still have its place as an introduction for people with no experience of Sun machines if that's all they can get hold of, but I can't see anybody in their right mind expecting to run fancy animated graphics on it. It all depends what you use the box for. I run IceWM on my 170MHz SPARCstation 5. I agree that it's not suited for watching movies, etc, but it's still a useful box. I agree that something like a WM, particularly one that prides itself as being light and tight, would be expected to run on as many systems as possible, irrespective of performance. Hell, I run KDE on an 8-way SPARCserver on occasion, but in my case I'm concerned with being able to demonstrate that we can /potentially/ reduce our reliance on the PC architecture rather than having something that can do real work without major air conditioning. As xine comaintainer I'm interested if I should disable special vis optimisations in the xine-lib source package sacrificing performance on ultrasparc machines for the sake of older SPARCstations. This was not meant as offence for SPARCstation users (and I don't have much clue about sparc anyway), I rather want to find a good solutions for our users. I'm a very junior member of this community, and I'm not a practicing C/C++ or kernel hacker, so I'm not really sure I'm entitled to an opinion. However the bottom line is that something like xine would be unlikely to perform adequately on /any/ SPARC-32 system, either because of insufficient processor speed or peripheral issues (limited colour depth on most screens, availability of audio and suitable CD/DVD drives etc.). The fastest 32-bit SPARC is going to be what- 200MHz? Let's say that in a workstation that does the same amount of work as a 400MHz PC- marginal for multimedia, even allowing that SPARC CPUs frequently come in pairs. In practice most people who've acquired 32-bit machines will have something slower than this: I might be wrong, but I think that xine would have problems even with the most ingenious optimisations. In other words, where there's a clear physical requirement which a particular variant of an architecture can't meet then I see no reason to bend over backwards to accomodate it. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc32 and sparc64-only packages
On Wed, Jul 12, 2006 at 07:37:45PM -0700, Jurij Smakov wrote: As xine comaintainer I'm interested if I should disable special vis optimisations in the xine-lib source package sacrificing performance on ultrasparc machines for the sake of older SPARCstations. This was not meant as offence for SPARCstation users (and I don't have much clue about sparc anyway), I rather want to find a good solutions for our users. An other option would be to create a 'special' libxine1-vis package, which has libxine recompiled with optimised libraries. That would be and ideal solution, however I'm not sure whether it is easily achievable. From a cursory look at the source of the component containing the sparc64-specific assembler I got an impression that it just does not ship any generic unoptimized code. I would be glad to be proven wrong on that, but to me it looked like making it work on sparc32 required a significant effort. I meant to compile whole xine twice on sparc, like marillat does with the mplayer packages. (yes, this is a ridiculous waste of cpu time on the sparc buildds, and I'd rather avoid this). If the decision is that it is okay to include vis depending code for ffmpeg and related packages, then I think we should have this documented in the Developers Reference, if not, in Debian Policy. I don't think it's such a big deal, but at the moment it's up to release team to decide whether such packages are considered RC-buggy. Last time I asked on irc, I was said that the release team was waiting for further comments from the sparc porters about this issue. Up to know, I have seen no comments yet (besides from Goswin or you). Gruesse, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc32 and sparc64-only packages
Jurij Smakov [EMAIL PROTECTED] writes: On Wed, 12 Jul 2006, Goswin von Brederlow wrote: How about creating a sparc64 package (probably part of dpkg's internal type-handling support) and depending on that? That would at least make the package uninstallable on sparc32. Is there some mechanism to enforce it? I don't see anything which would prevent the installation of the proposed sparc64 package on sparc32 box. Anyway, before working on a solution I would like to hear the release team opinion on the matter. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC Make the sparc64 package internal to dpkg and only installed when a sparc64 cpu is present. Or have the sparc64 package check in preinst that the cpu is 64bit. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc32 and sparc64-only packages
Austin Denyer wrote: On Sun, 02 Jul 2006 17:08:08 +, Mark Morgan Lloyd [EMAIL PROTECTED] wrote: I agree. SPARC-32 might still have its place as an introduction for people with no experience of Sun machines if that's all they can get hold of, but I can't see anybody in their right mind expecting to run fancy animated graphics on it. It all depends what you use the box for. I run IceWM on my 170MHz SPARCstation 5. I agree that it's not suited for watching movies, etc, but it's still a useful box. As xine comaintainer I'm interested if I should disable special vis optimisations in the xine-lib source package sacrificing performance on ultrasparc machines for the sake of older SPARCstations. This was not meant as offence for SPARCstation users (and I don't have much clue about sparc anyway), I rather want to find a good solutions for our users. An other option would be to create a 'special' libxine1-vis package, which has libxine recompiled with optimised libraries. If the decision is that it is okay to include vis depending code for ffmpeg and related packages, then I think we should have this documented in the Developers Reference, if not, in Debian Policy. Greetings, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc32 and sparc64-only packages
Jurij Smakov [EMAIL PROTECTED] writes: Hi, Recently I've been investigating the xine-lib build failure on sparc. It turned out that failure occured due to libavcodec, shipped as a part of xine-lib, using the sparc64-specific assembler instructions in some routines (without providing any generic arch-independent replacement for them). So, the simplest solution is to add something like -mcpu=ultrasparc, which fixes the build failure, but renders xine-lib unusable on sparc32 machine. It turns out that there are at least a few binaries already in the archive (like binaries built from ffmpeg and mpeg2dec source packages) which uses -mcpu=ultrasparc. Those will not work on sparc32 either. How about creating a sparc64 package (probably part of dpkg's internal type-handling support) and depending on that? That would at least make the package uninstallable on sparc32. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc32 and sparc64-only packages
On Wed, 12 Jul 2006, Reinhard Tartler wrote: As xine comaintainer I'm interested if I should disable special vis optimisations in the xine-lib source package sacrificing performance on ultrasparc machines for the sake of older SPARCstations. This was not meant as offence for SPARCstation users (and I don't have much clue about sparc anyway), I rather want to find a good solutions for our users. An other option would be to create a 'special' libxine1-vis package, which has libxine recompiled with optimised libraries. That would be and ideal solution, however I'm not sure whether it is easily achievable. From a cursory look at the source of the component containing the sparc64-specific assembler I got an impression that it just does not ship any generic unoptimized code. I would be glad to be proven wrong on that, but to me it looked like making it work on sparc32 required a significant effort. If the decision is that it is okay to include vis depending code for ffmpeg and related packages, then I think we should have this documented in the Developers Reference, if not, in Debian Policy. I don't think it's such a big deal, but at the moment it's up to release team to decide whether such packages are considered RC-buggy. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc32 and sparc64-only packages
On Wed, 12 Jul 2006, Goswin von Brederlow wrote: How about creating a sparc64 package (probably part of dpkg's internal type-handling support) and depending on that? That would at least make the package uninstallable on sparc32. Is there some mechanism to enforce it? I don't see anything which would prevent the installation of the proposed sparc64 package on sparc32 box. Anyway, before working on a solution I would like to hear the release team opinion on the matter. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc32 and sparc64-only packages
Hence the question: what does release team thinks about presence of such packages in the archive? Porting them to sparc32 may constitute a significant effort, not justified, in my opinion, by the benefit provided. sparc32 is not exactly geared for watching movies, and so far I can recall only one person on the debian-sparc list mentioning attempts to run xorg on it (current xorg lacks drivers for cards found on sparc32 boxes, they have been uploaded only recently and are currently in NEW). So, if sparc at some point becomes a release candidate, would presence of the packages only supporting sparc64 would be considered RC? I agree. SPARC-32 might still have its place as an introduction for people with no experience of Sun machines if that's all they can get hold of, but I can't see anybody in their right mind expecting to run fancy animated graphics on it. Perhaps a stub is in order advising anybody who tries to install certain packages that they have been withdrawn since the platform simply isn't fast enough- can anything like that be done? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc32 and sparc64-only packages
On Sun, 02 Jul 2006 17:08:08 +, Mark Morgan Lloyd [EMAIL PROTECTED] wrote: I agree. SPARC-32 might still have its place as an introduction for people with no experience of Sun machines if that's all they can get hold of, but I can't see anybody in their right mind expecting to run fancy animated graphics on it. It all depends what you use the box for. I run IceWM on my 170MHz SPARCstation 5. I agree that it's not suited for watching movies, etc, but it's still a useful box. Regards, Ozz. pgp51AjsIa9dG.pgp Description: PGP signature
sparc32 and sparc64-only packages
Hi, Recently I've been investigating the xine-lib build failure on sparc. It turned out that failure occured due to libavcodec, shipped as a part of xine-lib, using the sparc64-specific assembler instructions in some routines (without providing any generic arch-independent replacement for them). So, the simplest solution is to add something like -mcpu=ultrasparc, which fixes the build failure, but renders xine-lib unusable on sparc32 machine. It turns out that there are at least a few binaries already in the archive (like binaries built from ffmpeg and mpeg2dec source packages) which uses -mcpu=ultrasparc. Those will not work on sparc32 either. Hence the question: what does release team thinks about presence of such packages in the archive? Porting them to sparc32 may constitute a significant effort, not justified, in my opinion, by the benefit provided. sparc32 is not exactly geared for watching movies, and so far I can recall only one person on the debian-sparc list mentioning attempts to run xorg on it (current xorg lacks drivers for cards found on sparc32 boxes, they have been uploaded only recently and are currently in NEW). So, if sparc at some point becomes a release candidate, would presence of the packages only supporting sparc64 would be considered RC? If someone would volunteer to look into these problems and produce the generic versions for the sparc64-optimized routines, such an effort would, of course, be very welcome. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sparc32 and sparc64-only packages
Jurij Smakov wrote: Recently I've been investigating the xine-lib build failure on sparc. It turned out that failure occured due to libavcodec, shipped as a part of xine-lib, using the sparc64-specific assembler instructions in some routines (without providing any generic arch-independent replacement for them). So, the simplest solution is to add something like -mcpu=ultrasparc, which fixes the build failure, but renders xine-lib unusable on sparc32 machine. It turns out that there are at least a few binaries already in the archive (like binaries built from ffmpeg and mpeg2dec source packages) which uses -mcpu=ultrasparc. Those will not work on sparc32 either. It happens that I approached upstream with this issue today, but without success: http://comments.gmane.org/gmane.comp.video.xine.devel/15554 I also tried building with the configure flag --disable-vis, but the same FTBFS occured. Greetings, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
