Package: sat4j Version: 2.2.0-2 Severity: serious Hi Michael Tautschnig, Release people and Java people.
In light of #587657, I have decided to file an RC bug against sat4j to prevent it from migrating to testing and quite possibly breaking eclipse-platform in testing. I strongly suspect that eclipse is quite frankly unable to deal with OSGi bundles (jar files with OSGi metadata in their manifests) changing their "Bundle-Version" entry if they are listed in the bundles.info file that eclipse uses to register some of these bundles (sat4j being one of them). #587657 started out being a problem with jetty (that bumped its version in a recent upload) for some users; after jetty migrated to testing it was silent for a short while. Shortly after the sat4j upload we got a new report of eclipse acting up and sat4j appears to have changed its Bundle-Version in the 2.2.0-2 version currently available in unstable. I am currently having the person test if reverting sat4j to the 2.2.0-1 in testing (and correcting the bundles.info which gets messed up) solves the issue. I will get back to you when I have more information on that. If my speculation turns out to be true, then we have a general issue with eclipse that needs to be solved. It is simply too error-prone to rely on maintainers to remember to bump their "Breaks: eclipse-$part ($version)" every time they update their package and have us to a Source upload to bump (Build-)Depends. "Luckily" most of the Java Team maintained packages have the OSGi metadata hard-cored and will have to be updated manually, so at the current time these packages should not break eclipse (provided people just leave it alone for now). I suspect we can solve this by using file-triggers and a script to manually update bundles.info, but it is not something I can promise to get done and have well testing for Squeeze, so I would much rather just do one more upload of eclipse 3.5.2, bumping the (Build-)Depends for Squeeze and then work on this script for Squeeze + 1. Obviously I would need a freeze exception for eclipse and I will file that separated when we have verified the issue and prepared the issue. I would like to apologize in advance if my assertions turn out to be incorrect and the issue turn out to be unrelated to sat4j and eclipse. I decided to take the "rather safe than sorry" approach to possibly breaking eclipse in testing. As I am returning from DebConf10 tomorrow, I may be slow to reply in the next few days. ~Niels -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages sat4j depends on: ii default-jre [java6-runtime] 1.6-38 Standard Java or Java compatible R ii jarwrapper 0.31 Run executable Java .jar files ii openjdk-6-jre [java6-runtim 6b18-1.8.1-1 OpenJDK Java runtime, using Hotspo ii sun-java6-jre [java6-runtim 6.20-dlj-4 Sun Java(TM) Runtime Environment ( sat4j recommends no packages. sat4j suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100808005424.25933.25334.report...@getsu.thykier.net
