Bug#866671: Bug#681726: Time to remove eclipse from Testing?

[Ivo De Decker]

Hi,

On Mon, May 14, 2018 at 06:44:17PM +0200, Emilio Pozuelo Monfort wrote:
> I took a quick look at the current status:

[...]

> That leaves aspectj as the only blocker:

With the new aspectj in testing, this is no longer an issue. I added a removal
hint for

webkitgtk/2.4.11-4 eclipse/3.8.1-11 byte-buddy/1.7.11-1 hibiscus/2.8.3+dfsg-2
ivyplusplus/1.28-1 jameica/2.8.1+dfsg-2 lombok/1.16.22-2 lombok-patcher/0.22-2
mimepull/1.9.7-1 pleiades/1.7.27-4 saaj-ri/1.4.1-1 statsvn/0.7.0.dfsg-8
svnclientadapter/1.10.12-1 svnkit/1.8.14-2 swtchart/0.10.0-2 swt-gtk/3.8.2-5

Cheers,

Ivo

Bug#681726: Time to remove eclipse from Testing?

[Emilio Pozuelo Monfort]

On Sun, 4 Feb 2018 19:34:55 +0100 Markus Koschany  wrote:
> On Wed, 15 Nov 2017 18:01:07 +0200 Adrian Bunk  wrote:
> [...]
> > I tried to sort out what I could find as required for getting the
> > ancient eclipse out of testing in [1]:
> > 
> > 1. src:bnd
> > You fixed that already.
> > 
> > 2. batik -> maven -> guice -> libspring-java -> aspectj -> eclipse-platform
> > Is there some good way to break this dependency chain?
> > 
> > 3. split libequinox-osgi-java out of src:eclise
> > Or as a short-term hack, build only libequinox-osgi-java from src:eclipse.
> 
> I have spent some time this weekend on Eclipse again. I have created a
> standalone src:libequinox-osgi-java package and successfully rebuilt all
> reverse-dependencies. We only have to make a small adjustment in
> src:netbeans and src:libnb-platform18-java and update the osgi patch.
> 
> If there are no objections I could go ahead and upload
> libequinox-osgi-java to NEW.
> 
> eclipse-rcp:
> 
> * svnkit:
> 
> There are two Eclipse specific classes that fail to build. As a
> workaround we could remove one of them and patch SVNWCUtil.
> 
> * android-sdktools and android-platform-tools-swt
> 
> According to [1] both packages should be removed anyway.
> 
> After that there would be only three packages left (not counting the
> eclipse plugins) that build-depend on either eclipse-platform (aspectj)
> or eclipse-jdt (lombok, biogenesis)

I took a quick look at the current status:

| $ dak rm -Rn -s testing eclipse
| [...]
| Checking reverse dependencies...
| # Broken Depends:
| pleiades: pleiades
|
| # Broken Build-Depends:
| aspectj: eclipse-platform (>= 3.4.1)
| lombok: eclipse-jdt
| eclipse-platform-data
| svnkit: eclipse-rcp

biogenesis build-deps on 'default-jdk | eclipse-jdt', so that's not a problem.

pleiades, lombok and svnkit could be removed from testing alongside eclipse.

That leaves aspectj as the only blocker:

| $ dak rm -Rn -s testing aspectj
| [...]
| Checking reverse dependencies...
| # Broken Depends:
| aspectj-maven-plugin: libaspectj-maven-plugin-java
|
| # Broken Build-Depends:
| aspectj-maven-plugin: libaspectj-java (>= 1.8.2)
| eclipselink: aspectj
| libspring-java: libaspectj-java
| openjpa: aspectj
| shiro: libaspectj-java

Cheers,
Emilio

Bug#681726: Time to remove eclipse from Testing?

[Hans-Christoph Steiner]

