Examine individual changes

'<div class="mw-parser-output"><table class="table table-condensed" style="width: 30em; font-size: 95%; border: 1px solid #ddd; background-color: #f9f9f9; color: black; margin-bottom: 0.5em; margin-left: 1em; padding: 0.2em; float: right; clear: right; text-align:left;"> <tbody><tr> <th style="text-align: center; background-color:#3E355A; color: white;" colspan="2"><big>Games Project</big> </th></tr> <tr valign="top"> <th>Description </th> <td style="text-align: justify;">The Games Project manages the game categories (dev-games, games-*) in Portage </td></tr> <tr> <th><span title="Mails to member(s) listed below.">Project email</span> </th> <td><a rel="nofollow" class="external text" href="mailto:games@gentoo.org">games@gentoo.org</a> </td></tr> <tr> <th><span title="The link opens a webchat to this project&#39;s Freenode IRC channel.">IRC channel</span> </th> <td><a rel="nofollow" class="external text" href="https://webchat.freenode.net/?channels=gentoo-games">#gentoo-games</a> </td></tr> <tr valign="top"> <th>Lead(s) </th> <td><ul><li><a href="/wiki/User:Chewi" title="User:Chewi">James Le Cuirot</a> (chewi)<br /><i>Lead ( Team Lead )</i></li></ul> <br />Last elected: 2019/05/12 </td></tr> <tr valign="top"> <th>Member(s) </th> <td><ul><li><a href="/wiki/User:ConiKost" title="User:ConiKost">Conrad Kostecki</a> (ConiKost)<br /><i>Member ( general )</i></li><li><a href="/wiki/User:Soap" title="User:Soap">David Seifert</a> (soap)<br /><i>Member ( general )</i></li><li><a href="/wiki/User:Steils" title="User:Steils">Stefan Strogin</a> (steils)<br /><i>Member ( general )</i></li><li><a href="/wiki/User:Vapier" title="User:Vapier">Mike Frysinger</a> (vapier)<br /><i>Member ( general )</i></li></ul> </td></tr> <tr valign="top"> <th>Subproject(s)<br /><small style="font-weight: normal;">(and inherited member(s))</small> </th> <td>(none) </td></tr> <tr> <th>Parent Project </th> <td><a href="/wiki/Project:Gentoo" title="Project:Gentoo">Gentoo</a> </td></tr> <tr> <td colspan="2" style="border-top: 1px solid #ddd; font-size: smaller; text-align: center;"><a href="/wiki/Project:Gentoo" title="Project:Gentoo">Project listing</a> </td></tr></tbody></table> <p>The Gentoo Games Project manages some of the games in the Portage tree. We're the guys that put the fun into Gentoo. We also manage a few utilities that are used heavily in many games, such as the SDL* libraries. Please note that we don't manage heavily integrated games packages such as 'gnome-games' or 'kdegames'. </p> <div id="toc" class="toc"><div class="toctitle" lang="en" dir="ltr"><h2>Contents</h2></div> <ul> <li class="toclevel-1 tocsection-1"><a href="#Goals"><span class="tocnumber">1</span> <span class="toctext">Goals</span></a></li> <li class="toclevel-1 tocsection-2"><a href="#Gentoo_Games_bugs_FAQ"><span class="tocnumber">2</span> <span class="toctext">Gentoo Games bugs FAQ</span></a> <ul> <li class="toclevel-2 tocsection-3"><a href="#Should_I_attach_an_ebuild_to_a_version_bump_request.3F"><span class="tocnumber">2.1</span> <span class="toctext">Should I attach an ebuild to a version bump request?</span></a></li> <li class="toclevel-2 tocsection-4"><a href="#What_information_do_I_need_to_post_with_my_bug_report.3F"><span class="tocnumber">2.2</span> <span class="toctext">What information do I need to post with my bug report?</span></a></li> <li class="toclevel-2 tocsection-5"><a href="#When_should_I_open_a_new_bug_rather_than_comment_on_an_old_one.3F"><span class="tocnumber">2.3</span> <span class="toctext">When should I open a new bug rather than comment on an old one?</span></a></li> <li class="toclevel-2 tocsection-6"><a href="#This_download_is_too_big._Can_we_make_it_download_the_patches.3F"><span class="tocnumber">2.4</span> <span class="toctext">This download is too big. Can we make it download the patches?</span></a></li> </ul> </li> <li class="toclevel-1 tocsection-7"><a href="#Want_to_help.3F"><span class="tocnumber">3</span> <span class="toctext">Want to help?</span></a></li> </ul> </div> <h2><span class="mw-headline" id="Goals">Goals</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Project:Games&amp;action=edit&amp;section=1" title="Edit section: Goals">edit</a><span class="mw-editsection-bracket">]</span></span></h2> <p>The games project aims to turn Gentoo into the premiere Linux gaming platform. We strive to have the best compatibility not only for free games, but also for commercial titles. </p> <h2><span class="mw-headline" id="Gentoo_Games_bugs_FAQ">Gentoo Games bugs FAQ</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Project:Games&amp;action=edit&amp;section=2" title="Edit section: Gentoo Games bugs FAQ">edit</a><span class="mw-editsection-bracket">]</span></span></h2> <h3><span id="Should_I_attach_an_ebuild_to_a_version_bump_request?"></span><span class="mw-headline" id="Should_I_attach_an_ebuild_to_a_version_bump_request.3F">Should I attach an ebuild to a version bump request?</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Project:Games&amp;action=edit&amp;section=3" title="Edit section: Should I attach an ebuild to a version bump request?">edit</a><span class="mw-editsection-bracket">]</span></span></h3> <p>Usually, no. If simply copying the ebuild to the new name and creating a new digest works for the upgrade, then please mention that in the bug. It will save us time from looking at an ebuild and trying to determine what has changed. If there has been a few minor changes, then a diff between the two ebuilds using <span style="font-family: monospace; font-size: 95%; font-weight: bold;" class="tripleclick-separator">diff -u old.ebuild new.ebuild</span> is perfect. If there has been major changes between versions, then an ebuild is appropriate and appreciated. </p> <h3><span id="What_information_do_I_need_to_post_with_my_bug_report?"></span><span class="mw-headline" id="What_information_do_I_need_to_post_with_my_bug_report.3F">What information do I need to post with my bug report?</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Project:Games&amp;action=edit&amp;section=4" title="Edit section: What information do I need to post with my bug report?">edit</a><span class="mw-editsection-bracket">]</span></span></h3> <p>As in any bug report, you should <b>always</b> post the output of <span style="font-family: monospace; font-size: 95%; font-weight: bold;" class="tripleclick-separator">emerge --info</span> into every bug report that you submit (see <a href="/wiki/Bugzilla/Bug_report_guide" title="Bugzilla/Bug report guide">Bug report guide</a>). If you think there are other pertinent pieces of information that could possibly help us in tracking down the bug, then be sure to include that information, too. One example is the opengl implementation that you are using when filing a bug against an opengl-based game. Anything you can provide us could possibly be the one piece of information that we need to accurately and quickly resolve the bug. This could include information such as your method of installation in a CD-based install, or the situation in which the bug occurs. </p> <h3><span id="When_should_I_open_a_new_bug_rather_than_comment_on_an_old_one?"></span><span class="mw-headline" id="When_should_I_open_a_new_bug_rather_than_comment_on_an_old_one.3F">When should I open a new bug rather than comment on an old one?</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Project:Games&amp;action=edit&amp;section=5" title="Edit section: When should I open a new bug rather than comment on an old one?">edit</a><span class="mw-editsection-bracket">]</span></span></h3> <p>You should always open a new bug unless your problem is producing the exact same error, you have tried the workarounds or fixes in the ebuild, and your error is occurring on a same-versioned ebuild. Do not make comments on an already resolved bug if you are seeing a similar problem in a newer version of a game, as this makes it hard to track individual problems. You should also never add a comment about a new version of to an existing bug about the same package. </p> <h3><span id="This_download_is_too_big._Can_we_make_it_download_the_patches?"></span><span class="mw-headline" id="This_download_is_too_big._Can_we_make_it_download_the_patches.3F">This download is too big. Can we make it download the patches?</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Project:Games&amp;action=edit&amp;section=6" title="Edit section: This download is too big. Can we make it download the patches?">edit</a><span class="mw-editsection-bracket">]</span></span></h3> <p>No. In general, ebuilds are designed to be used as if one is not upgrading from a previous version. As soon as we start having people download version $foo and patch $bar, people complain that there is a $foo-$bar distfile. We can't please both camps, so we simply do not offer incremental downloads. While this can be a pain for users on dial-up, it makes things easier on us. </p> <h2><span id="Want_to_help?"></span><span class="mw-headline" id="Want_to_help.3F">Want to help?</span><span class="mw-editsection"><span class="mw-editsection-bracket">[</span><a href="/index.php?title=Project:Games&amp;action=edit&amp;section=7" title="Edit section: Want to help?">edit</a><span class="mw-editsection-bracket">]</span></span></h2> <p>If you want to get involved with improving Gentoo's gaming experience, we'd like to hear from you! The main thing you'll want to do is be active on <a rel="nofollow" class="external text" href="http://bugs.gentoo.org">Gentoo's Bugzilla</a> . A good start is to provide patches or ebuilds to bug reports that have already been filed by other users. Simply adding new bug reports is helpful in getting problems resolved in the long term, but does not help get them resolved in the near term. Also, please join games project members in <span style="font-family: monospace; font-size: 95%;"><a rel="nofollow" class="external text" href="irc://irc.gentoo.org/gentoo-games">#gentoo-games</a></span> on Freenode. </p><p>There is also a <a href="/wiki/Project:Games/Ebuild_howto" title="Project:Games/Ebuild howto">HOWTO</a> for writing proper games ebuilds. You will definitely want to read it if you plan on contributing as it is the standard by which games ebuilds are written. This information is in addition to the standard ebuild policies and procedures. </p> <hr /><p><small>This page is based on a document formerly found on our main website <a rel="nofollow" class="external text" href="https://www.gentoo.org/">gentoo.org</a>. <br />The following people contributed to the original document: <b>Chris Gianelloni</b><br /><span style="color: #555;">They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do <b>not</b> add yourself here; your contributions are recorded on each article's associated history page.</span></small> </p> <!-- NewPP limit report Cached time: 20200109213501 Cache expiry: 86400 Dynamic content: false [SMW] In‐text annotation parser time: 0.006 seconds CPU time usage: 0.102 seconds Real time usage: 0.130 seconds Preprocessor visited node count: 377/1000000 Preprocessor generated node count: 1425/1000000 Post‐expand include size: 4499/2097152 bytes Template argument size: 830/2097152 bytes Highest expansion depth: 7/40 Expensive parser function count: 0/100 Unstrip recursion depth: 0/20 Unstrip post‐expand size: 0/5000000 bytes --> <!-- Transclusion expansion time report (%,ms,calls,template) 100.00% 100.025 1 -total 96.61% 96.630 1 Template:Project 40.90% 40.912 5 Template:ProjectMemberLine 17.37% 17.370 5 Template:ProjectMemberLineNickname 9.80% 9.804 4 Template:Project_Member 0.95% 0.952 2 Template:C 0.93% 0.928 1 Template:IRC 0.85% 0.855 1 Template:Migrated --> </div>'