Development builds (1.3 branch) of Battle for Wesnoth (games-strategy/wesnoth) are missing in "~86". Only stable builds are there (1.2 branch). I think that people running "~x86" should be able to install development builds, while "x86" should stay on stable builds. It has been a while that wesnoth-1.3.2 is released. I renamed wesnoth-1.2.4-ebuild to wesnoth-1.3.2-ebuild, and was able to run it without problems so far. Reproducible: Always Steps to Reproduce:
We won't be adding the development versions to portage.
(In reply to comment #1) > We won't be adding the development versions to portage. > What is the reason for, that? I think that each numbered release should be added, at least as masked.
Because the development stuff doesn't really belong in portage and we don't want to support it. You're welcome to use it locally.
Too bad it has been decided to exclude the 1.3 branch from portage. It really is a nice progress and from 1.2 and certainly playable. Perhaps someone should update the info in the wiki though about this new policy since there its said dev versions are kept in the ebuild tree. http://www.wesnoth.org/wiki/WesnothBinariesLinux#Gentoo Also, I'm scratching my head trying to fully understand the reason. There are literally hundreds of developer branch ebuilds of other software in the ebuild tree. In any case, on the above link is also findable an svn version of Wesnoth for those like me who would like to play the up to date version :)
All you need to do is to rename your ebuild to wesnoth-1.3.x.ebuild and you can compile and play it without problems. I can't see a reason why it is not in portage (at least masked).
see comment #1 and #3
(In reply to comment #6) > see comment #1 and #3 > Still don't agree with the "dev builds don't belong to portage". Is it written in stone? Here are just a few examples of dev-builds in portage, just on top of my head: vanilla-sources - full of rc releases mplayer - snapshots, not even releases dokuwiki - snapshots ... and wesnoth 1.3.x builds are releases, not some snapshots, rc, or beta Also see comments #4 and #5
Not happening. Please stop reopening this bug.
(In reply to comment #8) > Not happening. Please stop reopening this bug. > You didn't convince me that it is that hard to do "mv wesnoth-1.2.x.ebuild wesnoth-1.3.4.ebuild".
I've already asked you once to not reopen the bug. Stop doing that. This is WONTFIX because it won't be done. That's the end. You're welcome to run those versions of wesnoth locally.
Indeed, give it up Marko. The days when Gentoo devs actually gave a *uck about Gentoo users has long since gone. 3 months ago I myself added a request to include SMplayer, the best frontend for mplayer I've seen (vastly better then the Gmplayer that is available today). Even though lots of people concur and new ebuilds are continuously added to bugzilla no dev can be bothered to move a finger to include it in the tree. Best option left is to simply switch to another distribution where devs are actually assisting in instead of blocking user requests. Personally I'm looking towards Gobolinux myself, a lot less polished then Gentoo, but where efforts are made into making tools to automatically create new recipes (=ebuilds) so user them selves can easily add new packages & updates instead of having to wait for some dev with bad attitude to wake up and realize why they where given commit access in the first place.
*** Bug 183756 has been marked as a duplicate of this bug. ***
> Indeed, give it up Marko. The days when Gentoo devs actually gave a *uck about > Gentoo users has long since gone. Actually I will not give up. I remember the times when I switched to gentoo, and that I was pleasantly surprised that whenever wesnoth released new version, it was in portage. When I see it updated by portage, I would then go to the www.wesnoth.org to download Mac version. Gentoo was the edge, now it is behind the edge. Anyways, back to the topic. Mr Bones, this is a bug, and besides beeing a bug it is a REGRESSION. Development builds of wesnoth had their ebuilds in portage tree. Just take a look at Changelog. It is full of 1.1.x versions. All 1.1.x versions were development versions, in the same way 1.3.x versions are now. And asking me to stop reopening this bug will not change the fact that this is regression bug. I would understand that you refuse to add new version if that would require some work from your side (I would probably help to fix it if possible), but if fixing a serious regression bug is just a one ebuild file rename away, I can't accept WONTFIX as a resolution. Sorry if it reopening of this bug is hurting your statistics or whatever.
The disrespect you're showing to Gentoo developers who are donating their time for your enjoyment is quite rude. You've already been asked to stop opening this bug. Now stop.
> The disrespect you're showing to Gentoo developers who are donating their time > for your enjoyment is quite rude. Respect to you, man. I would show respect even more if you fixed it (need 30sec of your time) instead of replaying here and changing status to WONTFIX (>30sec of time). > You've already been asked to stop opening this bug. Now stop. The fact that you asked me to stop reopening instead of answering the question will not help. In case you forgot: How come that 1.1.x series of wesnoth was part of portage tree and 1.3.x is not? Both series are development builds. Before development builds were in portage, now they are not. Something that worked before, and doesn't work now is a regression bug, and regressions are always considered most important bugs.
Hi Marko, Mr. Bones alerted me to the fact that you are reopening a big on an issue that he has since deemed handled. Please understand that our developers are very busy, and do work without salary, and that their time is dedicated. Mr_Bones feels this game,while gaining popularity, is still in a development mindset and therefore would live for the time being, in package.mask. He deems this additional overhead unnecessary when other parts of Gentoo demand more of his time. Please understand this and realize that when the time comes, he will deal with your request appropriately. As for the constant reopening of this bug, as a Gentoo Bugzilla Administrator, we find that is a nuisance and will disable accounts for a temporary amount of time if the unruly behavior persists. Thanks for understanding. Regards, Jeff
> Mr_Bones feels this game,while gaining popularity, is still in a development mindset and therefore would live for the time being, in package.mask. Some corrections and info since you seem not 100% updated. * This game is not in package.mask at all. * The two latest stable (1.2.4 & ~1.2.5) are in the tree. * The 1.3.x developer releases is completely left out even though creating an ebuild for it is trivial in nature (cp). * Historically developer releases (eg 1.1.x) have been in the tree (and is even advertised in the Wesnoth Wiki) * Developer RELEASES (as opposed to SVN) are generally quite stable and working just fine. I would also like to add my personal opinion that everything I have so far read from Mr Bones tells me he has no knowledge what so ever about the quality status of the developer releases of wesnoth. I assume he just sees "developer" and thinks it will crash or have other huge problems which is not the case. Personally I dont care since I already did what I'm found myself doing more and more, just downloading the source tarballs and compiling "manually". A lot less enervating then trying to convince a DEV to add a package to the tree.
You can also create a local overlay to emerge this game. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1#doc_chap6_sect2 If the ebuild run without changes, you will not need to waste much of your time doing the installation manually. Just put it in your overlay with the correct name and emerge. That's all.
Hi Jeff, ok, I'll stop reopening this bug. My fault for not being so clear. Stefan Huszics summarized it much better in comment #17. Each time I reopened the bug, I provided new arguments, to which the only answer was "stop reopening". That's why I keeped reopening in hope that someone will at least read it. Also, thanx for comment #18, I created my overlay and will stop asking for ebuild.
Re #18 Manually creating the correct folders for an overlay takes roughly the same time as manually typing configure | make | make install . If people with commit access cant be bothered to keep packages updated centrally there is little advantage in a user fixing it locally since it in any case wont help other users. Thus you might as well do it the generic Linux way instead of the specifically Gentoo way. *shrug*
Sorry to tell you, but what is linked in our official wiki is *not* the official build. It is a build created by a fellow friend of mine who made sure that these wesnoth-dev builds can not interfere with the stable version. It is a complete and existing overlay, you can simply use it. It even includes some slight modifications due to different versions of some tools now being required. What was listed in there for quite some time was only valid for 1.1.something onwards. To be more precise: The gentoo builds were not in the official tree until we (the Wesnoth team) did reach beta state. So all the smaller versions like 1.1.1 were not in. I did just update our wiki to refelect the current state again. Don't expect the -dev versions to get into the official tree until we reach beta state (this will take quite some more month). This is some general gentoo policy and just the way it is...
