There is a new version of the America's Army game available for Linux. This bug report should cover the needed ebuild changes. http://icculus.org/news/news.php?id=2333 Reproducible: Always Steps to Reproduce: 1. emerge sync 2. emerge americas-army 3. Actual Results: Version 2.2.1 Expected Results: Version 2.3.0
*** Bug 82526 has been marked as a duplicate of this bug. ***
Created attachment 51623 [details] americas-army-230.ebuild
Comment on attachment 51623 [details] americas-army-230.ebuild forgot the header, sorry.
Created attachment 51624 [details] americas-army-230.ebuild This ebuild has the correct headers - sorry about the confusion.
haha i'm sorry guys... i can't believe i didnt change the headers or description... i was so excited about it that it never crossed my mind. -Mark
haha same here - sorry again for that.
I'll get on this as soon as I return from vacation.
I've been working on this, but it totally breaks on amd64 and I'm not sure why. More investigation is needed before I'm adding this to portage... sorry, kids!
hello, I get this error with the ebuild: [ 17:40 itchy americas-army ] ACCEPT_KEYWORDS="~x86" emerge =americas-army-230 Calculating dependencies ...done! >>> emerge (1 of 1) games-fps/americas-army-230 to / >>> md5 src_uri ;-) armyops230-linux.run * The installed game takes about 1.6GB of space when installed and 2.4GB of space in /var/tmp to build! >>> Unpacking source... >>> Unpacking armyops230-linux.run to /var/tmp/portage/americas-army-230/work * I'm sorry, but I was unable to support the Makeself file. * The version I detected was ''. * Please file a bug about the file armyops230-linux.run at * http://bugs.gentoo.org/ so that support can be added. any ideas?
This was added to portage. This bug is only to have it added to portage. If you think there is another bug, please file it. It appears that something is wonky with your eutils.eclass on your machine. Have you made sure you don't have a copy of this eclass in an overlay somewhere? Try also deleting and redownloading the distfile, because it WORKSFORME on several machines.
Version 230 WORKSFORME on x86; any reason this ebuild hasn't been marked stable for the x86 platform yet?
This has nothing to do with putting this into portage and bugs isn't a discussion forum. It hasn't gone to stable because there were still some issues with the game that I am trying to address, specifically some Punkbuster issues.
As the original submitter of this bug, let me clarify what "upgrade americas-army to version 2.3.0" means: 1) submit new ebuild 2) debug ebuild for this version so that it actually works 3) test 4) mark ebuild stable For x86, steps 1 through 3 are complete. I don't see any issues with Punkbuster or anything else for that matter. If there is an issue (on x86) please point me to the bug report and I will glady help resolve it (I have searched bugzilla and see nothing open). Otherwise americas-army-230 should be marked stable for x86.
...and as the maintainer, I am the one that decides when the game goes to stable, not you. If you uncomfortable with that, I'm sorry, but I am the one that has to work the bugs. While there might not be a bug number for the Punkbuster issue, it is prevalent for many people. That being said, I'll mark the ebuild stable when I'm ready to do so and not before.
You said it yourself "If you think there is another bug, please file it". I really do want to *help* you... And as far as the open/closed state of this bug, it should remain OPEN until the "Expected Results" are achieved; at this point that is not a reality.
Stop reopening this bug.
How about "stop closing bugs that have NOT been resolved".
comment #10 explained it to you. You can feel free to unmask locally. man portage and read about package.keywords if you like.
Comment #13 & the bug report itself explains why comment #10 is wrong. I know how to unmask locally, its how I tested the submitted ebuild. If there is some mysterious "Punkbuster issue" on x86 that is "prevalent for many people" then Chris should take his own advice and file a bug report. Marking a bug RESOLVED FIXED when the Expected Results have not been accomplished is just plain stupid. Chis et.al. would not have to be "the one that has to work the bugs" if the devs would follow the process defined by the bugzilla tool and the Gentoo Developer Docs. Gentoo isn't anyone's personal pet project, its a community effort. I highly suspect that the punkbuster issue only exists on amd64 only (if I'm wrong FILE A BUG REPORT AND PROVE ME WRONG). There is no process in the Gentoo Dev Docs that states that an ebuild must be stable on all platforms to before being marked stable on a particular platform.
Yawn... I just made a procmail filter for this bug to /dev/null it... This has been resolved for a long time and I'm sick of arguing over it. If you don't think this was resolved to your satisfaction, then don't file version bump bugs. I follow the development of America's Army and really have zero need for them. I also have zero need to file bugs to myself, and since I am the maintainer of americas-army under Gentoo for both x86 and amd64, that's exactly what I would be doing. I have no desire to explain myself to you, nor am I required to do so. It is pretty simple here, the maintainer has the final say on the package unless there is a vital security bug or tree breakage. Not to mention that nowhere in your "Expected Results" did I see anything about marking this package stable. You added that on sometime later and it was not only unrealistic, but pointless. Personally, I couldn't care if you think comment #10 is wrong or not, as the games team are all in agreement here that I am correct.
"I follow the development of America's Army and really have zero need for {file version bump bugs}. I also have zero need to file bugs to myself, and since I am the maintainer of americas-army under Gentoo for both x86 and amd64, that's exactly what I would be doing. " Wow, once again your self importance is amazing. Did it ever occur to you that there are other people involved with Gentoo (users, devs, etc.) that might want to keep track of such things? Did it ever occur to you that the bug process exists not only to report bugs to the people who maintain the packages but also to document what the maintainer does SO OTHERS CAN CATCH THEIR MISTAKES. Or are you assuming that you don't make mistakes? "I have no desire to explain myself to you, nor am I required to do so." Since you are in a leadership role in Gentoo (Lead Integration Engineer I believe), then you are in fact in a position to explain yourself, especially in matters involving the bug resolution policy. If you can't take the heat... "It is pretty simple here, the maintainer has the final say on the package unless there is a vital security bug or tree breakage." That doesn't give you Napoleon-like powers; there is this thing called peer review... "Not to mention that nowhere in your "Expected Results" did I see anything about marking this package stable. You added that on sometime later and it was not only unrealistic, but pointless." Nowhere in my "Steps to Reproduce" did I mention unmasking packages! Therefor its plainly obvious that the package must be marked stable in order for the "Steps to Reproduce" to cause the "Expected Results". You do understand how package unmasking works, correct? And how is expecting a package to be marked stable "unrealistic". Your arguments on this point are becoming more and more ludicrous! "Personally, I couldn't care if you think comment #10 is wrong or not, as the games team are all in agreement here that I am correct." Then frankly you *and* the games team have a few things to learn about engineering, especially systems engineering and quality. It seems that anytime I (or anyone else) question you, Chris, the discussion degrades into a flame war. Learn how to take criticism, and stop taking things personally. You'll be a better engineer for it. My only goal with Gentoo is to help make it the highest quality product possible, not to make you or anyone else look bad.
Wow guys... this is sad.. VERY sad. I cannot believe you still haven't marked this stable yet. Why? All the bugs have been resolved. I have never seen any reports of any problems for AGES. These problems weren't even AMERICAS ARMY problems -- they were punkbuster. My solution is to release it ANYWAY and let Punkbuster weed things out. At least people could still play on NON-Punkbuster servers if there WERE problems. Go ahead, install version 2.2.1. Tell me how many servers are available. 0. Thank you. Therefore, 2.2.1 is worthless as this is a MULTIPLAYER ONLY game. IF for some odd reason you find this to still be UNSTABLE and BUGGY, the problem is GENTOO or PORTAGE. Prove me wrong, then go ahead and stop on #icculus.org on Freenode and b*tch at Icculus for releasing a broken 2.3 for Linux. This won't happen though, because the problem is NOT the game. It WAS the optional Anti-cheat program, which has been resolved, and is NOT the Army's fault. This game has been 100% playable since the say it was released, save for about 3 days setback with the PB probs. Go find something else to "Maintain" because you apparently cannot handle a simple game. BINARY games should never be marked UNSTABLE. Beta releases and patches are NOT (usually) public. If they were, it would probably be open source. THEN I could finally understand the need for an UNSTABLE game. Note: I speak for x86. This game was not written for 64bit. I can understand the UNSTABLE there. I have put at LEAST 100 hours on since 2.3's release with no problems at all. Reproducible: Always on x86 Steps to Reproduce: 1. emerge sync 2. emerge americas-army 3. Actual Results: Version 2.2.1 Expected Results: Version 2.3.0 marked stable; Chris Gianelloni removed from MAINTAINER of x86 America's Army because apparently he relies on rumors rather than real experience with the game.
Mark -- perhaps you'd be able to help better if you familiarised yourself with the keywording policy beforehand.
For future reference, the 'QA policy' for keywords is detailed here: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap4 Basically use package.mask if the target software is flakey. Use ~arch if the ebuild itself is flakey. Chris: Thanks for ponying up and marking americas-army-230 stable on x86.
I thought I would point out this excerpt from the Ebuild Policy that Nathan was so kind to post a URL to, and apparently didn't read in its entirety: "It is up to the maintainer of the package to deem which versions are stable or if development versions should be in package.mask or left in ~arch." This means that when Chris deems the ebuild stable, then it is stable. Not before. Please keep this in mind next time you submit an ebuild. Chris handles alot more work in Gentoo than just maintaining the America's Army game (like Release Engineering), so he can't always fix bugs as fast as some users would like them fixed. The comments in this bug from both Nathan and Mark show a complete lack of respect for the work we as developers do. As a community-based project, we are not here to be stepped all over and told which ebuilds to mark stable. We provide many mechanisms within portage by which a user may mark an ebuild stable locally if they do not wish to wait for the maintainer to mark it stable in the tree. I therefore reccommend to both Nathan and Mark, that next time this situation arises, that they work WITH the maintainer of the package to get the issues resolved in the bug so the package can be moved into stable more efficiently than it would be by arguing with the maintainer. That way, everyone is happy, and we don't create uneccessary flames over such trivial matters.
Joshua, Thank you for the response. Although I take exception to the "complete lack of respect" comment, the level-headed tone of your comment is refreshing. I do, in fact, respect the work that Gentoo volanteers do; if I didn't I wouldn't be filing bug reports and helping out occasionally in the forums. I also understand that Chris is the person empowered to mark the ebuilds stable, and I am also aware that Chris has more important responsibilities than this particular ebuild. However, none of that excuses the lack of professionalism in this arguement from some of the developers, and no matter what a developer's responsibilities are his work (like mine, yours, and everyone else's) is subject to peer review and critiques. If you can't handle criticism and critiques in a public fashion, you shouldn't be wasting your time on an open source project. So I ask you, where is the disrespect in comments #11, #13, #15, #19, etc? If any of those come across as disrespectful, then I apologize; disrespect was not my intent. I asked simple questions to try and get this bug resolved and received hostility in return (#14, #16, #18, etc). If I mistook succinctness for hostility in your comments, then I do apologize for that. You should also frame this discussion with the comments Chris made in the forums[1]. Back in February I was helping other users emerge the test ebuild and ended with the comment "Be sure to let the developers know if you have any problems: http://bugs.gentoo.org/show_bug.cgi?id=82516". Chris responded with "Never comment in an ebuild request bug about problems. Instead, you should file a new bug, lest you anger the developers that keep this stuff updated in portage and they decide to reach out and smite thee." Sadly its not uncommon for developers to perceive themselves as quasi-rock-star-omniscient-beings, but in reality we are just poor slobs just like everyone else (no matter how great our technical prowess and/or contributions are). So if you are going to preach about users respecting developers and their work, then you should also expect developers to respect users and *their* work as well. Finally, as I stated in my response to Mike's email, I've moved on. I harbor no ill-will or bad feelings of any kind to Chris, or anyone else. Let's all just take a step back, learn from *all* of our mistakes, and move on to the next interesting problem to solve. I will make a 'pledge' of sorts to try and be more sensitive to the developers' feelings in the future. Its obvious that some mistook my critiques and debate as personal attacks, and I will step more gingerly in the future. I will never back down from a debate if prevailing evidence shows I'm right however, so I look forward to more heated discussions with all of you in the future. Lets just *all* try to me more cordial next time! :) [1] http://forums.gentoo.org/viewtopic-t-294259-highlight-.html
It has been my observance that there is often a varied definition of what one considers criticism. What may be criticism to one may be disrepect to another. It depends heavily on one's particular worldview. Comment #11 Seems fine to me. The tone comes across as mildly inquisitive, and not much more. Things, however, change after that comment. The tone of Comment #13 comes across to me as a bit more rancid, salted lightly with some sarcasm, and a dash of belligerance on the side. Simply because the ebuild satisfies Steps 1 through 3 on your system does not automatically qualify it for promotion to Step 4. As I myself have learned when working on the mips port, I sometimes create a patch to fix something mips-related, test it on several of my SGI systems, and discovering it works, post it to the tree under unstable or mask. One of the other mips developers then comes along, and discovers that what I created has a small bug in it that did not turn up in my test. Thus, just because something works flawlessly for me does not imply it will work for everyone else. Comment #15 I cannot classify easily, as I cannot tell via Bugzilla how many times it was "resolved" and "reopened". However, Developers often will "resolve" a bug temporarily, like when using "NEEDINFO" or "TESTREQUEST" or even when putting te bug on hold for awhile until they can resolve a particular issue (or find time to resolve it). Comment #19 is somewhat inaccurate in it's statement. Chris is right in Comment #10 that the bug was specific to having the ebuild added to portage. This is a traditional thing, and prior history exists within Bugzilla itself. Typically, a separate bug is filed for stable requests, unless otherwise specified in the Expected Results of the bug. You Expected Results as I see it here does not indicate that the bug's final outcome result in AA-2.3.0 becoming stable. While the Expected Results are vague at best, they imply more addition of the ebuild to the tree, not marking of the ebuild stable. If this was your intention when filing this bug, then next time actually state in the Expected Results section that the bug is finished when the ebuild is marked stable. However, even when this is the case, it is not uncommon for the bug to still be resolved for "TESTREQUEST". Perhaps the most abrasive of comments came not from you, Nathan, but more so from Mark in Comment #22. Perhaps if he were to read the Ebuild Policy, he might be more thoughtful in his choice of words when discussing this topic again. As far as the forums go, Chris' statement seems rather harmless. While his use of bold on the opening word implies a bit of seriousness to the statement, the use of the phrase "smite thee" gives the statement a more humourous/sarcastic nature, which balances out any intended or accidental seriousness, thus rendering the statement more or less neutral. He is also correct in that statement -- problems with a specific ebuild should be filed under a new bug. It can sometimes seem wasteful doing this, but it's purpose is to maintain a separate bug for each unique problem or oddity that occurs. Thus, a bug for adding an ebuild to portage is not the correct location to post problems with that ebuild after it has been added to portage. Sometimes, however, this policy is overlooked, especially if the ebuild has been in the tree for a very small amount of time (>1-4 days maybe?). Ultimately, though, while debate here was rather heated at times, hopefully this gives all involved parties a chance to analyze this and hope this issue doesn't arise again.
Ah, well I was not aware of the 'file another bug to mark an ebuild stable' tradition. And I cannot find any hint of that in the docs either (if you can, please point me to it; I have read all of the docs by the way, piece-meal, over time). As far as Comment #15 is concerned, I don't think this bug was marked RESOLVED because of a "NEEDINFO" or "TESTREQUEST" type situation, those things were never mentioned. And still I don't see how anyone can defend a position that says 1) this can't be marked stable because of a specific bug, yet 2) we're not actually going to open a report for that bug, and at the same time 3) if any bugs are found, you should open a bug report. Not to mention that I made a sincere and polite offer to help resolve the bug! And I don't condone Mark's comments, so please don't associate them with me. But Mark is obviously somebody who is willing to contribute so I think he should be extended the same 'forgiveness' as anyone else who may have crossed the line in this discussion. I come from a more traditional engineering background where accountability, traceability, and the like are paramount. The process is well defined, and every change gets documented. So for example in the Gentoo world, every CVS commit would point to a Bugzilla number, and the Bugzilla number would more fully describe the how and why of the change. There could be multiple CVS commits under a single bug report of course, but the CVS tool would not allow a check-in without first associating it with a valid bug report. The point is not to load ourselves down with pointless paper work or to provide a quick an easy way for somebody to point the finger at a developer when something gets hosed up. The point is provide enough high quality artifacts that we know exactly what the system is, does, and how it came to be. Remember that the creation of artifacts is what an engineer does, and outside auditors, customers, other developers, and other stake-holders have a need to know this information. So now that you know where I'm coming from, maybe my previous comments will make a little more sense and seem to have less of "a dash of belligerance (sic) on the side". ;) (Comment #13 was, by the way, intended purely to clarify what I meant in the original bug report; no more, no less.) I also see an opportunity to turn a negative into a positive here. I know from my work experience that a stream-lined systems engineering approach creates better, more reliable software in the long run. I work for a very large company, and my department is the *only* dept to have perfect track record of being on time an on or under budget. Combine a streamlined with the ultimate peer review system (F/OSS) and I think you might have something truly great. If you're interested, maybe we should work together on a GLEP. And again, Josh, thanks for the level-headed response. While I certainly don't agree with everything thing you say, a more civil discussion is exactly what everyone needed!
We fix things *before* they make it onto bugzilla if at all possible. As for peer review, it's something that's done by peers -- in this case, that would be people who are familiar with the ebuild policy.
After reading all that was said so far, I too am sorry for being rude and obnoxious. I just found it to be completely unacceptable that this was still marked unstable. The game has been released since Feb 17th, which really bothered me. I also follow the America's Army development. I am an OP in the #aa-linux channel on the America's Army IRC network. I was one of three people who established that channel and we help people EVERY day. We are also the first to know about ANYTHING related to the game regarding Linux thanks to our tight ties to the AA Community Leaders. (We actually called up SCI once to dispell a rumor.) I'm also soon to be an America's Army beta tester, according to a friend of mine who is one. I have been fully aware of any bugs regarding this game and Linux (x86), and I thought it to be quite unacceptable that a game this popular was still deemed unstable after this amount of time.
stop kicking a dead horse the game is stable, everyone is happy, lets all hold hands and collectively shut up