Markus Koschany:
> On Wed, 15 Nov 2017 18:01:07 +0200 Adrian Bunk  wrote:
> [...]
>> I tried to sort out what I could find as required for getting the
>> ancient eclipse out of testing in [1]:
>>
>> 1. src:bnd
>> You fixed that already.
>>
>> 2. batik -> maven -> guice -> libspring-java -> aspectj -> eclipse-platform
>> Is there some good way to break this dependency chain?
>>
>> 3. split libequinox-osgi-java out of src:eclise
>> Or as a short-term hack, build only libequinox-osgi-java from src:eclipse.
> 
> I have spent some time this weekend on Eclipse again. I have created a
> standalone src:libequinox-osgi-java package and successfully rebuilt all
> reverse-dependencies. We only have to make a small adjustment in
> src:netbeans and src:libnb-platform18-java and update the osgi patch.
> 
> If there are no objections I could go ahead and upload
> libequinox-osgi-java to NEW.
> 
> eclipse-rcp:
> 
> * svnkit:
> 
> There are two Eclipse specific classes that fail to build. As a
> workaround we could remove one of them and patch SVNWCUtil.
> 
> * android-sdktools and android-platform-tools-swt
> 
> According to [1] both packages should be removed anyway.
> 
> After that there would be only three packages left (not counting the
> eclipse plugins) that build-depend on either eclipse-platform (aspectj)
> or eclipse-jdt (lombok, biogenesis)
> 
> Next I'm going to try if a separate eclipse-jdt package from [2] could
> be a drop-in-replacement for our current package. The latest stable
> release appears to be S4_8_0_M5.
> 
> Regards,
> 
> Markus
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879175#10
> [2] https://github.com/eclipse/eclipse.jdt.core

As far as I know, android-sdktools and android-platform-tools-swt are
both deprecated by Google.  So it should be fine to remove them also.
There is a chance that other parts of the Android SDK depend on JARs
from Eclipse, but I guess that's not likely/

.hc

Bug#681726: Time to remove eclipse from Testing?

[Markus Koschany]

On Wed, 15 Nov 2017 18:01:07 +0200 Adrian Bunk  wrote:
[...]
> I tried to sort out what I could find as required for getting the
> ancient eclipse out of testing in [1]:
> 
> 1. src:bnd
> You fixed that already.
> 
> 2. batik -> maven -> guice -> libspring-java -> aspectj -> eclipse-platform
> Is there some good way to break this dependency chain?
> 
> 3. split libequinox-osgi-java out of src:eclise
> Or as a short-term hack, build only libequinox-osgi-java from src:eclipse.

I have spent some time this weekend on Eclipse again. I have created a
standalone src:libequinox-osgi-java package and successfully rebuilt all
reverse-dependencies. We only have to make a small adjustment in
src:netbeans and src:libnb-platform18-java and update the osgi patch.

If there are no objections I could go ahead and upload
libequinox-osgi-java to NEW.

eclipse-rcp:

* svnkit:

There are two Eclipse specific classes that fail to build. As a
workaround we could remove one of them and patch SVNWCUtil.

* android-sdktools and android-platform-tools-swt

According to [1] both packages should be removed anyway.

After that there would be only three packages left (not counting the
eclipse plugins) that build-depend on either eclipse-platform (aspectj)
or eclipse-jdt (lombok, biogenesis)

Next I'm going to try if a separate eclipse-jdt package from [2] could
be a drop-in-replacement for our current package. The latest stable
release appears to be S4_8_0_M5.

Regards,

Markus

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879175#10
[2] https://github.com/eclipse/eclipse.jdt.core

Bug#681726: Time to remove eclipse from Testing?

[Emmanuel Bourg]

Le 15/11/2017 à 17:56, Emmanuel Bourg a écrit :

> I suspect we build the aspectj eclipse plugin but don't even install it
> in the binary package. I'll see if this can be disabled.

Long story short, it can't. aspectj deeply depends on eclipse jdt. Also
upgrading to the latest version isn't possible without updating Eclipse.

This is turning into a nightmare, we can neither upgrade nor remove
Eclipse and it's going to block the Java 9 transition :(

Emmanuel Bourg

Bug#681726: Time to remove eclipse from Testing?

[Emmanuel Bourg]

Le 15/11/2017 à 17:01, Adrian Bunk a écrit :

> 2. batik -> maven -> guice -> libspring-java -> aspectj -> eclipse-platform
> Is there some good way to break this dependency chain?

I suspect we build the aspectj eclipse plugin but don't even install it
in the binary package. I'll see if this can be disabled.

Emmanuel Bourg

Bug#681726: Time to remove eclipse from Testing?

[Adrian Bunk]

