Re: java-common_0.28_i386.changes REJECTED
Michael Koch writes: > On Wed, Mar 05, 2008 at 08:52:30PM +0100, Matthias Klose wrote: > > Joerg Jaspert writes: > > > Hi Maintainer, > > > > > > rejected, lots of > > > > > > E: default-jdk: no-copyright-file > > > E: default-jdk: debian-changelog-file-missing-or-wrong-name > > > > noted. > > > > > Additionally you might want to listen/talk to others in the java team, > > > which > > > have concerns about the package, just asking me about it... > > > > would those "others" (plural) in the java team please notify me about > > their concerns? afaik these were addressed. But maybe that's the > > usual Debian communication ... > > Well, that was me. fine, who else? or was Joerg (again) inaccurate? > I strongly object that upload how it went. There are some issues that > should be solved before the upload and as thats a policy change it needs > to be explicitely ACKed by other DDs. which policy change? There's nothing new which does change the state of the current java policy. If you do want to use the opportunity of that change to clean up the policy, that's fine with me, but please don't use that "argument" for anything. fyi, these bugs about policy changes are now nearly two years old, so I don't expect those to be resolved before 6.0. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java-common_0.28_i386.changes REJECTED
On Wed, Mar 05, 2008 at 11:10:42PM +0100, Matthias Klose wrote: > which policy change? There's nothing new which does change the state > of the current java policy. If you do want to use the opportunity of > that change to clean up the policy, that's fine with me, but please > don't use that "argument" for anything. fyi, these bugs about policy > changes are now nearly two years old, so I don't expect those to be > resolved before 6.0. We are implicitely doing a policy change when your package gets uploaded. The current issues in the policy can be resolved failry quickly if we want that. You started that byyour work. And thats really good. I just want to avoid doing half-steps. Blindly uploading in the middle of a discussion doesn't help. Cheers, Michael > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java-common_0.28_i386.changes REJECTED
On Wed, Mar 05, 2008 at 08:52:30PM +0100, Matthias Klose wrote: > Joerg Jaspert writes: > > Hi Maintainer, > > > > rejected, lots of > > > > E: default-jdk: no-copyright-file > > E: default-jdk: debian-changelog-file-missing-or-wrong-name > > noted. > > > Additionally you might want to listen/talk to others in the java team, which > > have concerns about the package, just asking me about it... > > would those "others" (plural) in the java team please notify me about > their concerns? afaik these were addressed. But maybe that's the > usual Debian communication ... Well, that was me. I strongly object that upload how it went. There are some issues that should be solved before the upload and as thats a policy change it needs to be explicitely ACKed by other DDs. Chers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: java-common_0.28_i386.changes REJECTED
Joerg Jaspert writes: > Hi Maintainer, > > rejected, lots of > > E: default-jdk: no-copyright-file > E: default-jdk: debian-changelog-file-missing-or-wrong-name noted. > Additionally you might want to listen/talk to others in the java team, which > have concerns about the package, just asking me about it... would those "others" (plural) in the java team please notify me about their concerns? afaik these were addressed. But maybe that's the usual Debian communication ... have a nice evening. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
java-common_0.28_i386.changes REJECTED
Hi Maintainer, rejected, lots of E: default-jdk: no-copyright-file E: default-jdk: debian-changelog-file-missing-or-wrong-name Additionally you might want to listen/talk to others in the java team, which have concerns about the package, just asking me about it... -- bye Joerg === If you don't understand why your files were rejected, or if the override file requires editing, reply to this email. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
java-common_0.28_i386.changes is NEW
(new) default-jdk-builddep_1.5-28_i386.deb optional devel Standard Java or Java compatible build dependencies This package points to the build dependencies used to build packages requiring a Java or Java compatible Development Kit. (new) default-jdk_1.5-28_i386.deb optional devel Standard Java or Java compatible Development Kit This package points to the Java runtime, or Java compatible development kit recommended for this architecture, which is java-gcj-compat-dev for i386. (new) default-jre-headless_1.5-28_i386.deb optional interpreters Standard Java or Java compatible Runtime (headless) This package points to the Java runtime, or Java compatible runtime recommended for this architecture, which is java-gcj-compat-headless for i386. . The package is used as dependency for packages not needing a graphical display during runtime. (new) default-jre_1.5-28_i386.deb optional interpreters Standard Java or Java compatible Runtime This package points to the Java runtime, or Java compatible runtime recommended for the i386 architecture, which is java-gcj-compat-dev for . java-common_0.28.dsc to pool/main/j/java-common/java-common_0.28.dsc java-common_0.28.tar.gz to pool/main/j/java-common/java-common_0.28.tar.gz java-common_0.28_all.deb to pool/main/j/java-common/java-common_0.28_all.deb Changes: java-common (0.28) unstable; urgency=low . * Build packages default-jre, default-jre-headless, default-jdk and default-jdk-builddep. Provides an abstraction for the preferred jre/jdk for a specific architecture. Build-depending on default-jdk-builddep ensures a dependency on java-gcj-compat-dev even if the default jdk is another than java-gcj-compat-dev. Discussion thread starting at http://lists.debian.org/debian-java/2008/03/msg7.html. * update-java-alternatives: Add --jre-headless option. Override entries for your package: java-common_0.28.dsc - source misc java-common_0.28_all.deb - optional misc Announcing to [EMAIL PROTECTED] Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#469527: policy: Alternatives for minor versions of Java
Package: java-common Version: 0.25 Severity: normal It's often required to run Java application with concrete version of JDK: 1.4, 1.5 or 1.6, even if JRE is backward compatible. To achieve this, new executables should be created in /usr/bin: java1.4 java1.5 java1.6 javac1.4 javac1.4 javac1.6 and so on. These files should be symlinks to /etc/alternatives/* Similar names present Python (python2.4, python2.5), although Python is installed without alternatives. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-openvz-amd64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of java-common_0.28_i386.changes
java-common_0.28_i386.changes uploaded successfully to localhost along with the files: java-common_0.28.dsc java-common_0.28.tar.gz java-common_0.28_all.deb default-jre_1.5-28_i386.deb default-jre-headless_1.5-28_i386.deb default-jdk_1.5-28_i386.deb default-jdk-builddep_1.5-28_i386.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Andrew Haley wrote:
> Andrew Haley wrote:
>> OK, I've found it. The ClassNotFoundException is thrown from a security
>> check
>> in libgcj. We are calling Method m1 from method m0, and m1's class loader
>> is different from m0's class loader. We have to check that for every arg
>> in m1, the actual type is the same in both m1.loader and m0.loader.
>>
>> The method in question is
>> org.eclipse.core.runtime.Platform.getPlugin(String), which returns an
>> instance of org.eclipse.core.runtime.Plugin. It gets this
>> by calling org.eclipse.core.internal.plugins.PluginDescriptor.getPlugin().
>>
>> When we do the security check, we call Platform's class loader to ask it
>> to loadClass("org.eclipse.core.runtime.Plugin") and it throws a
>> ClassNotFoundException.
>
> OK, I've discovered some more. The class loader that's throwing the
> exception is a
> org.eclipse.osgi.framework.internal.core.BundleLoader, and
> it's being asked to find org.eclipse.core.runtime.Plugin. Now, this
> is where it gets really interesting.
>
> org.eclipse.core.runtime.Plugin is defined in
> eclipse/plugins/org.eclipse.core.runtime_3.3.100.v20070530.jar,
> along with a few other classes, including
> org.eclipse.core.runtime.IPluginDescriptor and
> org.eclipse.core.runtime.Platform.
>
> *but*
>
> IPluginDescriptor's class loader is not able to find
> org.eclipse.core.runtime.Plugin.
OK, and the *reason* for this is that IPluginDescriptor is loaded not
from eclipse/plugins/org.eclipse.core.runtime_3.3.100.v20070530.jar
but from
eclipse/plugins/org.eclipse.core.runtime.compatibility.registry_3.2.100.v20070316/runtime_registry_compatibility.jar
So, if you ask IPluginDescriptor's class loader to find Plugin it
throws a ClassNotFoundException.
The only files in runtime_registry_compatibility.jar are:
org/eclipse/core/internal/registry/BundleHelper.class
org/eclipse/core/internal/registry/ExtensionHandle.class
org/eclipse/core/internal/registry/ExtensionPointHandle.class
org/eclipse/core/internal/registry/RegistryCompatibilityHelper.class
org/eclipse/core/runtime/IExtension.class
org/eclipse/core/runtime/IExtensionPoint.class
org/eclipse/core/runtime/IPluginDescriptor.class
So, I think I now have enough to write a test case. Two class
loaders, one of which loads a subset of the other's classes. Call
an interface in the class defined by the subset class loader and
see what happens.
Andrew.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#432541: eclipse-cdt FTBFS with gcj-4.2
Andrew Haley wrote:
> Michael Koch wrote:
>> On Sun, Mar 02, 2008 at 12:01:03PM +, Andrew Haley wrote:
>>> Michael Koch wrote:
On Sun, Mar 02, 2008 at 10:35:28AM +, Andrew Haley wrote:
> And what was the reason? I need to know.
!ENTRY org.eclipse.osgi 4 0 2008-03-02 12:38:50.196
!MESSAGE Application error
!STACK 1
java.lang.ClassNotFoundException: org.eclipse.core.runtime.Plugin
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:402)
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:347)
make: *** [build-stamp] Fehler 13
The only small strange thing is that org.eclipse.core.runtime.Plugin
and
org.eclipse.core.runtime.Platform are in the same Jar. This must be
some
OSGi issue. At least I know now where to start debugging.
>>> Oh, right, so you *don't* actually know what the cause of this is.
>>> Me either, but
>>> I'm debugging it at the moment.
>>
>> Yeah, yesterday I thought it was just a missing jar file. Today I took a
>> closer look at at it...
>>
>>> gcj should not distinguish between natively compiled code and bytecode.
>>> The fact that it makes a difference must be a bug.
>>
>> Sounds like it. Can I somehow help? I know this is a hard case and
>> currently cant think of a simpler testcase.
>
> OK, I've found it. The ClassNotFoundException is thrown from a security
> check
> in libgcj. We are calling Method m1 from method m0, and m1's class loader
> is different from m0's class loader. We have to check that for every arg
> in m1, the actual type is the same in both m1.loader and m0.loader.
>
> The method in question is
> org.eclipse.core.runtime.Platform.getPlugin(String), which returns an
> instance of org.eclipse.core.runtime.Plugin. It gets this
> by calling org.eclipse.core.internal.plugins.PluginDescriptor.getPlugin().
>
> When we do the security check, we call Platform's class loader to ask it
> to loadClass("org.eclipse.core.runtime.Plugin") and it throws a
> ClassNotFoundException.
OK, I've discovered some more. The class loader that's throwing the
exception is a
org.eclipse.osgi.framework.internal.core.BundleLoader, and
it's being asked to find org.eclipse.core.runtime.Plugin. Now, this
is where it gets really interesting.
org.eclipse.core.runtime.Plugin is defined in
eclipse/plugins/org.eclipse.core.runtime_3.3.100.v20070530.jar,
along with a few other classes, including
org.eclipse.core.runtime.IPluginDescriptor and
org.eclipse.core.runtime.Platform.
*but*
IPluginDescriptor's class loader is not able to find
org.eclipse.core.runtime.Plugin.
Andrew.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Autobuilding packages depending on sun-java6-jdk
* Matthias Klose: > Florian Weimer writes: >> This does not work in a pristine build environment (such as one set up >> by pbuilder) because the DLJ has to be accepted, which can't work in a >> non-interactive environment. >> >> How do you cope with that? > > Preseed the debconf value. Thanks, this works reasonably well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
