Bug#866671: Bug#681726: Time to remove eclipse from Testing?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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 Orbital Alignment Team --- Reason --- -- Checking reverse dependencies... # B
Processed: Re: Bug#681726: Time to remove eclipse from Testing?
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