On Wed, Nov 15, 2017 at 12:08:10AM +0100, Markus Koschany wrote:
>...
> We should definitely try to avoid this sort of dependency mess in the
> future by packaging important libraries like eclipse-rcp in a separate
> source package. That would be similar to what we are doing whith
> Netbeans and libnb-platform18-java at the moment. It simply ensures that
> we can resolve such issues more easily by dropping the hard to maintain
> IDE but keeping other important dependencies which don't require that
> much effort in theory.

I tried to sort out what I could find as required for getting the
ancient eclipse out of testing in [1]:

1. src:bnd
You fixed that already.

2. batik -> maven -> guice -> libspring-java -> aspectj -> eclipse-platform
Is there some good way to break this dependency chain?

3. split libequinox-osgi-java out of src:eclise
Or as a short-term hack, build only libequinox-osgi-java from src:eclipse.

> Regards,
> 
> Markus

cu
Adrian

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880470#10

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#681726: Time to remove eclipse from Testing?

[Markus Koschany]

Am 09.11.2017 um 21:34 schrieb Jeremy Bicha:
[...]
> Have you considered dropping the libswt-webkit-gtk-3-jni dependency
> from eclipse-rcp? Then the swt-gtk source package could stop building
> libswt-webkit-gtk-3-jni and we could complete the webkitgtk removal
> from Debian Testing.
> 
> Thanks,
> Jeremy Bicha

Hi,

sorry for the delay.

I haven't tested that yet but I believe this will simply make the
package unusable for everyone. I'm not sure what we can do to assist you
in your effort to remove webkitgtk from Debian. Ok, most obviously we
could "just" package the latest Eclipse version but that won't happen
anytime soon.

We should definitely try to avoid this sort of dependency mess in the
future by packaging important libraries like eclipse-rcp in a separate
source package. That would be similar to what we are doing whith
Netbeans and libnb-platform18-java at the moment. It simply ensures that
we can resolve such issues more easily by dropping the hard to maintain
IDE but keeping other important dependencies which don't require that
much effort in theory.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#681726: Time to remove eclipse from Testing?

[Jeremy Bicha]

On Fri, Oct 20, 2017 at 5:52 PM, Jeremy Bicha  wrote:
> On Fri, Oct 20, 2017 at 12:47 PM, Markus Koschany  wrote:
>> Am 20.10.2017 um 18:43 schrieb Jeremy Bicha:
>>> Are there any objections to me requesting that the ftpmasters remove
>>> swt-gtk and eclipse from Debian Testing so that we can complete the
>>> webkitgtk removal from Testing?
>>>
>>> Thanks,
>>> Jeremy Bicha
>>
>> Thank you for contacting us. I completely agree with you. Eclipse in its
>> current state should not be a blocker for other packages in testing. I
>> can't promise anything but I will try to get the package in shape again
>> but this process will be quite slow probably, so the request for help is
>> as valid as ever.
>
> Never mind. I tried doing the dak queries and I eventually got more
> than 500 reverse-depends before I gave up. (Attached)
>
> The only other reverse-depends of libswt-webkit-gtk-3-jni in Testing
> now is tuxguitar which was already switched in Unstable to swt4-gtk
> which should work with webkit2gtk.

Have you considered dropping the libswt-webkit-gtk-3-jni dependency
from eclipse-rcp? Then the swt-gtk source package could stop building
libswt-webkit-gtk-3-jni and we could complete the webkitgtk removal
from Debian Testing.

Thanks,
Jeremy Bicha

Bug#681726: Time to remove eclipse from Testing?

[Markus Koschany]

Am 01.11.2017 um 22:04 schrieb Adrian Bunk:
> On Wed, Nov 01, 2017 at 09:23:32PM +0100, Markus Koschany wrote:
>> Am 01.11.2017 um 20:47 schrieb Jeremy Bicha:
>>> On Fri, Oct 20, 2017 at 6:24 PM, Emmanuel Bourg  wrote:
 Le 20/10/2017 à 23:52, Jeremy Bicha a écrit :

> Never mind. I tried doing the dak queries and I eventually got more
> than 500 reverse-depends before I gave up. (Attached)

 Funny, I never realized that src:eclipse was basically holding most of
 the Java packages. Maybe this package deserves some of my attention
 after all ;)
