Re: [gentoo-dev] games.eclass
On Sat, Aug 22, 2015 at 3:33 AM, Daniel Campbell (zlg) z...@gentoo.org wrote: Great question on the 'cdinstall' flag. Games from Humble Bundle and GOG are basically fetch-restricted and require the user to put the relevant distfile in /usr/portage/distfiles to install. 'cdinstall' could be applied only for games that the user wants to install via optical media. With it off, it could default to the fetch restriction. However, that could result in different checksums for the source. It may not be feasible to go the cdinstall route forever. Honestly, I'd need a concrete example and knowledge of the other releases to offer a better-informed opinion. You hit a few issues here, and without trying to solution any of them I'll elaborate just a bit more, and I think it does make a case for there being value in a team focused on games: 1. As there is more emphasis on CI/QA/etc how do we control quality on proprietary packages? 2. How do we know if a proprietary ebuild even builds/works? 3. What is our stance on maintainership/responsiveness/etc on these kinds of packages, since we're so dependent on maintainers who have access? Besides this there is also the fact that games tend to be demanding on graphics drivers and opengl/sdl/etc. I think hasufell works on games... thoughts? I've actually had a few contact me privately now expressing interest in games, so perhaps there is an opportunity to put the band back together. If anybody else would like to be among them please let me know, and for those who have contacted me thanks and if you have concerns with me sharing your name/address (but not any private comments you have made) with the rest of the interested team please let me know. Also, thanks for those who have taken a bit of time to vent frustrations both on the list and privately. I'd like to see something constructive come out of all this, as James recently expressed. I don't want to promise miracles though - I will say that some frustrations I've seen expressed (by more than one on this topic already) are the sorts of things you can find on blogs across the FOSS world. We do work that is important and often unpaid. We tend to have deep technical skills but exercise them in huge communities where interpersonal issues become magnified. We are activists and artists and architects all at once. We're changing the world in ways that are often unnoticed not only by the public, but by ourselves. This is true of the entire FOSS world, but it seems especially true of Gentoo. -- Rich
Re: [gentoo-dev] games.eclass
On 08/22/2015 09:33 AM, Daniel Campbell (zlg) wrote: On 08/21/2015 02:09 PM, James Le Cuirot wrote: On Fri, 21 Aug 2015 12:42:07 -0700 Daniel Campbell (zlg) z...@gentoo.org wrote: Sure, we did drop this, but I don't really see this line of argument actually accomplishing anything productive. Creating a games team that fixes these issues would be productive. Letting others fix them is also productive. Nobody is opposed to having a games project - it just seems like nobody cares enough to actually make it happen. That's ok - we can still get things done. What would be required to revive the games project? One of the reasons I became a dev was to help out the games team, and if it's defunct, I want to see what's necessary to fix it. I'm still a new dev (May 2015), but I wouldn't mind doing some dirty work if it means we can put squabbles like this behind us and get enough devs together to give game ebuilds the attention they deserve. I don't have a lot of free time, but sitting here discussing stuff isn't fixing anything, either... If I can spend what little Gentoo time I have on fixing things, I'd be glad to. At last, some positivity! As I said before, I would like to work on a few games too. I would certainly take up any Java-based ones and I have four of those in mind already. I've dabbled with ebuilds for many other games in the past, some already in the tree and some not, and some from source, some not. The Humble Bundle games are of particular interest to me. I'm obviously bogged with the more boring Java stuff for the foreseeable future though so as much as I'd like to, stepping up to be a lead would be unwise. I, too, have interest in Humble Bundle games since most of the games I have and can test come from them. Do we actually need a team? Games come in all shapes and sizes so I think the assertion that they should be handled like any other application is somewhat valid. Many games are commercial so it's likely that certain games would only be handled by one or two team members anyway. The main thing I've been concerned about in the past is how to handle data. Should it be packaged separately? How do we handle the cdinstall flag these days when there are also multiple online sources like Humble Bundle and GOG? Do we just do whatever seems best for the game in question? I'd be happy to hold such discussions in a distro-wide fashion though. Despite games being just another application, I think they differ simply because they're a *different type* of application. Fonts and icon-sets are similar to games in that they are mostly assets, and they get the separate treatment they deserve. Games are an odd mix of software and assets, so I think they deserve to be considered their own type of software. They're also built in different ways than most typical software is. Games differ in a lot of ways and they _require_ different policies. In some cases this also means more lax policies and in some cases more strict policies. An example is unbundling libraries. While unbundling libraries is often a good idea for regular well-maintained projects, it can often cause various problems for games: * games upstreams often modify 3rd party libraries * games upstreams often use libraries in very fishy ways, so you really need a very specific version * for proprietary games breakage often happens randomly at runtime * proprietary games may also break silently when library XY is bumped in the tree I've seen both opensource games and proprietary games that break when you unbundle libraries. One example is games-action/supertuxkart that was broken by a lot of packagers (including archlinux), because they didn't ask upstream if it was a good idea to unbundle Irrlicht. It wasn't. Another example is games-rpg/baldurs-gate-ee which has some weird graphical glitches when you unbundle libraries. The primary concern of gamers is that the game runs and that they can reasonably install it (see the games-roguelike/nethack bug which was unsolved for 8 years). Because of that, I provide a 'bundled-libs' USE flag for almost all proprietary games I package (e.g. those from GOG). So in case something breaks, the user can still opt-out of all this. Similarly, when upstream starts to heavily patch a library or when the system version of the library doesn't work half of the time for this game, then I simply drop back to the bundled version (probably creating a bug report or a note for that too), so that people can still enjoy it. And this is just one example where games-specific policies/guidelines are necessary. Another topic is ebuild cleanups which have to be handled differently for various reasons. Great question on the 'cdinstall' flag. Games from Humble Bundle and GOG are basically fetch-restricted and require the user to put the relevant distfile in /usr/portage/distfiles to install. 'cdinstall' could be applied only for games that the user wants to install
Re: [gentoo-dev] games.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/21/2015 02:09 PM, James Le Cuirot wrote: On Fri, 21 Aug 2015 12:42:07 -0700 Daniel Campbell (zlg) z...@gentoo.org wrote: Sure, we did drop this, but I don't really see this line of argument actually accomplishing anything productive. Creating a games team that fixes these issues would be productive. Letting others fix them is also productive. Nobody is opposed to having a games project - it just seems like nobody cares enough to actually make it happen. That's ok - we can still get things done. What would be required to revive the games project? One of the reasons I became a dev was to help out the games team, and if it's defunct, I want to see what's necessary to fix it. I'm still a new dev (May 2015), but I wouldn't mind doing some dirty work if it means we can put squabbles like this behind us and get enough devs together to give game ebuilds the attention they deserve. I don't have a lot of free time, but sitting here discussing stuff isn't fixing anything, either... If I can spend what little Gentoo time I have on fixing things, I'd be glad to. At last, some positivity! As I said before, I would like to work on a few games too. I would certainly take up any Java-based ones and I have four of those in mind already. I've dabbled with ebuilds for many other games in the past, some already in the tree and some not, and some from source, some not. The Humble Bundle games are of particular interest to me. I'm obviously bogged with the more boring Java stuff for the foreseeable future though so as much as I'd like to, stepping up to be a lead would be unwise. I, too, have interest in Humble Bundle games since most of the games I have and can test come from them. Do we actually need a team? Games come in all shapes and sizes so I think the assertion that they should be handled like any other application is somewhat valid. Many games are commercial so it's likely that certain games would only be handled by one or two team members anyway. The main thing I've been concerned about in the past is how to handle data. Should it be packaged separately? How do we handle the cdinstall flag these days when there are also multiple online sources like Humble Bundle and GOG? Do we just do whatever seems best for the game in question? I'd be happy to hold such discussions in a distro-wide fashion though. Despite games being just another application, I think they differ simply because they're a *different type* of application. Fonts and icon-sets are similar to games in that they are mostly assets, and they get the separate treatment they deserve. Games are an odd mix of software and assets, so I think they deserve to be considered their own type of software. They're also built in different ways than most typical software is. Great question on the 'cdinstall' flag. Games from Humble Bundle and GOG are basically fetch-restricted and require the user to put the relevant distfile in /usr/portage/distfiles to install. 'cdinstall' could be applied only for games that the user wants to install via optical media. With it off, it could default to the fetch restriction. However, that could result in different checksums for the source. It may not be feasible to go the cdinstall route forever. Honestly, I'd need a concrete example and knowledge of the other releases to offer a better-informed opinion. I think hasufell works on games... thoughts? - -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJV2CW8AAoJEAEkDpRQOeFwmD4QAK+XDYvgKngBsF2PAZahSrSz zxkp3fRdkTf81ZojI5u3bqby15n93026FoIXCkWEdjcJnV4xIxGDLSqIJ7BfxObS MtGsk48upYO3K0/af4AYCLOU7P8B22SNrkgCYyS0v++4ZOEkdLV+i2TdCXwSEXNW lJig9X3iot1oYRsHHNnmlfPhkHgZsaeox48m1DazxlcWbVDHvcq8kiATaUyOLB1O +nOJEXBMI9bXaUjCW7kX7OGROJrzP6zpU/lGoEE4+jHg1X39chlIUJnJbaBkcHUG MoUc25NLB72C+dPhnsQQPMh/MA4bI6K2IhpIWR1Pthebb+GslwBMxxKkxop+tRpV 2nuz9qRRqVQWN55ugwBlFhG8nUA+jIIFaWNKl/4sF9FyZ1AT/yoZYldvlRF6OtT2 sm9H0XlXr2kdO3kFdD9ZiyA/APivAtBTUxeDGmvAd/iuzrjOUhXNX8zmuVYQGGtu 3C4y3IK9nFpFtAInfTGuwq5iRtfVOt0DmEEwF6ad8qofxigopRkKX0eWOgapeZtx 0PkUjv99bt2lc3Hrn0kA9ECUJ8X8pT3aZhVSuV/bZpwG1fqOTkNzFEQgm15PyMVN v45z3/s6A4dJgZtGdlAB6c0/8kA+Ae4Fg5n65mQJqIoS2UqEQGf8FaTv0YpKYwc1 Qngd4iwJUUpcgm2DNey9 =A20Q -END PGP SIGNATURE-
Re: [gentoo-dev] games.eclass
On Sat, 22 Aug 2015 13:10:54 +0200 hasufell hasuf...@gentoo.org wrote: Great response, thanks! Because of that, I provide a 'bundled-libs' USE flag for almost all proprietary games I package (e.g. those from GOG). So in case something breaks, the user can still opt-out of all this. I like unbundling but I also like this compromise. I wrote a wrapper for launching Minecraft that allows the libraries to be unbundled but because Minecraft updates are automatically downloaded by the official launcher, I had to make it resilient to new dependencies suddenly appearing and I also had to make it easy to disable entirely in the event of problems. As things stand, it is woefully out of date due to my other Java duties but I'll get there. Data ebuilds with cdinstall and optional gog sources are already available, see https://gitweb.gentoo.org/repo/gentoo.git/tree/games-fps/duke3d-data/duke3d-data-1.0-r2.ebuild https://gitweb.gentoo.org/repo/gentoo.git/tree/games-rpg/arx-fatalis-data/arx-fatalis-data-1.21-r2.ebuild REQUIRED_USE=^^ ( cdinstall gog ) That is great use of REQUIRED_USE. Last time I looked at this, REQUIRED_USE didn't exist so I hadn't seen any examples but this is exactly what I would have done. About data ebuilds... they make sense when at least some of these points are true: * data is very very big (you don't want extract 8GB just because you changed an engine USE flag) * upstream provides the engine and the data separately anyway * upstream sometimes bumps the data without bumping the engine or vice versa * we have a lot of data-specific USE flags (you don't want to recompile the whole engine just because you are trying different music-packs) * the data portion uses the cdinstall USE flag (you definitely want to decrease the number of times users have to look for their CD...) In some cases, we are forced to make data ebuilds anyway, e.g. when you have opensource engines for proprietary games. But there's no reason to split off -data ebuilds for every possible package. It's done if it makes sense and doesn't overcomplicate ebuild development and user-side configuration/installation. I'm pleased to say I was thinking along the same lines. This gives me confidence that I could contribute games without upsetting anybody, be it alone or part of a team. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpPMW8AvIpij.pgp Description: OpenPGP digital signature
[gentoo-dev] Last rites: x11-base/nouveau-drm
# Matt Turner matts...@gentoo.org (22 Aug 2015) # nouveau has been in the kernel since 2.6.33 # Masked for removal in 30 days. x11-base/nouveau-drm
Re: [gentoo-dev] games.eclass
On Sat, Aug 22, 2015 at 4:47 PM, hasufell hasuf...@gentoo.org wrote: So my point stands. Games require their own set of policies (and ebuild writing guidelines). I think we're somewhat talking past each other. I'm not debating that it may be beneficial for games to have some specific policies, and those should be taken as they come. However, many of the examples that are coming up don't really strike me as games-specific so much as general issues that apply often to games. Just take it one issue at a time, and think about both the tree and games when you make them. We can always revisit at the distro level if necessary. -- Rich
Re: [gentoo-dev] games.eclass
On 08/22/2015 05:25 PM, Rich Freeman wrote: On Saturday, August 22, 2015, hasufell hasuf...@gentoo.org wrote: Games differ in a lot of ways and they _require_ different policies. In some cases this also means more lax policies and in some cases more strict policies. An example is unbundling libraries. While unbundling libraries is often a good idea for regular well-maintained projects, it can often cause various problems for games: * games upstreams often modify 3rd party libraries * games upstreams often use libraries in very fishy ways, so you really need a very specific version * for proprietary games breakage often happens randomly at runtime * proprietary games may also break silently when library XY is bumped in the tree While I get what you're saying, none of the specific issues you listed are actually unique to games, especially FOSS games. These sorts of issues tend to happen with lots of desktop/multimedia-oriented applications. I do agree that they hit games pretty hard though and games maintainers should have a forum for discussing them. Sure. You could say that there is no herd with special ebuilds. They all have build systems, bundled libraries and dependencies. But that was not the point. The point are the common pitfalls and the way they are handled. And that may differ greatly from other projects/herds, because you must keep in mind what your users expect and what is reasonable in that context. Tree-cleaning a vulnerable proprietary game is not reasonable. You just hardmask it. That is different for kernel packages. There are lots of other examples. Most herds (like python, ruby and whatnot) have their own understanding of consistency and quality that particularly applies to their domain. You can't make everything global. Some thing you should make global (e.g. if it is about dependency resolution, when to do revision bumps and so on) and others not. So my point stands. Games require their own set of policies (and ebuild writing guidelines).
Re: [gentoo-dev] Re: Excessive rsync time after git migration
150815 Holger Hoffstätte wrote: On Sat, 15 Aug 2015 15:29:21 -0400, Joshua Kinard wrote: I've been super-busy as of late and just recently ran 'emerge --sync' on my main dev box for the first time after the git migration. I just synced my main dev box again, ~10 hours after the last sync, but it looks like the 'Manifest' files for *every* package in the tree are getting downloaded with each sync. https://bugs.gentoo.org/show_bug.cgi?id=557192 I've just done my weekly 'eix-sync', which took c 2 min : it seems smoother than in CVS days lack the lengthy 'metadata' list. The problem seems to have been solved : thanks to whoever fixed it. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] games.eclass
On 08/22/2015 08:01 PM, Daniel Campbell (zlg) wrote: The primary concern of gamers is that the game runs and that they can reasonably install it (see the games-roguelike/nethack bug which was unsolved for 8 years). What happened with that bug? 8 years? That's insane! It got fixed in several overlays and then later got force-fixed by QA. And this is just one example where games-specific policies/guidelines are necessary. Another topic is ebuild cleanups which have to be handled differently for various reasons. What ebuild cleanups are we talking about, specifically? A great example is games-strategy/openra, which is very shaky in terms of stability and if you want to play it on LAN, you definitely want more than one version to try out. Another example are fps games like games-fps/urbanterror where a lot of servers still run older versions (and you might even want to play these on LAN). Since you have some experience working on game ebuilds and are clearly invested in seeing games maintain their quality, what do you want to see happen to games on Gentoo? If we can gather a list of things we want to do or fix (from games maintainers, users, and other devs), maybe we can settle on actionable things and find a way forward. Things I think that need to stay the same, although they can be improved: * strict review policies, because I don't think it makes a lot of sense to not communicate (we already had that). We have git, we can communicate quickly and double check each others ebuilds/fixes. Games ebuilds in particular have a lot of pitfalls. * the team should have the freedom to enforce their own set of policies and guidelines to a certain extent * the team should be the go-to guys when it comes to games ebuilds (pretty similar to what we have with other projects already... ofc you can maintain your own python/games package without the python/games herd, but it's really not very good style) Things that need to change * communicate more and be more open to global discussions * be more open to community collaborations (github PRs for example) * be proactive... don't just wait that people contact you * actually process membership applications and extend the team * be more active on the wiki and create useful sites (e.g. I started https://wiki.gentoo.org/wiki/Games) * try to bring more GoG and humble bundle games to the tree * have an official games overlay for packages that really cannot meet our current minimum standards (or other trash/graveyard/WIP things)... the main work/collaboration however should happen in the tree * help improve steam gaming on gentoo, even if it's just documentation * improve official gentoo gaming support channels in general
Re: [gentoo-dev] games.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/22/2015 04:10 AM, hasufell wrote: On 08/22/2015 09:33 AM, Daniel Campbell (zlg) wrote: On 08/21/2015 02:09 PM, James Le Cuirot wrote: On Fri, 21 Aug 2015 12:42:07 -0700 Daniel Campbell (zlg) z...@gentoo.org wrote: Sure, we did drop this, but I don't really see this line of argument actually accomplishing anything productive. Creating a games team that fixes these issues would be productive. Letting others fix them is also productive. Nobody is opposed to having a games project - it just seems like nobody cares enough to actually make it happen. That's ok - we can still get things done. What would be required to revive the games project? One of the reasons I became a dev was to help out the games team, and if it's defunct, I want to see what's necessary to fix it. I'm still a new dev (May 2015), but I wouldn't mind doing some dirty work if it means we can put squabbles like this behind us and get enough devs together to give game ebuilds the attention they deserve. I don't have a lot of free time, but sitting here discussing stuff isn't fixing anything, either... If I can spend what little Gentoo time I have on fixing things, I'd be glad to. At last, some positivity! As I said before, I would like to work on a few games too. I would certainly take up any Java-based ones and I have four of those in mind already. I've dabbled with ebuilds for many other games in the past, some already in the tree and some not, and some from source, some not. The Humble Bundle games are of particular interest to me. I'm obviously bogged with the more boring Java stuff for the foreseeable future though so as much as I'd like to, stepping up to be a lead would be unwise. I, too, have interest in Humble Bundle games since most of the games I have and can test come from them. Do we actually need a team? Games come in all shapes and sizes so I think the assertion that they should be handled like any other application is somewhat valid. Many games are commercial so it's likely that certain games would only be handled by one or two team members anyway. The main thing I've been concerned about in the past is how to handle data. Should it be packaged separately? How do we handle the cdinstall flag these days when there are also multiple online sources like Humble Bundle and GOG? Do we just do whatever seems best for the game in question? I'd be happy to hold such discussions in a distro-wide fashion though. Despite games being just another application, I think they differ simply because they're a *different type* of application. Fonts and icon-sets are similar to games in that they are mostly assets, and they get the separate treatment they deserve. Games are an odd mix of software and assets, so I think they deserve to be considered their own type of software. They're also built in different ways than most typical software is. Games differ in a lot of ways and they _require_ different policies. In some cases this also means more lax policies and in some cases more strict policies. An example is unbundling libraries. While unbundling libraries is often a good idea for regular well-maintained projects, it can often cause various problems for games: * games upstreams often modify 3rd party libraries * games upstreams often use libraries in very fishy ways, so you really need a very specific version * for proprietary games breakage often happens randomly at runtime * proprietary games may also break silently when library XY is bumped in the tree Great points. Games often do rely on their bundled libraries, and that's one of the biggest exceptions to the rule that I see *needs* to apply to games; if bumping a dependent library breaks it, then we at least need an option to make sure the game continues to work. I've seen both opensource games and proprietary games that break when you unbundle libraries. One example is games-action/supertuxkart that was broken by a lot of packagers (including archlinux), because they didn't ask upstream if it was a good idea to unbundle Irrlicht. It wasn't. Another example is games-rpg/baldurs-gate-ee which has some weird graphical glitches when you unbundle libraries. The primary concern of gamers is that the game runs and that they can reasonably install it (see the games-roguelike/nethack bug which was unsolved for 8 years). What happened with that bug? 8 years? That's insane! Because of that, I provide a 'bundled-libs' USE flag for almost all proprietary games I package (e.g. those from GOG). So in case something breaks, the user can still opt-out of all this. Right, that flag is really handy in my experience. If you've worked on Torchlight, Rochard, or Shatter, I'd like to thank you for your work on them. 'bundled-libs' is a lifesaver with those games because they *do* use modified libraries and it's the path of least pain to get them to work.
Re: [gentoo-dev] games.eclass
On Saturday, August 22, 2015, hasufell hasuf...@gentoo.org wrote: Games differ in a lot of ways and they _require_ different policies. In some cases this also means more lax policies and in some cases more strict policies. An example is unbundling libraries. While unbundling libraries is often a good idea for regular well-maintained projects, it can often cause various problems for games: * games upstreams often modify 3rd party libraries * games upstreams often use libraries in very fishy ways, so you really need a very specific version * for proprietary games breakage often happens randomly at runtime * proprietary games may also break silently when library XY is bumped in the tree While I get what you're saying, none of the specific issues you listed are actually unique to games, especially FOSS games. These sorts of issues tend to happen with lots of desktop/multimedia-oriented applications. I do agree that they hit games pretty hard though and games maintainers should have a forum for discussing them. Where I think games tend to exacerbate this issue is that they're often proprietary and non-free which makes detecting these issues harder, and fixing them almost impossible for the library maintainers. Also, they tend to not have equal FOSS substitutes. A proprietary word processor will tend to not have much interest in Gentoo because there are so many decent FOSS alternatives. Since games tend to be more about the content then the engines, they tend to be expensive to write FOSS replacements for, so people tend to use the proprietary ones. And that is why I think we have to be careful about just taking any games issue and leaving it up to the games team. I think they can take the lead on raising these issues, and when nobody else has a solution to their problems they should certainly have a bias for action in solving them on their own. However, when a problem does have competing solutions across the tree or where there is value in consistency we shouldn't just leave it up to the games team to do whatever they want with the games. Do we really want a world where multimedia applications go in /usr/multimedia/bin, toolchain goes in /usr/toolchain/bin, science goes in /usr/science/bin, and so on? All of those have projects, and all of them have unique concerns. That doesn't make all of their concerns unique. -- Rich
