Re: How should we deal with 'pointless-on-this-arch' packages?
On Sun, Oct 15, 2006 at 01:13:53AM -0500, Ron Johnson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/06 00:03, Goswin von Brederlow wrote: Roberto C. Sanchez [EMAIL PROTECTED] writes: On Sat, Oct 14, 2006 at 07:30:15PM +0200, Holger Levsen wrote: [snip] I think it should be in the porters control what packages to build for an arch with some guidelines what sort of packages can be removed without loosing release status. For example removing KDE would not be OK. Removal should be reserved for extreme cases though. Things that just need long to build should be put into weak_no_auto and limited to the stronger buildds of an arch. Why *shouldn't* KDE, GNOME, Firefox/Iceweasel, Tbird, and anything that requires Mesa/OpenGL, and all of Charles Plessy's scientific packages be marked do_not_build on 68k/Coldfire ARM? Because they all have many reverse dependencies. Because running (e.g.) konqueror may still be a good idea even if you don't want to run all of KDE. Because not interested in all of this does not necessarily mean not interested even in part of this. If an Amiga (using the unaccelerated fb driver?) is running as an X Terminal for a powerful, modern box, the Amiga would need to process the OpenGL commands, no? Sometimes. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sun, Oct 15, 2006 at 09:33:51AM +0200, Goswin von Brederlow wrote: not others (like gnome) should not be allowed. If the port decides that they don't need any X, e.g. there is no hardware capable of running X applications, then they could remove all X stuff as a whole. That would be different from removing kde. That's a bad example. X is a client/server system for a reason. E.g., there is no graphical hardware for s390, yet it can still be a good idea to use X software on s390 hardware with X terminals. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
Wouter Verhelst [EMAIL PROTECTED] writes: That's a bad example. X is a client/server system for a reason. E.g., there is no graphical hardware for s390, yet it can still be a good idea to use X software on s390 hardware with X terminals. Yeah, that's the thing -- while maintainers are usually competent to judge can't (i.e., non-trivial porting effort is required), they often don't seem any better than anyone else at judging shouldn't / don't-need-to . Users do all _kinds_ of weird things... -Miles -- `The suburb is an obsolete and contradictory form of human settlement' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/06 00:03, Goswin von Brederlow wrote: Roberto C. Sanchez [EMAIL PROTECTED] writes: On Sat, Oct 14, 2006 at 07:30:15PM +0200, Holger Levsen wrote: [snip] I think it should be in the porters control what packages to build for an arch with some guidelines what sort of packages can be removed without loosing release status. For example removing KDE would not be OK. Removal should be reserved for extreme cases though. Things that just need long to build should be put into weak_no_auto and limited to the stronger buildds of an arch. Why *shouldn't* KDE, GNOME, Firefox/Iceweasel, Tbird, and anything that requires Mesa/OpenGL, and all of Charles Plessy's scientific packages be marked do_not_build on 68k/Coldfire ARM? If an Amiga (using the unaccelerated fb driver?) is running as an X Terminal for a powerful, modern box, the Amiga would need to process the OpenGL commands, no? - -- Ron Johnson, Jr. Jefferson LA USA Is common sense really valid? For example, it is common sense to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that common sense is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFMdGhS9HxQb37XmcRAqDRAJ9vMAMZ8ZxvVXByqtZ9BRGGB2wifwCgqebl V68y29Jjbv9UJ+57ZDhDxsA= =wexU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
Ron Johnson [EMAIL PROTECTED] writes: On 10/15/06 00:03, Goswin von Brederlow wrote: Roberto C. Sanchez [EMAIL PROTECTED] writes: On Sat, Oct 14, 2006 at 07:30:15PM +0200, Holger Levsen wrote: [snip] I think it should be in the porters control what packages to build for an arch with some guidelines what sort of packages can be removed without loosing release status. For example removing KDE would not be OK. Removal should be reserved for extreme cases though. Things that just need long to build should be put into weak_no_auto and limited to the stronger buildds of an arch. Why *shouldn't* KDE, GNOME, Firefox/Iceweasel, Tbird, and anything that requires Mesa/OpenGL, and all of Charles Plessy's scientific packages be marked do_not_build on 68k/Coldfire ARM? Because it is perfectly fine to run kde on such a system. Anything that can run gnome can run kde. Anything that can run X can run kde I would even say. Kicking one alternative for something (like kde) but not others (like gnome) should not be allowed. If the port decides that they don't need any X, e.g. there is no hardware capable of running X applications, then they could remove all X stuff as a whole. That would be different from removing kde. But I feel that X, Gnome, KDE is a big part of what makes Debian what it is. If you remove all that is it still Debian? Anyway, kde was just an example / a suggestion. The guidelines could say a port must have all priority standard and above and can decide freely on optional/extra. There is that 95% rule for official releases. Think of this as a refinement of that rule that is more than the line in a graph. If an Amiga (using the unaccelerated fb driver?) is running as an X Terminal for a powerful, modern box, the Amiga would need to process the OpenGL commands, no? There are no amigas with unaccelerated FB driver I believe, which does not mean the FB is all that fast though. There are also crads with 3D hardware and even cards allowing to use PCI graphic cards, theoretically. But I don't think there is anything actually supported and in use capable of realtime 3D gaming. Would a Virge 3D card even be good enough to play Tuxracer? Anything that needs realtime GL is probably useless for m68k. So even if you could get hardware GL working remotely m68k just couldn't do it I think. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
Carlo Segre [EMAIL PROTECTED] writes: On Sun, 15 Oct 2006, Charles Plessy wrote: The interest with debtags is that it allows to change the policy for a package without needing an upload or the intervention of the maintainer. This way, the decision of not building could be taken by the maintainer, and it could be reverted quickly by somebody else if a user requested the package on an excluded arch. How would you implement with with debtags? Are the buildd's paying attention to this now? Maybe I misunderstand. Carlo They aren't paying attention to anything but Wanna-Build and their local [weak_]no_auto list. The place to watch for debtags would be wanna-build. That is the central place that decides what to build. Buildds just pick things up from there. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/06 02:33, Goswin von Brederlow wrote: Ron Johnson [EMAIL PROTECTED] writes: On 10/15/06 00:03, Goswin von Brederlow wrote: Roberto C. Sanchez [EMAIL PROTECTED] writes: On Sat, Oct 14, 2006 at 07:30:15PM +0200, Holger Levsen wrote: [snip] I think it should be in the porters control what packages to build for an arch with some guidelines what sort of packages can be removed without loosing release status. For example removing KDE would not be OK. Removal should be reserved for extreme cases though. Things that just need long to build should be put into weak_no_auto and limited to the stronger buildds of an arch. Why *shouldn't* KDE, GNOME, Firefox/Iceweasel, Tbird, and anything that requires Mesa/OpenGL, and all of Charles Plessy's scientific packages be marked do_not_build on 68k/Coldfire ARM? Because it is perfectly fine to run kde on such a system. Anything that can run gnome can run kde. Anything that can run X can run kde I would even say. Kicking one alternative for something (like kde) but not others (like gnome) should not be allowed. But I *am* saying that porters/maintainers should think about dropping all the heavy CPU- RAM-using packages. Including GNOME. If the port decides that they don't need any X, e.g. there is no hardware capable of running X applications, then they could remove all X stuff as a whole. That would be different from removing kde. But I feel that X, Gnome, KDE is a big part of what makes Debian what it is. If you remove all that is it still Debian? Am I not running Debian if I only have a minimal system installed? Of course I am. XFce, fvwm, BlackBox, AfterStep, WindowManager(?) and jwm would all still let you have a nice low-power system. [snip] If an Amiga (using the unaccelerated fb driver?) is running as an X Terminal for a powerful, modern box, the Amiga would need to process the OpenGL commands, no? There are no amigas with unaccelerated FB driver I believe, which does not mean the FB is all that fast though. There are also crads with 3D hardware and even cards allowing to use PCI graphic cards, theoretically. But I don't think there is anything actually supported and in use capable of realtime 3D gaming. Would a Virge 3D card even be good enough to play Tuxracer? Anything that needs realtime GL is probably useless for m68k. So even if you could get hardware GL working remotely m68k just couldn't do it I think. Then why build Mesa/GL packages for 68k and ARM and (probably?) MIPS? - -- Ron Johnson, Jr. Jefferson LA USA Is common sense really valid? For example, it is common sense to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that common sense is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFMe5ES9HxQb37XmcRAvYsAJ0UPR+wq0jM0wAQE/CsobceZJrRbACdFs1l lr0AF+T7XgjgLezqpLfdgVU= =jq2f -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sat, Oct 14, 2006 at 11:51:49AM +0100, Wookey wrote: On 2006-10-14 12:06 +0200, Ingo Juergensmann wrote: It doesn't make much sense to build all Desktop related packages for an arch that is mainly used remotely or as an embedded device. I don't think that anyone will run KDE on top of an NSLU2 or on a Linksys WRT54G. No - but they might well run it on an Iyonix, and maybe even a balloon. Even though arm is mostly-embedded there are a few desktop machines (which merely illustrates the problem of general package classifications). Granted. Same may be valid for m68k, although there *are* users that are using their m68ks as an X-Terminal or such. But those are rare. As you say m68k is leading the way in terms of still being a useful arch but not able to cope with 'all of debian'. Arm is following. Other archs may follow as well. S390 seems short of porters/developers, mips, alpha, hppa and ia64 don't have such huge userbase either. PPC may be fade away as well, now Apple made the switch, although there are still some brave manufactures left for PPC Desktop machine, but those don't have the market share (yet). Hopefully it won't end in a i386/amd64 only distribution So, it's better, IMHO, to reduce the number of packages for those archs by defining some sort of requirements: - what is *required* to make use of that arch (f.e. example packages in section base, admin or with priority required)? - what is commonly used on those archs? popcon can gives some hints like MTAs, fetchmail, UUCP, DHCP-stuff or similar things (gcc, debugger, ...) - what is rarely used? (Desktop Environments, Browsers, numerical analysis tools) - what is unuseable on that arch? (qemu, Xen, flight simulators, cluster software, ...) Clearly something like this could be a general solution to the problem. I do think there is value in defining characteristics of packages so that choice can be made, but it is not an easy thing to do. Even on a slow arch which is not normally used as a desktop, desktop packages are often needed. Yes. Even on m68k we get some user input from time to time saying something like I'm using firefox on m68k... Should such classification be done per-arch, or generally. Should we perhaps have 'core' and 'other' (like ubuntu's main and multiverse (or whatever it which)). I think it should be done on a per arch basis. The need for desktops can vary much across archs. i386, amd64 and ppc have a higher need for desktop apps than arm and m68k. Generally I would like to see a new release scheme anyway: define a basic set of packages forming a core release and allow subprojects like desktop teams (KDE, Gnome, XSF) to do their own releases based on the core release. But that's a different story... Perhaps debtags could be used as an appropriate classification mechanism. Debtags are aiming at binary packages, as someone already stated, and w-b doesn't support them, but something similar could be implemented for source packages, I think. Currently, w-b supports some sort of prioritization, IIRC, so it should fairly easy to define a certain set of packages at a higher priority (the core packages if you like). Everything above that priority is considered as a release criteria whereas every package below that priority *can* be built and *can* considered for a release for that particular arch - or considered not. Perhaps embedded debian could be developed to fill the 'smaller machine' niche, although that is not necessarily a very good fit (emdebian is about shrinking all packages as well as subsetting). Shrinking packages would be a general benefit for smaller/slower archs as well. Packages are getting bigger and bigger, so no wonder slower archs are falling behind. Heck, even on faster archs this does matter. My 512 MB PPC machine is using 300 MB swap now, whereas it was using no swap 2 years ago or so. And any such descisions have implications for how the release process is managed. Of course. And therefore I would welcome if any of the RMs would join the discussion. :) Nevertheless I think it is clear that we do need mechanisms to keep the load and package set appropriate for slower arches. If we design the mechanism properly I would hope it could be useful for various categorisation/subsetting purposes within debian. Indeed. And a new release scheme will most likely shorten the release cycles, if done properly. The whole project would benefit from that. -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sat, Oct 14, 2006 at 07:30:15PM +0200, Holger Levsen wrote: On Saturday 14 October 2006 12:51, Wookey wrote: Nevertheless I think it is clear that we do need mechanisms to keep the load and package set appropriate for slower arches. If we design the mechanism properly I would hope it could be useful for various categorisation/subsetting purposes within debian. Isn't it up to the maintainer to say $package is not suited for $architecture? And aren't maintainers happy to receive hints (e.g. from porters or users of a certain package), which specific package is not suited for a specific architecture? IMHO, Wookeys intention was to change the release scheme to something that not all packages are considered as a release criteria as a whole, although some packages can be built, but a rather useless except for academic proof of being able to built (and catch some errors). Excluding archs from Arch: list wasn't the intention of Wookey as I understand him. -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sun, Oct 15, 2006 at 07:03:59AM +0200, Goswin von Brederlow wrote: I think it should be in the porters control what packages to build for an arch with some guidelines what sort of packages can be removed without loosing release status. For example removing KDE would not be OK. Removal should be reserved for extreme cases though. Things that just need long to build should be put into weak_no_auto and limited to the stronger buildds of an arch. Well, this can be problematic as you know and as mips proved prominently 2 or 3 years ago. ;) And even more weak_no_auto doesn't prevent consideration for testing migration, so this wouldn't help much at all. Maybe someone could come up with a britney patch that would allow an arch to make a list of package non-blocking for the testing transition. A package like axiom should not be blocked from testing because m68k hasn't build it yet. It should be perfectly save to remove it for m68k till such a time that the buildds catch up. Things that the porters/maintainer are reasonably sure noone will miss but we try to build it just in case anyway. I think a lot of the potential excludes fall under this category. The w-b/dak suite already implements some sort of those mechanisms. It can exlcude an arch from testing migration, it can exclude package per P-A-S, so it just needs a mixture of both to exclude packages for some archs for the testing migration. -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sun, Oct 15, 2006 at 03:16:04AM -0500, Ron Johnson wrote: Because it is perfectly fine to run kde on such a system. Anything that can run gnome can run kde. Anything that can run X can run kde I would even say. Kicking one alternative for something (like kde) but not others (like gnome) should not be allowed. But I *am* saying that porters/maintainers should think about dropping all the heavy CPU- RAM-using packages. Including GNOME. I don't think this is good. Basically a user should be able to choose if s/he would like to use Gnome or KDE. Wookeys proposal was about dropping those packages from being a release criteria, not about dropping them at all from that arch. If the port decides that they don't need any X, e.g. there is no hardware capable of running X applications, then they could remove all X stuff as a whole. That would be different from removing kde. But I feel that X, Gnome, KDE is a big part of what makes Debian what it is. If you remove all that is it still Debian? Am I not running Debian if I only have a minimal system installed? Of course I am. XFce, fvwm, BlackBox, AfterStep, WindowManager(?) and jwm would all still let you have a nice low-power system. Of course, but why not let the other DEs being built, when there's enough horse-power left, even if it's being built later? [snip] If an Amiga (using the unaccelerated fb driver?) is running as an X Terminal for a powerful, modern box, the Amiga would need to process the OpenGL commands, no? There are no amigas with unaccelerated FB driver I believe, which does not mean the FB is all that fast though. There are also crads with 3D hardware and even cards allowing to use PCI graphic cards, theoretically. But I don't think there is anything actually supported and in use capable of realtime 3D gaming. Would a Virge 3D card even be good enough to play Tuxracer? Anything that needs realtime GL is probably useless for m68k. So even if you could get hardware GL working remotely m68k just couldn't do it I think. Then why build Mesa/GL packages for 68k and ARM and (probably?) MIPS? Because some users want to use them? Imagine a developer/programmer that has just an old faithfull Amiga with some Virge 3D card, wanting to learn some OpenGL programming. This person can actually use that machine to achieve knowledge about OpenGL programming. If you exclude all OpenGL related packages from that arch, this person will not be able to gain that knowledge. If you just exclude those packages from testing migration, that person can still use an older version of that package in testing, but all the other archs are not blocked by that slower arch for testing migration. -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sat, Oct 14, 2006 at 05:35:57PM -0400, Kevin Mark wrote: However there are some packages which are clearly not sensible on some arches. Numerical analysis software in general on arm is a good example of this class. Arm hardware is generally slow and more seriously has no floating point hardware (except very exceptionally). As you say there are lists. I'm aware of p-a-s and n-f-u lists which provide mechanism for things not being built. I'd also be interested in Ingo's wonderful buildd.net that can provide 'what are the top N things that are taking the longest to build' (per arch) (although this does not take into account something like 'kde' which depends upon many bits to be built) Feel free and invited to join the buildd.net development process! A dependency resolver and other things are already on the todo list, but I'm short of free time for those features. :) Also, from the graphs on % of packages built, it is normally in 80%+ range for short periods of time while is is more often in the 93%+ range. And the 'cut-off' is IIRC 95%+ as the 'release' requirement. So it should only require the removal of a handfull of very intensive packages to get that number up to release status. Yes, removing some packages from being a release criteria would certainly help, although we had huge toolchain issues in the past on m68k. gcc-4.0 was absolutely no good choice for m68k and introduced many, many FTBFS errors. No-one in their right mind would run numerical analysis on an arm box, for any purpose other than testing that they could. The question is who should decide and by what criteria? ftp masters, the maintainers, the porters ? IMHO porters and RMs should decide this issue. Now in an ideal world we would gratutiously build these packages anyway, just to check that they do build on said architecture, but IIRC the buildds do not have a weight attached to each package to determine its order in the buildd queue. Would the introduction of a weight, where resource intensive packages get put on the bottom and are built at 'slow' periods help? W-b has some sort of priority for packages, which made be (ab-)used for this. But that's of course no dependency-resolver as it was proposed for other w-b replacement projects. [0] So, 'is pretty much pointless' has not to date been deemed a reason to mark a package 'not for us'. However, It seems to me that if the porters _and_ the package maintainer agree that there really is no real point in building a package for a particular arch, and it takes signifcant resources to do so, that it is best to mark such packages 'not for us'. There are currently 'release goals' for the entire project. Would it make sense to have 'arch goals' that would include the exclusion of certain packages that are 'not-for-us' with the 'us' being the team that is familiar with the uses of the arch and what should be build? IMHO: yes! [0] http://www.buildd.net/files/Multibuild-Draft.pdf -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
Ron Johnson [EMAIL PROTECTED] writes: On 10/15/06 02:33, Goswin von Brederlow wrote: Ron Johnson [EMAIL PROTECTED] writes: On 10/15/06 00:03, Goswin von Brederlow wrote: Roberto C. Sanchez [EMAIL PROTECTED] writes: On Sat, Oct 14, 2006 at 07:30:15PM +0200, Holger Levsen wrote: [snip] I think it should be in the porters control what packages to build for an arch with some guidelines what sort of packages can be removed without loosing release status. For example removing KDE would not be OK. Removal should be reserved for extreme cases though. Things that just need long to build should be put into weak_no_auto and limited to the stronger buildds of an arch. Why *shouldn't* KDE, GNOME, Firefox/Iceweasel, Tbird, and anything that requires Mesa/OpenGL, and all of Charles Plessy's scientific packages be marked do_not_build on 68k/Coldfire ARM? Because it is perfectly fine to run kde on such a system. Anything that can run gnome can run kde. Anything that can run X can run kde I would even say. Kicking one alternative for something (like kde) but not others (like gnome) should not be allowed. But I *am* saying that porters/maintainers should think about dropping all the heavy CPU- RAM-using packages. Including GNOME. There are things in kde and gnome that aren't such resource hoggers. While I never would run kde or gnome on my Amiga I from time to time enjoyed playing gsame or other little games. I think you would be hard pressed to find an arh where no component of kde or gnome has a use. It is just too big a range of applications. If the port decides that they don't need any X, e.g. there is no hardware capable of running X applications, then they could remove all X stuff as a whole. That would be different from removing kde. But I feel that X, Gnome, KDE is a big part of what makes Debian what it is. If you remove all that is it still Debian? Am I not running Debian if I only have a minimal system installed? Of course I am. XFce, fvwm, BlackBox, AfterStep, WindowManager(?) and jwm would all still let you have a nice low-power system. What if the port decides that they don't need fvwm because everyone from the team uses another wm? Wouldn't you as user be pissed of that your favourite wm isn't available anymore? There should be some guidelines that preserve the flavour of Debian, the wide choice of packages for every taste out there. Something that draws a line between being Debian and for example Embedded-Debian. That should serve both Debian and the port. [snip] If an Amiga (using the unaccelerated fb driver?) is running as an X Terminal for a powerful, modern box, the Amiga would need to process the OpenGL commands, no? There are no amigas with unaccelerated FB driver I believe, which does not mean the FB is all that fast though. There are also crads with 3D hardware and even cards allowing to use PCI graphic cards, theoretically. But I don't think there is anything actually supported and in use capable of realtime 3D gaming. Would a Virge 3D card even be good enough to play Tuxracer? Anything that needs realtime GL is probably useless for m68k. So even if you could get hardware GL working remotely m68k just couldn't do it I think. Then why build Mesa/GL packages for 68k and ARM and (probably?) MIPS? There are non real time uses. A lot of stuff works fine without requiring 50 FPS. For example I wrote a little fractal programm that displays the M-Set in 3D and uses simple distributed computing. I would keep 20 computers at university busy computing over night and display the results on my Amiga. If the image takes 10h on 20 computers to compute then you don't need a high FPS to draw a progress. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
* Kevin Mark | IIRC the buildds do not have a weight attached to each package to | determine its order in the buildd queue. Would the introduction of a | weight, where resource intensive packages get put on the bottom and are | built at 'slow' periods help? This will easily cause problems for those packages's migration to testing, since there will be out-of-date binaries for slow arches in the archive. (Or the release team will have to get the old binaries removed for said slow architectures.) -- 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: How should we deal with 'pointless-on-this-arch' packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/06 04:24, Ingo Juergensmann wrote: On Sun, Oct 15, 2006 at 03:16:04AM -0500, Ron Johnson wrote: [snip] I don't think this is good. Basically a user should be able to choose if s/he would like to use Gnome or KDE. Wookeys proposal was about dropping those packages from being a release criteria, not about dropping them at all from that arch. Ah, ok. - -- Ron Johnson, Jr. Jefferson LA USA Is common sense really valid? For example, it is common sense to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that common sense is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFMgf9S9HxQb37XmcRAqoAAJ9ypki2kN4ZTGNBzN6c7mY11QOfwwCg3IyV 60TCOWR8uhZgsRrTUNpIboI= =mT5V -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sun, Oct 15, 2006 at 09:33:51AM +0200, Goswin von Brederlow wrote: If an Amiga (using the unaccelerated fb driver?) is running as an X Terminal for a powerful, modern box, the Amiga would need to process the OpenGL commands, no? There are no amigas with unaccelerated FB driver I believe, which does not mean the FB is all that fast though. There are also crads with 3D hardware and even cards allowing to use PCI graphic cards, theoretically. But I don't think there is anything actually supported and in use capable of realtime 3D gaming. Would a Virge 3D card even be good enough to play Tuxracer? Anything that needs realtime GL is probably useless for m68k. X is generally moving towards GL, so 3D games are not everything. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
Ron Johnson wrote: Why *shouldn't* KDE, GNOME, Firefox/Iceweasel, Tbird, and anything that requires Mesa/OpenGL, and all of Charles Plessy's scientific packages be marked do_not_build on 68k/Coldfire ARM? Well, just for example, I know of people who run firefox on arm. -- see shy jo signature.asc Description: Digital signature
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sun, Oct 15, 2006 at 01:10:33PM -0400, Joey Hess [EMAIL PROTECTED] wrote: Ron Johnson wrote: Why *shouldn't* KDE, GNOME, Firefox/Iceweasel, Tbird, and anything that requires Mesa/OpenGL, and all of Charles Plessy's scientific packages be marked do_not_build on 68k/Coldfire ARM? Well, just for example, I know of people who run firefox on arm. Considering how we (firefox maintainers) got fixes for firefox on arm, mips, m68k and hppa, i can confirm that it is indeed used on architectures noone would have imagined it to be used ;) Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/06 14:28, Mike Hommey wrote: On Sun, Oct 15, 2006 at 01:10:33PM -0400, Joey Hess [EMAIL PROTECTED] wrote: Ron Johnson wrote: Why *shouldn't* KDE, GNOME, Firefox/Iceweasel, Tbird, and anything that requires Mesa/OpenGL, and all of Charles Plessy's scientific packages be marked do_not_build on 68k/Coldfire ARM? Well, just for example, I know of people who run firefox on arm. Considering how we (firefox maintainers) got fixes for firefox on arm, mips, m68k and hppa, i can confirm that it is indeed used on architectures noone would have imagined it to be used ;) I guess that's the answer, then... ;) What about Wookey's not_RC idea? - -- Ron Johnson, Jr. Jefferson LA USA Is common sense really valid? For example, it is common sense to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that common sense is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFMsVZS9HxQb37XmcRAgKpAKCbR79qVHbHNDqKfpILC30kCoYiggCgg9RL /f7BkKuKfIadELBtR2P3XIc= =yQZt -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
How should we deal with 'pointless-on-this-arch' packages?
In general debian builds everything for every architecture. This is a very good plan and finds a lot of bugs. However there are some packages which are clearly not sensible on some arches. Numerical analysis software in general on arm is a good example of this class. Arm hardware is generally slow and more seriously has no floating point hardware (except very exceptionally). No-one in their right mind would run numerical analysis on an arm box, for any purpose other than testing that they could. Now in an ideal world we would gratutiously build these packages anyway, just to check that they do build on said architecture, but there is a cost to doing this. Buildd time and archive space. Buildd time particularly, for slow arches, is a resource we don't have a huge abundance of. So, 'is pretty much pointless' has not to date been deemed a reason to mark a package 'not for us'. However, It seems to me that if the porters _and_ the package maintainer agree that there really is no real point in building a package for a particular arch, and it takes signifcant resources to do so, that it is best to mark such packages 'not for us'. However I don't think we should just start doing this unilaterally, so I am posting here to canvass opinion. Should inappropriateness be a criterion for deciding a package is not-for-us? Should we perhaps have a more general mechanism than such ad-hoc marking to indicate innappropriate combinations of package and architecture? An example of this genre is fityk, which currently times out on arm, trying to build large C++ files. It is curve-fitting software. It could probably be built, but one wonders if it is worth the effort. The author is happy to not have it built for arm. I'm sure there are others in the same situation, although I have not done extensive research to try and produce a list. (cc: me - I'm not subscribed) Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sat, Oct 14, 2006 at 02:30:14AM +0100, Wookey wrote: In general debian builds everything for every architecture. This is a very good plan and finds a lot of bugs. Agreed. However there are some packages which are clearly not sensible on some arches. Numerical analysis software in general on arm is a good example of this class. Arm hardware is generally slow and more seriously has no floating point hardware (except very exceptionally). Same for m68k. Additionally such packages like flightgear don't make much sense on those archs. No-one in their right mind would run numerical analysis on an arm box, for any purpose other than testing that they could. ... or to find bugs. Now in an ideal world we would gratutiously build these packages anyway, just to check that they do build on said architecture, but there is a cost to doing this. Buildd time and archive space. Buildd time particularly, for slow arches, is a resource we don't have a huge abundance of. Very true, especially before freeze when every maintainer uploads frequently to get new and hopefully bug-fixed version in... So, 'is pretty much pointless' has not to date been deemed a reason to mark a package 'not for us'. However, It seems to me that if the porters _and_ the package maintainer agree that there really is no real point in building a package for a particular arch, and it takes signifcant resources to do so, that it is best to mark such packages 'not for us'. Placing a package in N-F-U is mostly done for FTBFS reasons or if upstream doesn't support that arch. However I don't think we should just start doing this unilaterally, so I am posting here to canvass opinion. Should inappropriateness be a criterion for deciding a package is not-for-us? I think yes, it should be... to some degree at least... Should we perhaps have a more general mechanism than such ad-hoc marking to indicate innappropriate combinations of package and architecture? An example of this genre is fityk, which currently times out on arm, trying to build large C++ files. It is curve-fitting software. It could probably be built, but one wonders if it is worth the effort. The author is happy to not have it built for arm. I'm sure there are others in the same situation, although I have not done extensive research to try and produce a list. I believe the Vancouver proposal went into wrong direction by excluding (slower) archs from releases. Of course, dropping archs is a quick and easy way to lighten the load for a release, but IMHO it is wrong, because it's damaging and destroying one of Debians biggest strengths: being an universal OS that can be run on nearly every arch. Of course nobody wants to extent the releases beyond any sane time just due to some slower archs. The question is: how can Debian release more frequently and on time even when some slower archs are falling behind and can't keep up with 6100 source packages? The answer is quite simple: reduce the load for those archs by not forcing them to build *every* package, but only a certain subset of them. I think everyone will agree that every arch should have a basic set of packages to be suitable to use it like some shells, some editors, ssh, debian-installer, compilers, linkers, etc. It doesn't make much sense to build all Desktop related packages for an arch that is mainly used remotely or as an embedded device. I don't think that anyone will run KDE on top of an NSLU2 or on a Linksys WRT54G. Same may be valid for m68k, although there *are* users that are using their m68ks as an X-Terminal or such. But those are rare. So, it's better, IMHO, to reduce the number of packages for those archs by defining some sort of requirements: - what is *required* to make use of that arch (f.e. example packages in section base, admin or with priority required)? - what is commonly used on those archs? popcon can gives some hints like MTAs, fetchmail, UUCP, DHCP-stuff or similar things (gcc, debugger, ...) - what is rarely used? (Desktop Environments, Browsers, numerical analysis tools) - what is unuseable on that arch? (qemu, Xen, flight simulators, cluster software, ...) When an arch doesn't need to have *all* of the archive to build, like KDE, Gnome, the arch (and the porters!) have more resources to get the important packages being build. *If* resources aren't exhausted, the arch *can* build stuff that isn't that necessary for that arch and its users. And even more, if it can be released with the other archs, the users are happy and being able to compile needed packages on their own if they need some other packages, that haven't found their way into the release for that arch. M68k was the first port that got released by Debian and it's the first arch that got dropped from the release. And it showed now that it's unclear how the port should be handled after the drop. Can it be released in a point-release later? Does it need to wait for etch+1? I think m68k
Re: How should we deal with 'pointless-on-this-arch' packages?
Hello, I agree with most of what Wookey and you said, but would like some clarification on this: On Sat, 14.10.2006 at 12:06:20 +0200, Ingo Juergensmann [EMAIL PROTECTED] wrote: But sadly, I have very little hope that Debian will change anything it's release structure soon. *sigh* Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
On 2006-10-14 12:06 +0200, Ingo Juergensmann wrote: On Sat, Oct 14, 2006 at 02:30:14AM +0100, Wookey wrote: I believe the Vancouver proposal went into wrong direction by excluding (slower) archs from releases. Of course, dropping archs is a quick and easy way to lighten the load for a release, but IMHO it is wrong, because it's damaging and destroying one of Debians biggest strengths: being an universal OS that can be run on nearly every arch. Of course nobody wants to extent the releases beyond any sane time just due to some slower archs. The question is: how can Debian release more frequently and on time even when some slower archs are falling behind and can't keep up with 6100 source packages? The answer is quite simple: reduce the load for those archs by not forcing them to build *every* package, but only a certain subset of them. I think everyone will agree that every arch should have a basic set of packages to be suitable to use it like some shells, some editors, ssh, debian-installer, compilers, linkers, etc. It doesn't make much sense to build all Desktop related packages for an arch that is mainly used remotely or as an embedded device. I don't think that anyone will run KDE on top of an NSLU2 or on a Linksys WRT54G. No - but they might well run it on an Iyonix, and maybe even a balloon. Even though arm is mostly-embedded there are a few desktop machines (which merely illustrates the problem of general package classifications). Same may be valid for m68k, although there *are* users that are using their m68ks as an X-Terminal or such. But those are rare. As you say m68k is leading the way in terms of still being a useful arch but not able to cope with 'all of debian'. Arm is following. So, it's better, IMHO, to reduce the number of packages for those archs by defining some sort of requirements: - what is *required* to make use of that arch (f.e. example packages in section base, admin or with priority required)? - what is commonly used on those archs? popcon can gives some hints like MTAs, fetchmail, UUCP, DHCP-stuff or similar things (gcc, debugger, ...) - what is rarely used? (Desktop Environments, Browsers, numerical analysis tools) - what is unuseable on that arch? (qemu, Xen, flight simulators, cluster software, ...) Clearly something like this could be a general solution to the problem. I do think there is value in defining characteristics of packages so that choice can be made, but it is not an easy thing to do. Even on a slow arch which is not normally used as a desktop, desktop packages are often needed. Should such classification be done per-arch, or generally. Should we perhaps have 'core' and 'other' (like ubuntu's main and multiverse (or whatever it which)). Perhaps debtags could be used as an appropriate classification mechanism. Perhaps embedded debian could be developed to fill the 'smaller machine' niche, although that is not necessarily a very good fit (emdebian is about shrinking all packages as well as subsetting). And any such descisions have implications for how the release process is managed. Nevertheless I think it is clear that we do need mechanisms to keep the load and package set appropriate for slower arches. If we design the mechanism properly I would hope it could be useful for various categorisation/subsetting purposes within debian. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sat, Oct 14, 2006 at 12:21:35PM +0200, Toni Mueller wrote: I agree with most of what Wookey and you said, but would like some clarification on this: On Sat, 14.10.2006 at 12:06:20 +0200, Ingo Juergensmann [EMAIL PROTECTED] wrote: But sadly, I have very little hope that Debian will change anything it's release structure soon. *sigh* What do you want to hear? What clarification do you need? I think it is known that some changes in Debian needs a lng time. Adding amd64 to the archive is an example. -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] gpg pubkey: http://www.juergensmann.de/ij/public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
Hi, On Saturday 14 October 2006 12:51, Wookey wrote: Nevertheless I think it is clear that we do need mechanisms to keep the load and package set appropriate for slower arches. If we design the mechanism properly I would hope it could be useful for various categorisation/subsetting purposes within debian. Isn't it up to the maintainer to say $package is not suited for $architecture? And aren't maintainers happy to receive hints (e.g. from porters or users of a certain package), which specific package is not suited for a specific architecture? regards, Holger pgpp06gZIloAl.pgp Description: PGP signature
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sat, Oct 14, 2006 at 07:30:15PM +0200, Holger Levsen wrote: Isn't it up to the maintainer to say $package is not suited for $architecture? And aren't maintainers happy to receive hints (e.g. from porters or users of a certain package), which specific package is not suited for a specific architecture? I would think that by definition a user of a package is the last person who would be qualified to make a determinitation as to whether a particular pacakge is suitable for a particular architecture. Regards, -Roberto -- Roberto C. Sanchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sat, Oct 14, 2006 at 02:30:14AM +0100, Wookey wrote: In general debian builds everything for every architecture. This is a very good plan and finds a lot of bugs. Hi Wookey, endian bugs, 32/64 bit bugs, int size bugs, more eyes on bad code, more users on bad code, low-mem compiling, low-mem installs, more testing of the Debian infrastrure (apt,debconf,pre/post install scripts) and providing 'practice' for porters x-) These are the 'good' reasons not to do this. However there are some packages which are clearly not sensible on some arches. Numerical analysis software in general on arm is a good example of this class. Arm hardware is generally slow and more seriously has no floating point hardware (except very exceptionally). As you say there are lists. I'm aware of p-a-s and n-f-u lists which provide mechanism for things not being built. I'd also be interested in Ingo's wonderful buildd.net that can provide 'what are the top N things that are taking the longest to build' (per arch) (although this does not take into account something like 'kde' which depends upon many bits to be built) I've read that the ftpmasters consider it a bug if someone adds an arch to p-a-s unless there is substantial reason, and n-f-u has a specific use case that would not be suitable for this either. So maybe a new list for packages that are buildd intensive and would not benfit the arch use case for being built -- may call it packages-that-are-too-resource-intensive as I dont see some tiny 10k package being dropped but only large ones. Also, from the graphs on % of packages built, it is normally in 80%+ range for short periods of time while is is more often in the 93%+ range. And the 'cut-off' is IIRC 95%+ as the 'release' requirement. So it should only require the removal of a handfull of very intensive packages to get that number up to release status. No-one in their right mind would run numerical analysis on an arm box, for any purpose other than testing that they could. The question is who should decide and by what criteria? ftp masters, the maintainers, the porters ? Now in an ideal world we would gratutiously build these packages anyway, just to check that they do build on said architecture, but IIRC the buildds do not have a weight attached to each package to determine its order in the buildd queue. Would the introduction of a weight, where resource intensive packages get put on the bottom and are built at 'slow' periods help? there is a cost to doing this. Buildd time and archive space. Buildd time particularly, for slow arches, is a resource we don't have a huge abundance of. So, 'is pretty much pointless' has not to date been deemed a reason to mark a package 'not for us'. However, It seems to me that if the porters _and_ the package maintainer agree that there really is no real point in building a package for a particular arch, and it takes signifcant resources to do so, that it is best to mark such packages 'not for us'. There are currently 'release goals' for the entire project. Would it make sense to have 'arch goals' that would include the exclusion of certain packages that are 'not-for-us' with the 'us' being the team that is familiar with the uses of the arch and what should be build? However I don't think we should just start doing this unilaterally, so I am posting here to canvass opinion. Should inappropriateness be a criterion for deciding a package is not-for-us? snippage just my 2 centieuros, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Re: How should we deal with 'pointless-on-this-arch' packages?
Le Sat, Oct 14, 2006 at 11:51:49AM +0100, Wookey a écrit : Perhaps debtags could be used as an appropriate classification mechanism. Hi all, As a maintainer of scientific packages, I agree with this idea. I always feel sorry to see my packages sitting in the queue of slow arches while I am very confident that nobody will use them on such computers. The interest with debtags is that it allows to change the policy for a package without needing an upload or the intervention of the maintainer. This way, the decision of not building could be taken by the maintainer, and it could be reverted quickly by somebody else if a user requested the package on an excluded arch. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
Roberto C. Sanchez [EMAIL PROTECTED] writes: On Sat, Oct 14, 2006 at 07:30:15PM +0200, Holger Levsen wrote: Isn't it up to the maintainer to say $package is not suited for $architecture? And aren't maintainers happy to receive hints (e.g. from porters or users of a certain package), which specific package is not suited for a specific architecture? I would think that by definition a user of a package is the last person who would be qualified to make a determinitation as to whether a particular pacakge is suitable for a particular architecture. Regards, -Roberto I think that the maintainer is qualified saying This source can't support an arch. Porting/maintaining the stuff is too difficult. The proters are probably qualified saying This package is insane, nobody in his/her right mind will want to run this. E.g. the arch just lacks the hardware and processing power to run a realtime 3D game. The porters should also be the best judge about lack of speed on the buildds. A user is qualified saying I want to run this software on my arch. I can't live without it even if it crawls. I think it should be in the porters control what packages to build for an arch with some guidelines what sort of packages can be removed without loosing release status. For example removing KDE would not be OK. Removal should be reserved for extreme cases though. Things that just need long to build should be put into weak_no_auto and limited to the stronger buildds of an arch. Maybe someone could come up with a britney patch that would allow an arch to make a list of package non-blocking for the testing transition. A package like axiom should not be blocked from testing because m68k hasn't build it yet. It should be perfectly save to remove it for m68k till such a time that the buildds catch up. Things that the porters/maintainer are reasonably sure noone will miss but we try to build it just in case anyway. I think a lot of the potential excludes fall under this category. Just my 2c. Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How should we deal with 'pointless-on-this-arch' packages?
On Sun, 15 Oct 2006, Charles Plessy wrote: The interest with debtags is that it allows to change the policy for a package without needing an upload or the intervention of the maintainer. This way, the decision of not building could be taken by the maintainer, and it could be reverted quickly by somebody else if a user requested the package on an excluded arch. How would you implement with with debtags? Are the buildd's paying attention to this now? Maybe I misunderstand. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED]http://www.iit.edu/~segre[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