>>>
>>> Adrian Bunk suggests removing bnd's Build-Depends on eclipse-jdt and
>>> eclipse-rcp. He thinks that might significantly decrease the number of
>>> affected packages.
>>
>> It appears the package can be built without eclipse-jdt and eclipse-rcp.
>> Works with cowbuilder at least. We probably exclude the eclipse classes
>> in debian/bootstrap.xml anyway. I'm not exactly sure how the BND Eclipse
>> plugin is supposed to work because I see we also symlink various jars
>> into Eclipse specific directories in debian/rules.
>>
>> I believe it would be possible to drop the build-dependencies on
>> eclipse-jdt and eclipse-rcp. We would lose the BND Eclipse plugin but
>> the rest should still continue to work.
> 
> Which Eclipse plugin would we lose?
> 
> Before suggesting to drop the build dependency I did of course try it 
> with debdiff between the built packages (no difference), and read the 
> comment in README.md about the previous Eclipse-specific plugin no 
> longer available upstream (which is why I started thinking the build 
> dependency might just be a leftover).

I did a grep -r "eclipse-jdt" but now it seems those are just settings
files. I have never used the BND Eclipse plugin but I saw that we still
mention it in the package description. Apparently bndtools is the
successor and is maintained in a separate repository now. All in all
that means it should be safe to remove the build-dependencies and
obsolete symlinks in debian/rules.




signature.asc
Description: OpenPGP digital signature

Bug#681726: Time to remove eclipse from Testing?

[Adrian Bunk]

On Wed, Nov 01, 2017 at 09:23:32PM +0100, Markus Koschany wrote:
> Am 01.11.2017 um 20:47 schrieb Jeremy Bicha:
> > On Fri, Oct 20, 2017 at 6:24 PM, Emmanuel Bourg  wrote:
> >> Le 20/10/2017 à 23:52, Jeremy Bicha a écrit :
> >>
> >>> Never mind. I tried doing the dak queries and I eventually got more
> >>> than 500 reverse-depends before I gave up. (Attached)
> >>
> >> Funny, I never realized that src:eclipse was basically holding most of
> >> the Java packages. Maybe this package deserves some of my attention
> >> after all ;)
> > 
> > Adrian Bunk suggests removing bnd's Build-Depends on eclipse-jdt and
> > eclipse-rcp. He thinks that might significantly decrease the number of
> > affected packages.
> 
> It appears the package can be built without eclipse-jdt and eclipse-rcp.
> Works with cowbuilder at least. We probably exclude the eclipse classes
> in debian/bootstrap.xml anyway. I'm not exactly sure how the BND Eclipse
> plugin is supposed to work because I see we also symlink various jars
> into Eclipse specific directories in debian/rules.
> 
> I believe it would be possible to drop the build-dependencies on
> eclipse-jdt and eclipse-rcp. We would lose the BND Eclipse plugin but
> the rest should still continue to work.

Which Eclipse plugin would we lose?

Before suggesting to drop the build dependency I did of course try it 
with debdiff between the built packages (no difference), and read the 
comment in README.md about the previous Eclipse-specific plugin no 
longer available upstream (which is why I started thinking the build 
dependency might just be a leftover).

> Markus

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#681726: Time to remove eclipse from Testing?

[Markus Koschany]

Am 01.11.2017 um 20:47 schrieb Jeremy Bicha:
> On Fri, Oct 20, 2017 at 6:24 PM, Emmanuel Bourg  wrote:
>> Le 20/10/2017 à 23:52, Jeremy Bicha a écrit :
>>
>>> Never mind. I tried doing the dak queries and I eventually got more
>>> than 500 reverse-depends before I gave up. (Attached)
>>
>> Funny, I never realized that src:eclipse was basically holding most of
>> the Java packages. Maybe this package deserves some of my attention
>> after all ;)
> 
> Adrian Bunk suggests removing bnd's Build-Depends on eclipse-jdt and
> eclipse-rcp. He thinks that might significantly decrease the number of
> affected packages.

It appears the package can be built without eclipse-jdt and eclipse-rcp.
Works with cowbuilder at least. We probably exclude the eclipse classes
in debian/bootstrap.xml anyway. I'm not exactly sure how the BND Eclipse
plugin is supposed to work because I see we also symlink various jars
into Eclipse specific directories in debian/rules.

I believe it would be possible to drop the build-dependencies on
eclipse-jdt and eclipse-rcp. We would lose the BND Eclipse plugin but
the rest should still continue to work.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#681726: Time to remove eclipse from Testing?

