Re: CVS: cvs.openbsd.org: ports (fwd) (fwd) (fwd)
On 04/08/15(Tue) 17:49, Stuart Henderson wrote: > On 2015/08/03 14:49, Martin Pieuchot wrote: > > On 03/08/15(Mon) 14:15, Pascal Stumpf wrote: > > > I actually follow that practice for most games I maintain that require a > > > "beefier" machine, although they may build and package just fine on > > > !(amd64 || i386): vegastrike, speeddreams, flightgear, sumwars. I > > > believe enabling those on powerpc would only increase bulk build times > > > for very little gain. > > > > What you say is true for... let me guess... 95% of the ports we build on > > such architecture. Should we stop building packages then? > > While I generally agree, these 5 particular ports account for 3.5GB > of packages per arch. File distribution from the fanout to some of the > 2nd-level mirrors has never been particularly fast (plus it takes a > while to gzip this amount of data on a machine with slower CPU and > disks, and build times there are already pretty long) so disabling > these particular ports on arch where they aren't playable makes > a lot of sense to me. Indeed, that makes sense to me too.
Re: CVS: cvs.openbsd.org: ports (fwd) (fwd) (fwd)
On 2015/08/03 14:49, Martin Pieuchot wrote: > On 03/08/15(Mon) 14:15, Pascal Stumpf wrote: > > I actually follow that practice for most games I maintain that require a > > "beefier" machine, although they may build and package just fine on > > !(amd64 || i386): vegastrike, speeddreams, flightgear, sumwars. I > > believe enabling those on powerpc would only increase bulk build times > > for very little gain. > > What you say is true for... let me guess... 95% of the ports we build on > such architecture. Should we stop building packages then? While I generally agree, these 5 particular ports account for 3.5GB of packages per arch. File distribution from the fanout to some of the 2nd-level mirrors has never been particularly fast (plus it takes a while to gzip this amount of data on a machine with slower CPU and disks, and build times there are already pretty long) so disabling these particular ports on arch where they aren't playable makes a lot of sense to me. Maybe things like irrlamb would be better options if looking at drm on powerpc?
Re: CVS: cvs.openbsd.org: ports (fwd) (fwd) (fwd)
On Mon, 3 Aug 2015 14:49:53 +0200, Martin Pieuchot wrote: > On 03/08/15(Mon) 14:15, Pascal Stumpf wrote: > > On Sun, 2 Aug 2015 12:10:49 +0200, Martin Pieuchot wrote: > > > On 02/08/15(Sun) 10:03, Landry Breuil wrote: > > > > On Sun, Aug 02, 2015 at 09:55:39AM +0200, Antoine Jacoutot wrote: > > > > > On Sat, Aug 01, 2015 at 05:07:30PM -0600, Pascal Stumpf wrote: > > > > > > CVSROOT:/cvs > > > > > > Module name:ports > > > > > > Changes by: pas...@cvs.openbsd.org 2015/08/01 17:07:30 > > > > > > > > > > > > Modified files: > > > > > > games/supertuxkart: Makefile > > > > > > > > > > > > Log message: > > > > > > Don't even attempt to build this on anything but amd64 and i386. > > > > > > 3D ac > > cel > > > > > > isn't nearly good enough to run it on sparc64 or macppc. > > > > > > What do you mean by "3D accel isn't nearly good enough"? On which > > > macppc did you try to run supertuxkart? Are you talking about the > > > popup saying that the OpenGL driver is too old and should be upgraded? > > > > No, I mean the hardware be able to handle this game, no matter how good > > our support gets. It barely runs on my modern amd64 machines at <30 > > fps. That makes it pretty much unplayable on even the best macppc > > machines. Thus I think claiming to "support" this port on macppc is a > > lie. > > What do you mean by "supporting" a port? Having it in a state where it is generally usable and I am able to solve any small problems users encounter by myself. > > Also, upstream has ceased to support Linux and OS X PowerPC in version > > 0.9. > > This quite common in OSS ecosystems if nobody does the work. Or if the program suddenly has requirements that cannot possibly be met by the hardware, and thus the effort is futile. For instance, STK 0.9 requires OpenGL 3.1. According to the matrix here: https://wiki.freedesktop.org/xorg/RadeonFeature/ that support is only possible with R600 onwards, i.e. a HD2xxx card or better. I believe Apple never produced a machine with that kind of card. > > I actually follow that practice for most games I maintain that require a > > "beefier" machine, although they may build and package just fine on > > !(amd64 || i386): vegastrike, speeddreams, flightgear, sumwars. I > > believe enabling those on powerpc would only increase bulk build times > > for very little gain. > > What you say is true for... let me guess... 95% of the ports we build on > such architecture. Umm no, not really. There aren't THAT many ports depending on GL acceleration to run. > Should we stop building packages then? > > > > If that's the case don't you think it's simply a matter of upgrading > > > Mesa? Or does (the embedded version of) Irrlicht requires a "modern" > > > graphic card? > > > > > > Note that 3D acceleration on macppc is slower than it could be ATM > > > because we're not using the AGP GART. > > > > > > > > Hmm I am not sure I like this -- the above is true for a lot of other > > > > > por > > ts as well. > > > > > There is ongoing work on 3D and macppc and it's nice to have things > > > > > we ca > > n test. > > > > > Besides being slow, is there any actual breakage? > > > > > > > > Fwiw supertuxkart packaged in current macppc bulk. > > > > > > It also runs badly. There's some truth in what Pascal says. But I > > > believe that with a some efforts invested in the graphic stack it > > > should be possible to run it correctly. > > > > > > Sadly disabling the port prevent people to figure that out. > > > > I disagree. If you're smart enough to hack on powerpc drm(4), you're > > probably smart enough to build the package yourself if you think it's a > > worthwhile test/target program to improve. > > It's not a question of being smart, your completely missing my point, > it's about choice. How can somebody figure out that OpenBSD/X11 graphic > stack needs some love and/or the port itself needs to be adapted for > older hardware if it cannot even install and try the game? I don't think it takes a failed attempt at running STK to figure that out. But since you obviously have some use for the package during development, I will re-enable it on macppc, even if it doesn't make sense to me. :) > If you can try, at least you can decide where to spend your > time/money/energy. > > > But official packages are built for end users. And having a > > supertuxkart-0.9.tgz in the powerpc directory will lead them to think > > this package actually works on powerpc. Which it doesn't, be it because > > of limited driver support or actual hardware limitations. > > The same should be said for firefox and libreoffice and not only on > powerpc but on even on not-so-recent i386. I think it's not our job > to care if end users' machine are powerful enough for bloated software. Well, libreoffice is already only for amd64/i386, and firefox ran fine on powerpc last I heard. The difference with i386 is that you can always install it on a powerful machine, but the
Re: CVS: cvs.openbsd.org: ports (fwd) (fwd) (fwd)
On 03/08/15(Mon) 14:15, Pascal Stumpf wrote: > On Sun, 2 Aug 2015 12:10:49 +0200, Martin Pieuchot wrote: > > On 02/08/15(Sun) 10:03, Landry Breuil wrote: > > > On Sun, Aug 02, 2015 at 09:55:39AM +0200, Antoine Jacoutot wrote: > > > > On Sat, Aug 01, 2015 at 05:07:30PM -0600, Pascal Stumpf wrote: > > > > > CVSROOT: /cvs > > > > > Module name: ports > > > > > Changes by: pas...@cvs.openbsd.org 2015/08/01 17:07:30 > > > > > > > > > > Modified files: > > > > > games/supertuxkart: Makefile > > > > > > > > > > Log message: > > > > > Don't even attempt to build this on anything but amd64 and i386. 3D > > > > > ac > cel > > > > > isn't nearly good enough to run it on sparc64 or macppc. > > > > What do you mean by "3D accel isn't nearly good enough"? On which > > macppc did you try to run supertuxkart? Are you talking about the > > popup saying that the OpenGL driver is too old and should be upgraded? > > No, I mean the hardware be able to handle this game, no matter how good > our support gets. It barely runs on my modern amd64 machines at <30 > fps. That makes it pretty much unplayable on even the best macppc > machines. Thus I think claiming to "support" this port on macppc is a > lie. What do you mean by "supporting" a port? > Also, upstream has ceased to support Linux and OS X PowerPC in version > 0.9. This quite common in OSS ecosystems if nobody does the work. > I actually follow that practice for most games I maintain that require a > "beefier" machine, although they may build and package just fine on > !(amd64 || i386): vegastrike, speeddreams, flightgear, sumwars. I > believe enabling those on powerpc would only increase bulk build times > for very little gain. What you say is true for... let me guess... 95% of the ports we build on such architecture. Should we stop building packages then? > > If that's the case don't you think it's simply a matter of upgrading > > Mesa? Or does (the embedded version of) Irrlicht requires a "modern" > > graphic card? > > > > Note that 3D acceleration on macppc is slower than it could be ATM > > because we're not using the AGP GART. > > > > > > Hmm I am not sure I like this -- the above is true for a lot of other > > > > por > ts as well. > > > > There is ongoing work on 3D and macppc and it's nice to have things we > > > > ca > n test. > > > > Besides being slow, is there any actual breakage? > > > > > > Fwiw supertuxkart packaged in current macppc bulk. > > > > It also runs badly. There's some truth in what Pascal says. But I > > believe that with a some efforts invested in the graphic stack it > > should be possible to run it correctly. > > > > Sadly disabling the port prevent people to figure that out. > > I disagree. If you're smart enough to hack on powerpc drm(4), you're > probably smart enough to build the package yourself if you think it's a > worthwhile test/target program to improve. It's not a question of being smart, your completely missing my point, it's about choice. How can somebody figure out that OpenBSD/X11 graphic stack needs some love and/or the port itself needs to be adapted for older hardware if it cannot even install and try the game? If you can try, at least you can decide where to spend your time/money/energy. > But official packages are built for end users. And having a > supertuxkart-0.9.tgz in the powerpc directory will lead them to think > this package actually works on powerpc. Which it doesn't, be it because > of limited driver support or actual hardware limitations. The same should be said for firefox and libreoffice and not only on powerpc but on even on not-so-recent i386. I think it's not our job to care if end users' machine are powerful enough for bloated software.
Re: CVS: cvs.openbsd.org: ports (fwd) (fwd) (fwd)
Sorry, forwarding this mail again since it seems my ISP is currently SORBS-blacklisted. :( --- Forwarded Message Date:Mon, 03 Aug 2015 12:20:48 +0200 From:Pascal Stumpf To: Martin Pieuchot cc: ports-changes@openbsd.org Subject: Re: CVS: cvs.openbsd.org: ports On Sun, 2 Aug 2015 12:10:49 +0200, Martin Pieuchot wrote: > On 02/08/15(Sun) 10:03, Landry Breuil wrote: > > On Sun, Aug 02, 2015 at 09:55:39AM +0200, Antoine Jacoutot wrote: > > > On Sat, Aug 01, 2015 at 05:07:30PM -0600, Pascal Stumpf wrote: > > > > CVSROOT:/cvs > > > > Module name:ports > > > > Changes by: pas...@cvs.openbsd.org 2015/08/01 17:07:30 > > > > > > > > Modified files: > > > > games/supertuxkart: Makefile > > > > > > > > Log message: > > > > Don't even attempt to build this on anything but amd64 and i386. 3D ac cel > > > > isn't nearly good enough to run it on sparc64 or macppc. > > What do you mean by "3D accel isn't nearly good enough"? On which > macppc did you try to run supertuxkart? Are you talking about the > popup saying that the OpenGL driver is too old and should be upgraded? No, I mean the hardware be able to handle this game, no matter how good our support gets. It barely runs on my modern amd64 machines at <30 fps. That makes it pretty much unplayable on even the best macppc machines. Thus I think claiming to "support" this port on macppc is a lie. Also, upstream has ceased to support Linux and OS X PowerPC in version 0.9. I actually follow that practice for most games I maintain that require a "beefier" machine, although they may build and package just fine on !(amd64 || i386): vegastrike, speeddreams, flightgear, sumwars. I believe enabling those on powerpc would only increase bulk build times for very little gain. > If that's the case don't you think it's simply a matter of upgrading > Mesa? Or does (the embedded version of) Irrlicht requires a "modern" > graphic card? > > Note that 3D acceleration on macppc is slower than it could be ATM > because we're not using the AGP GART. > > > > Hmm I am not sure I like this -- the above is true for a lot of other por ts as well. > > > There is ongoing work on 3D and macppc and it's nice to have things we ca n test. > > > Besides being slow, is there any actual breakage? > > > > Fwiw supertuxkart packaged in current macppc bulk. > > It also runs badly. There's some truth in what Pascal says. But I > believe that with a some efforts invested in the graphic stack it > should be possible to run it correctly. > > Sadly disabling the port prevent people to figure that out. I disagree. If you're smart enough to hack on powerpc drm(4), you're probably smart enough to build the package yourself if you think it's a worthwhile test/target program to improve. But official packages are built for end users. And having a supertuxkart-0.9.tgz in the powerpc directory will lead them to think this package actually works on powerpc. Which it doesn't, be it because of limited driver support or actual hardware limitations. > Now if you guys are interested in reducing the bulk time for macppc and > sparc64 may I suggest to not build Irrlicht twice? As stsp@ pointed out, the developers have essentially forked irrlicht, and bullet too. It plainly won't work with stock versions. Yeah, it sucks for downstream packagers and they know it ... --- End of Forwarded Message
