The GNOME desktop switcher has been misbehaving since I upgraded to gnome 2.4 - on both my desktop and notebook. Specifically, what's happening is that the workspace is "moved" - so it appears that all the windows on the desktop move around when switching between desktops using the pager. For more details, it's covered in these bugs on bugzilla.gnome.org: http://bugzilla.gnome.org/show_bug.cgi?id=122512 http://bugzilla.gnome.org/show_bug.cgi?id=122205 http://bugzilla.gnome.org/show_bug.cgi?id=122086 The latter has a patch for libwnck which, to my understanding, fixes the problem by not moving the viewable desktop area if your desktop size is fixed (which is the correct behaviour). The patch applies cleanly to libwnck-2.4.0.1, and I can verify that applying it fixes the problem.
Created attachment 18686 [details, diff] Patch for libwnck to correct switcher behaviour
Created attachment 18687 [details] Updated libwnck-2.4.0.1-r1 ebuild that applies patch
*** Bug 30641 has been marked as a duplicate of this bug. ***
applied to libwnck-2.4.0.1 in portage, thanks for your report + gnome bugzilla links.
*** Bug 30934 has been marked as a duplicate of this bug. ***
Can someone explain to me why this wasn't bumped to -r1? Since it now installs something DIFFERENT (i.e. fixed) than the original 2.4.0.1, it should have been bumped so that people get the updated ebuild. I could understand it if 2.4.0.1 hadn't been installable, but if this isn't a case in point for a -r bump, I can't see what is - and duplicates (e.g. bug 30934) are still occuring because it wasn't bumped.
To backup what I said in comment 6, from the Gentoo Linux Development Policy page, at http://www.gentoo.org/doc/en/policy.xml: ============ Versioning and revision bumps Package revision numbers should be incremented by Gentoo Linux developers when the ebuild has changed to the point where users would want to upgrade. Typically, this is the case when fixes are made to an ebuild that affect the resultant installed files, but the ebuild uses the same source tarball as the previous release. ============
as with all policy, the guidelines are just that, each situation needs to be interpreted by them. it's always important to consider that a revision will cause all users, those seeing the bug, and those not, to rebuild the package (if you were going to requote 'when the ebuild has changed to the point where users would want to upgrade'). in the light that this bug was caught within a few days of gnome going stable, and that it seems few people are actually seeing this bug (few in comparison to the other major gnome 2.4 questions/bugs we got), it was deemed unnecessary for a revision bump.
I realize that some packages have revisions bumped far too much, for trivial things - in some cases, I've seen a ebuild bumped because someone cleaned up an ebuild without actually changing anything of the final program installed. However, in this case, anyone who has installed libwnck before it was silently updated, now have a broken gnome desktop switcher - and you're trying to say those users would NOT want to upgrade? In the light of the fact that duplicates bugs have been filed SINCE this was fixed, I ask you to reconsider bumping this. >>> as with all policy, the guidelines are just that, each situation needs to be interpreted by them. <<< Very true. What I don't understand is how package A, which was released broken, should be fixed for those people who install it after a certain date, but without hunting down this bug report, people who installed it BEFORE that date will not be able to resolve the issue. This guideline is particularly important as Gentoo should strive for any specific version of a package being the same across all systems (so long as compiler settings/use flags/etc. are the same). Without some consistency, saying "I have package-x.y.z installed; could it be causing the problem?" does not allow someone to respond "I have the same version installed, without any problems" - which they should be able to do, in order to enable users to help one another. To quote further from the guidelines: ============= If you make an internal, stylistic change to the ebuild that does not change any of the installed files, then there is no need to bump the revision number. Likewise, if you fix a compilation problem in the ebuild that was affecting some users, there is no need to bump the revision number, since those for whom it worked perfectly would see no benefit in installing a new revision, and those who experienced the problem do not have the package installed (since compilation failed) and thus have no need for the new revision number to force an upgrade. ============= The change was neither stylistic nor a compilation fix - so there doesn't seem to be much basis for your creative interpretation of the developer guidelines. Had libwnck been ~x86, I could understand the argument for not bumping the revision, but this was out in stable x86 for 3 full days, and in ~x86 for nearly a month - how many users do you suppose installed it and have no idea there is a fix available for this behaviour? All of those users don't want bugs to be fixed? >>> it's always important to consider that a revision will cause all users, those seeing the bug, and those not, to rebuild the package <<< libwnck is a pretty small package; recompiling is not as significant as compiling qt or openoffice, for instance. And I am sure that there are users out there with this installed who would like it fixed.
Jason is correct. It is pretty important to bump the revision when the installation is changed in any significant way, especially bugfixes. Obz, can you offer an explanation for why it would be harmful to bump the revision? Certianly, people will have to recompile, but this is not a huge package.
nor is it a major bug, if we had to bump for every little fix people would have to recompile considerable more. I don't understand why this gets so much attention and someone writes up such a big story as to why this is a mistake complete with a days worth of research on the subject including both ethical and functional complaints. I see this happen with seriously larger ebuilds and more important fixes on a bigger scale and nobody makes a big fuzz there. Go find some other windmills. In short, the idea is that very few people of the considerable amount that use this package will encounter this bug (to my knowledge it will not happen on a default install), so it's not worth making all of them download and upgrade in my opinion. I think this all was quite clear from Obz initial comment.
It is a potentially important bugfix on a package with a ~300k tarball. There is no disadvantage to bumping the revision. Policy is that revision bumps are necessary if the material actually getting installed changes. If you don't agree with that policy, perhaps we should discuss that policy on -dev -- bugzilla's not really the right place for it. In any case, Obz has fixed it and it's a dead issue.
In reply to comment 11, my point here was not so much about this package specifically, but about the tendency of some developers to make significant fixes without bumping the revision - in this case, the bug _was_ fairly significant as it affected everyone and anyone who uses the gnome desktop switcher with the unpatched libwnck. If my "days worth" of research (which consisted of a 5 minute look at the developer guidelines, and 15 minutes to write it up) helped Gentoo follow its own guidelines, then as a user of Gentoo, it seems worth it to me. You may not agree, and I leave you to your opinion. In any event, both issues here are now fixed.
> in this case, the bug _was_ fairly significant > as it affected everyone and anyone who uses the > gnome desktop switcher with the unpatched libwnck. that's not entirely correct. and please, dont close bugs pre-emptively, i was leaving this open on purpose so i could remind myself to mark the new 2.4.0.1-r1 stable on x86 (which is happening today on advice from avenj). in any case, bug closed.