[Jeremy Bicha]

On Fri, Oct 20, 2017 at 6:24 PM, Emmanuel Bourg  wrote:
> Le 20/10/2017 à 23:52, Jeremy Bicha a écrit :
>
>> Never mind. I tried doing the dak queries and I eventually got more
>> than 500 reverse-depends before I gave up. (Attached)
>
> Funny, I never realized that src:eclipse was basically holding most of
> the Java packages. Maybe this package deserves some of my attention
> after all ;)

Adrian Bunk suggests removing bnd's Build-Depends on eclipse-jdt and
eclipse-rcp. He thinks that might significantly decrease the number of
affected packages.

Thanks,
Jeremy Bicha

Bug#681726: Time to remove eclipse from Testing?

[Emmanuel Bourg]

Le 21/10/2017 à 00:33, Markus Koschany a écrit :

> Please claim this bug or tell me when you start to work on something
> related to Eclipse or Tycho, so that we avoid double work.

For now I'm just working on swt4-gtk. I'll ping the list if I feel ready
for some tycho/eclipse action.

Bug#681726: Time to remove eclipse from Testing?

[Markus Koschany]

Am 21.10.2017 um 00:24 schrieb Emmanuel Bourg:
> Le 20/10/2017 à 23:52, Jeremy Bicha a écrit :
> 
>> Never mind. I tried doing the dak queries and I eventually got more
>> than 500 reverse-depends before I gave up. (Attached)
> 
> Funny, I never realized that src:eclipse was basically holding most of
> the Java packages. Maybe this package deserves some of my attention
> after all ;)

Please claim this bug or tell me when you start to work on something
related to Eclipse or Tycho, so that we avoid double work.

Thanks

Markus



signature.asc
Description: OpenPGP digital signature

Bug#681726: Time to remove eclipse from Testing?

[Emmanuel Bourg]

Le 20/10/2017 à 23:52, Jeremy Bicha a écrit :

> Never mind. I tried doing the dak queries and I eventually got more
> than 500 reverse-depends before I gave up. (Attached)

Funny, I never realized that src:eclipse was basically holding most of
the Java packages. Maybe this package deserves some of my attention
after all ;)

Bug#681726: Time to remove eclipse from Testing?

[Jeremy Bicha]

On Fri, Oct 20, 2017 at 12:47 PM, Markus Koschany  wrote:
> Am 20.10.2017 um 18:43 schrieb Jeremy Bicha:
>> Are there any objections to me requesting that the ftpmasters remove
>> swt-gtk and eclipse from Debian Testing so that we can complete the
>> webkitgtk removal from Testing?
>>
>> Thanks,
>> Jeremy Bicha
>
> Thank you for contacting us. I completely agree with you. Eclipse in its
> current state should not be a blocker for other packages in testing. I
> can't promise anything but I will try to get the package in shape again
> but this process will be quite slow probably, so the request for help is
> as valid as ever.

Never mind. I tried doing the dak queries and I eventually got more
than 500 reverse-depends before I gave up. (Attached)

The only other reverse-depends of libswt-webkit-gtk-3-jni in Testing
now is tuxguitar which was already switched in Unstable to swt4-gtk
which should work with webkit2gtk.

Thanks,
Jeremy Bicha
jbicha@coccia:~$ dak rm -Rns testing swt-gtk
Will remove the following packages from testing:

libswt-cairo-gtk-3-jni |3.8.2-4 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
libswt-glx-gtk-3-jni |3.8.2-4 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
libswt-gnome-gtk-3-jni |3.8.2-4 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
libswt-gtk-3-java |3.8.2-4 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
libswt-gtk-3-jni |3.8.2-4 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
libswt-webkit-gtk-3-jni |3.8.2-4 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
   swt-gtk |3.8.2-4 | source

Maintainer: Debian Java Maintainers 


--- Reason ---

--

Checking reverse dependencies...
# Broken Depends:
androidsdk-tools: androidsdk-traceview
  androidsdk-uiautomatorviewer
  libandroidsdk-common-java
  libandroidsdk-ddmlib-java
  libandroidsdk-ddmuilib-java
  libandroidsdk-hierarchyviewerlib-java
  libandroidsdk-sdklib-java
  libandroidsdk-sdkstats-java
  libandroidsdk-swtmenubar-java
