Bug#334534: Patch from bug 307724 breaks Eclipse
Hi, On Mon, Dec 19, 2005, Douglas Pollock wrote: I suppose the philosophies are just different between Eclipse and Debian, which makes it hard for me to understand your position. In Eclipse this would be viewed as a regression. If we have a patch that fixes some bug and causes regressions, we would generally leave the patch out (or revert the patch if we put it in). In this case, the patch did not cause regression, but fixed a Gtk bug, which affected numerous apps. I could argue the following: The regression is on Eclipse side, which implemented a workaround for this Gtk bug, and where this workaround does not work under Debian. Why don't you simply remove that workaround if it causes a regression under Debian? And you would then probably answer: the workaround is helpful on other distros, and I would continue but our patch is helpful for other apps. I don't want to discuss this ad nauseam, I tried being constructive, and tried to look into options: - changing a low-level patch for Gtk in Debian stable is 10 times more risky than it was to include it prior to the stable release, and won't ever be accepted by stable release managers; FORGET IT - Gtk's upstream doesn't want to add API to detect Debian and special case easily - you don't seem to be willing to special case Eclipse's behavior for Debian anyway (be it without or with a special API) The only remaining way I see for you to handle this is a Gtk update for backports.org, but I'm absolutely unclear whether this has a change to be accepted, and I don't know anything about backports.org procedures. Bye, -- Loïc Minier [EMAIL PROTECTED] Current Earth status: NOT DESTROYED
Bug#334534: Patch from bug 307724 breaks Eclipse
Hi, On Fri, Dec 16, 2005, Billy Biggs wrote: I talked about this again with seb128 at UBZ. I really think the right solution is for Debian to revert the change. It's a really low-level X thing, and there is no good way for us to detect that it is fixed. Changing the Eclipse code in our stable release, especially now that it is so widely tested and used, is really hard. I can appreciate that the same is true for Debian. However, in the Debian case, there are also lots of other distributions which are shipping unpatched versions (or, at leat differently patched versions) of GTK+. Just in terms of re-introducing bugs - clearly the safer fix is to revert a Debian-specific patch applied to GTK+, rather than patch Eclipse for all distributions. We already had the discussion, and you saw by yourself that it was impossible to revert such a sensible change in a deeply frozen distro. There are 1629 packages depending on libgtk2.0-0 available to my Debian system, and this is excluding packages using libgtk2.0-0 indirectly, eg via Python or Perl bindings. How many would be affected by such a reversal? Is there anyway that we can at least get a count? The answer to these questions is probably that we have no way to measure the impact on such a huge number of packages, no-one can tell. Besides, even if we knew that reverting the patch would need patching of say 20 packages, there's *no* *way* the stable team is going to allow such a change for the sake of... Eclipse. And this is only assuming that we can really fix the bug for other packages/applications from their point of view. What if the application is written in python and we can't work around the gdk problems because the bindings aren't available? I'm afraid we should have detected this problem earlier in the stable release cycle. Back then, this patch helped fixing a real bug across a number of applications, so it was interesting to include. All I can offer is that we work with upstream to get some extra version information in the API so that distros can include some package related information (eg the version of the package). Unless you have better ideas to solve the current situation than revert this change in libgtk for Eclipse workaround code not to break, we're stuck. Cheers, -- Loïc Minier [EMAIL PROTECTED]
Bug#334534: Patch from bug 307724 breaks Eclipse
reopen 334534 forwarded 334534 http://bugzilla.gnome.org/show_bug.cgi?id=324336 thanks Hi, On Sat, Dec 17, 2005, Loic Minier wrote: All I can offer is that we work with upstream to get some extra version information in the API so that distros can include some package related information (eg the version of the package). Please subscribe and send your comments to: http://bugzilla.gnome.org/show_bug.cgi?id=324336 Bye, -- Loïc Minier [EMAIL PROTECTED]
Bug#334534: Patch from bug 307724 breaks Eclipse
Hi, On Fri, Dec 16, 2005, Douglas Pollock wrote: I would appreciate it if you could re-open this bug. Eclipse continues to get bugs filed about this issue (e.g., https://bugs.eclipse.org/bugs/show_bug.cgi?id=119622). It means that one of the first questions we must ask when debugging any focus or key binding issue is: Are you using Debian? We're forced into doing a lot of finger-pointing at Debian, which makes me uncomfortable. This is also a drain on our resources -- triaging bugs and replying to newsgroups. Well, there's nothing new, and we agreed there was no way to revert this (see the bug log and check with Billy Biggs for details). The short story is that we included a *fix*, which does help some application, and Eclipse maps the upstream version number of Gtk to a version which has not the fix and takes counter-measures, and this clashes. Reverting the fix is not only very difficult in a dist frozen like sarge is and for a core lib such as gtk, but would also break other apps (which don't have such dynamic workarounds). All I can suggest is that you check whether you're on Debian sarge, or whether the Gtk Debian package is installed in a borken version (borken from your perspective), or maybe offer a command-line flag? Unless you have new ideas to unlock this situation, no one can revert that for Debian. Cheers, -- Loïc Minier [EMAIL PROTECTED]
Bug#334534: Patch from bug 307724 breaks Eclipse
Loic Minier ([EMAIL PROTECTED]): On Fri, Dec 16, 2005, Douglas Pollock wrote: I would appreciate it if you could re-open this bug. Eclipse continues to get bugs filed about this issue (e.g., https://bugs.eclipse.org/bugs/show_bug.cgi?id=119622). It means that one of the first questions we must ask when debugging any focus or key binding issue is: Are you using Debian? We're forced into doing a lot of finger-pointing at Debian, which makes me uncomfortable. This is also a drain on our resources -- triaging bugs and replying to newsgroups. Well, there's nothing new, and we agreed there was no way to revert this (see the bug log and check with Billy Biggs for details). The short story is that we included a *fix*, which does help some application, and Eclipse maps the upstream version number of Gtk to a version which has not the fix and takes counter-measures, and this clashes. Reverting the fix is not only very difficult in a dist frozen like sarge is and for a core lib such as gtk, but would also break other apps (which don't have such dynamic workarounds). I talked about this again with seb128 at UBZ. I really think the right solution is for Debian to revert the change. It's a really low-level X thing, and there is no good way for us to detect that it is fixed. Changing the Eclipse code in our stable release, especially now that it is so widely tested and used, is really hard. I can appreciate that the same is true for Debian. However, in the Debian case, there are also lots of other distributions which are shipping unpatched versions (or, at leat differently patched versions) of GTK+. Just in terms of re-introducing bugs - clearly the safer fix is to revert a Debian-specific patch applied to GTK+, rather than patch Eclipse for all distributions. I urge you again to reconsider. Thanks, -Billy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334534: Patch from bug 307724 breaks Eclipse
Package: gtk+2.0 Severity: important The fix for Debian bug 307724 added a patch from gtk-2-6 branch to the 2.6.4 release for sarge. This causes the following bugs in Eclipse, where keybindings can completely fail: https://bugs.eclipse.org/bugs/show_bug.cgi?id=111479 https://bugs.eclipse.org/bugs/show_bug.cgi?id=111514 The patch was to fix the following long-standing bug in GTK+: http://bugzilla.gnome.org/show_bug.cgi?id=109246 While we worked with GTK+ to fix this bug, Eclipse had a workaround which conflicts with the patch. For 3.1.1 we disable our workaround if GTK+ = 2.6.8, but this check does not work with the patched version of 2.6.4 from debian. There is unfortunately no clean way to detect whether the version of GTK+ is fixed. I think the patch should be removed, or stable should be updated to GTK+ 2.6.8. Patching back a very tricky and low-level X event handling patch into a previous version just decreases the stability of the toolkit. -Billy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334534: Patch from bug 307724 breaks Eclipse
Hi, On Tue, Oct 18, 2005, Billy Biggs wrote: I think the patch should be removed, or stable should be updated to GTK+ 2.6.8. Patching back a very tricky and low-level X event handling patch into a previous version just decreases the stability of the toolkit. Updating stable for something as large as Gtk isn't trivial, and only happens for really important fixes which are visibly correct. Updating to a higher version is not an option for Debian, but updating the patch to match the actual fix implemented upstream is more feasible. However, how much confidence do you have that it won't break anything? Would it break older version of Eclipse working around the Gtk bug? Cheers, -- Loïc Minier [EMAIL PROTECTED]
Bug#334534: Patch from bug 307724 breaks Eclipse
Loic Minier ([EMAIL PROTECTED]): Updating stable for something as large as Gtk isn't trivial, and only happens for really important fixes which are visibly correct. Updating to a higher version is not an option for Debian, but updating the patch to match the actual fix implemented upstream is more feasible. However, how much confidence do you have that it won't break anything? Would it break older version of Eclipse working around the Gtk bug? The patch applied to Debian's 2.6.4 matches the fix in 2.6.8 as far as I know. The issue is that Eclipse can't easily determine whether it should shut off its workaround, so it wrongly considers Debian's 2.6.4 to be broken. The workaround conflicts and Eclipse breaks. So, the 2.6.4 in Debian stable is fixed. but's no longer GTK+ 2.6.4 as it claims to be. -Billy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]