A new release is available.
yes please bum currently version in portage is broken
Created attachment 266225 [details] New ebuild for 8.83.5.1
(In reply to comment #2) > Created attachment 266225 [details] > New ebuild for 8.83.5.1 In the future, please don't attach an entire ebuild that only changes one character to bugs. If want to attach something, the most useful thing for developers is a unified diff between the ebuild versions; however, in this case it's almost easier just to note the single change in a comment.
Are you kidding me? It uses one block in the file system either way, but this way adding it to the repository is less work. And, Captain Hindsight, why didn't you create the bumped ebuild yourself ten days ago?
Hi Florian, thanks for your work and your good intentions. (In reply to comment #4) > Are you kidding me? no - he is dead serious. > It uses one block in the file system either way, but this > way adding it to the repository is less work. its not about filesystem blocks. and its not easier to add, since the work of adding an ebuild is much more complicated than you seem to presume. we dont just blindly take ebuilds from bugzilla and stuff them into the gentoo portage tree. it is important to the developer doing the work and for gentoo as a whole that we know whats going on. so instead of just putting the ebuild in the tree the developer would be required to do the diff - thats where it is much better for you to have explained what you have changed (either by a diff or via a comment -- depending on the size of the changes). In this case it would have been easier for all, to simply state what changed (i presume, since i didnt do the diff). you can easily imagine a situation, where your change requires feedback from multiple people. in such a situation it becomes an obstacle for everybody involved to have to create the diff before being able to know what is being talked about. > And, Captain Hindsight, why didn't you create the bumped ebuild yourself ten > days ago? This comment does not serve your purpose of getting this fixed fast. to you the issue may seem trivial -- it probably is. Nevertheless, Tim's contribution to this bug (your education) is valueable too. At the same time i want to acknowledge that it is frustrating, that minor issues keep taking a long time to get fixed. And it is not good enough. But there is not much we can do about it, except urge people to join in and become developers. That is a pretty steep investment - so many dont, which is fine as well. As long as the situation is as it currently transpires the only thing that will get your proposed fix committed is playing by the rules. I hope you can see the value of unified diffs for ebuild changes and will provide those in the future. I'll try to see what I can do about this bug later today, when i get access to my dev machine. Anybody else is of course free to work on this before tonight. Thanks kind regards Thilo
(In reply to comment #4) > Are you kidding me? It uses one block in the file system either way, but this > way adding it to the repository is less work. > > And, Captain Hindsight, why didn't you create the bumped ebuild yourself ten > days ago? Wow, I'm sorry if my comment came off that way to you. As Thilo said, I was just trying to educate you in what developers find most helpful in version bump bugs. Also just to be clear, I didn't bump the package myself in the beginning since I'm not an official maintainer for the package so generally I wait awhile to let the official maintainers handle the task before bumping the ebuild myself if no one shows up. Therefore, I'll probably do this myself in a day or two unless Thilo commits the bump like he said he might.
http://intellinuxwireless.org appears to be down :-\
Created attachment 266339 [details, diff] diff of the committed changes
fixed in cvs.