eclipse: eclipse-rcp [amd64 arm64 armel armhf i386 mips mipsel ppc64el s390x]
piccolo: libpiccolo-java
tuxguitar: tuxguitar

# Broken Build-Depends:
davmail: libswt-gtk-3-java
eclipse: libswt-gtk-3-java (>= 3.8.0~m6)
piccolo: libswt-gtk-3-java
tuxguitar: libswt-gtk-3-java

Dependency problem found.


jbicha@coccia:~$ dak rm -Rns testing androidsdk-tools davmail eclipse piccolo 
swt-gtk
Will remove the following packages from testing:

androidsdk-ddms | 22.2+git20130830~92d25d6-4 | all
androidsdk-hierarchyviewer | 22.2+git20130830~92d25d6-4 | all
androidsdk-tools | 22.2+git20130830~92d25d6-4 | source
androidsdk-traceview | 22.2+git20130830~92d25d6-4 | all
androidsdk-uiautomatorviewer | 22.2+git20130830~92d25d6-4 | all
   davmail | 4.8.0.2479-2 | source, all
   eclipse |   3.8.1-10 | source, all
eclipse-jdt |   3.8.1-10 | all
eclipse-pde |   3.8.1-10 | amd64, arm64, armel, armhf, i386, mips, mipsel, 
ppc64el, s390x
eclipse-platform |   3.8.1-10 | amd64, arm64, armel, armhf, i386, mips, mipsel, 
ppc64el, s390x
eclipse-platform-data |   3.8.1-10 | all
eclipse-rcp |   3.8.1-10 | amd64, arm64, armel, armhf, i386, mips, mipsel, 
ppc64el, s390x
libandroidsdk-common-java | 22.2+git20130830~92d25d6-4 | all
libandroidsdk-ddmlib-java | 22.2+git20130830~92d25d6-4 | all
libandroidsdk-ddmuilib-java | 22.2+git20130830~92d25d6-4 | all
libandroidsdk-hierarchyviewerlib-java | 22.2+git20130830~92d25d6-4 | all
libandroidsdk-sdklib-java | 22.2+git20130830~92d25d6-4 | all
libandroidsdk-sdkstats-java | 22.2+git20130830~92d25d6-4 | all
libandroidsdk-swtmenubar-java | 22.2+git20130830~92d25d6-4 | all
libequinox-osgi-java |   3.8.1-10 | all
libpiccolo-java |  1.2-1 | all
libswt-cairo-gtk-3-jni |3.8.2-4 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
libswt-glx-gtk-3-jni |3.8.2-4 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
libswt-gnome-gtk-3-jni |3.8.2-4 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
libswt-gtk-3-java |3.8.2-4 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
libswt-gtk-3-jni |3.8.2-4 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
libswt-webkit-gtk-3-jni |3.8.2-4 | amd64, arm64, armel, armhf, i386, mips, 
mips64el, mipsel, ppc64el, s390x
   piccolo |  1.2-1 | source
   swt-gtk |3.8.2-4 | source

Maintainer: Debian Java Maintainers 
, Javier Fernández-Sanguino Peña 
, Alexandre Rossi , Debian 

Processed: Re: Bug#681726: Time to remove eclipse from Testing?

[Debian Bug Tracking System]

Processing control commands:

> severity -1 serious
Bug #681726 [src:eclipse] eclipse: Upgrade to latest upstream release (HELP 
WANTED)
Bug #725377 [src:eclipse] eclipse: Upgrade to latest upstream release (HELP 
WANTED)
Bug #732959 [src:eclipse] eclipse: Upgrade to latest upstream release (HELP 
WANTED)
Bug #738506 [src:eclipse] eclipse: Upgrade to latest upstream release (HELP 
WANTED)
Bug #789928 [src:eclipse] eclipse: Upgrade to latest upstream release (HELP 
WANTED)
Bug #831603 [src:eclipse] eclipse version
Severity set to 'serious' from 'wishlist'
Severity set to 'serious' from 'wishlist'
Severity set to 'serious' from 'wishlist'
Severity set to 'serious' from 'wishlist'
Severity set to 'serious' from 'wishlist'
Severity set to 'serious' from 'wishlist'

-- 
681726: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681726
725377: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725377
732959: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732959
738506: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738506
789928: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789928
831603: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831603
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems