thank you!
On Mon, Aug 7, 2023 at 5:18 AM Paul Wise wrote:
> On Sat, 2023-08-05 at 14:40 +0200, J.S.C. wrote:
>
> > > I just stumpled upon being unable to find libopenjfx-jni on an 64-bit
> > > ARM platform.
>
> This was fixed in libopenjfx-jni 11.0.11+1-3
On Sat, 2023-08-05 at 14:40 +0200, J.S.C. wrote:
> > I just stumpled upon being unable to find libopenjfx-jni on an 64-bit
> > ARM platform.
This was fixed in libopenjfx-jni 11.0.11+1-3.1 in Debian trixie:
https://bugs.debian.org/1021894
--
bye,
pabs
https://wiki.debian.
> Date: Sat, 5 Aug 2023 14:35:57 +0200
> From: "J.S.C."
> To: pkg-java-maintain...@lists.alioth.debian.org
> Subject: libopenjfx-jni missing for aarch64
>
> dear mainteners,
> I just stumpled upon being unable to find libopenjfx-jni on an 64-bit
> ARM plat
Hi sun min,
Le 01/06/2023 à 05:58, sun min a écrit :
Hi, Pierre,
Sorry for my late reply.
No worry, same here :)
Then this could be done in the changelog, acknowledging the issue is
solved :)
I have updated the changelog and uploaded a another one to
mentors.debian.org
Than
Hi, Pierre,
Sorry for my late reply.
Then this could be done in the changelog, acknowledging the issue is
solved :)
I have updated the changelog and uploaded a another one to mentors.debian.org
We should declare compliance with the current Standards version if it is
met, mentioning in the ch
Hi sun min,
Le 24/05/2023 à 07:39, sun min a écrit :
I have not looked at the package yet, but does the upload fix #976521
and #923440 (which should be merged, by the way)? If so, one should
mention it in the changelog.
Also, please write if changes were needed or not for the up
I have not looked at the package yet, but does the upload fix #976521
and #923440 (which should be merged, by the way)? If so, one should
mention it in the changelog.
Also, please write if changes were needed or not for the upgrade of
Standards-Version.
Cheers,
--
Pierre
Hi，Pierre:
#976521 and
or loading native libraries without
writing JNI code
libjnr-ffi-java-doc - Documentation for libjnr-ffi-java
To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/jnr-ffi/
Alternatively, you can download the package with &#
* License : Apache-2.0, Apache-2.0 or LGPL-3+
* Vcs : https://salsa.debian.org/java-team/jnr-ffi
Section : java
The source builds the following binary packages:
libjnr-ffi-java - Java library for loading native libraries without writing
JNI code
libjnr-ff
On Sun, 9 Apr 2023, Markus Koschany wrote:
>maven-compiler-plugin. Usually this just works without changes to the version
>number. I don't think a strict plugin dependency is the true solution but it
>might help future contributors to remember the RC bug.
Also not a real fix but more sustainable
Hi tony,
Am Sonntag, dem 09.04.2023 um 11:19 -0700 schrieb tony mancill:
>
> I wanted to ask you your thoughts on whether the fix should also include
> updating debian/control to strictly depend on the version(s) specified
> in the patched pom. Without some explicit declaration of dependencies,
On Sat, Apr 08, 2023 at 09:13:00PM +, Markus Koschany wrote:
> Control: tag -1 pending
>
> Hello,
>
> Bug #1034059 in zstd-jni-java reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can chec
dress this kind of bug ?
From: tony mancill on behalf of tony mancill
Sent: Friday, March 24, 2023 13:47
To: sun min
Cc: debian-java@lists.debian.org
Subject: Re: RFS: zstd-jni-java/1.5.4-2+ds-1 [Team] -- JNI bindings for Zstd
(Architecture-specific files)
Hi su
Hi sun min,
On Fri, Mar 24, 2023 at 03:01:00AM +, sun min wrote:
> Hi, all
>
> Could someone have a look at the build status of zstd-jni-java[1] ?
>
> It seems that the official build was failed while my local build is okay.
Yes, I will take a look. I also built the packa
Hi, all
Could someone have a look at the build status of zstd-jni-java[1] ?
It seems that the official build was failed while my local build is okay.
This patch "debian/patches/modify_pom.patch" defines maven-resources-plugin use
version 3.1.0, which is not the latest versin(3.3.0
Hi, tony:
I have updated all the branches of zstd-jni-java to version 1.5.4-2+ds-1 [1]
Could I leave the debian/changelog of branch master for you ?
Thanks!
[1] https://salsa.debian.org/java-team/zstd-jni-java
From: tony mancill on behalf of tony mancill
Sent
Hi, tony!
The experimental option should be more appropriate,
thanks for your update!
From: tony mancill on behalf of tony mancill
Sent: Wednesday, March 22, 2023 12:10
To: sun min
Cc: debian-java@lists.debian.org
Subject: Re: RFS: zstd-jni-java/1.5.4-2+ds-1
On Tue, Mar 21, 2023 at 01:13:35AM +, sun min wrote:
> Package: sponsorship-requests
>
> zstd-jni-java (1.5.4-2+ds-1) unstable; urgency=medium
> .
>* Team upload.
>* New upstream release.
>* Update debian/libzstd-jni1.symbols.
Hello sun min,
Should this u
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "zstd-jni-java":
* Package name : zstd-jni-java
Version : 1.5.4-2+ds-1
Upstream contact : [fill in name and email of upstream]
* URL : https://github
and
On Thu, Sep 10, 2020 at 11:41 AM tony mancill wrote:
Hello Olek,
On Wed, Sep 09, 2020 at 10:44:35AM -0400, Olek Wojnar wrote:
> Hello fellow Java developers,
>
> Has anyone been looking at packaging the JNI bindings for Zstd?
[1][2]
> Seems
Package: wnpp
Severity: wishlist
Owner: Olek Wojnar
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-java@lists.debian.org
* Package name: zstd-jni-java
Version : 1.5.0
Upstream Author : Luben Karavelov
* URL : https://github.com/luben/zstd-jni
* License
Hi All,
On Sat, Jan 2, 2021 at 12:44 AM Sudip Mukherjee
wrote:
>
> Hi All,
>
> I am seeing segfault in openjdk with a coredump when I am using the
> updated JNI libraries of swt4-gtk on ppc64el. Its happening every time
>
> Also, this will be a bug on swt4-gtk or ope
On Mon, Oct 5, 2020 at 11:17 AM Emmanuel Bourg wrote:
>
> Le 04.10.2020 23:02, Sudip Mukherjee a écrit :
> >
> > I have modified d/rules and added the version in 'dh_gencontrol' and
> > you can see it in sudip/jni branch. It now builds
> > libequinox-execut
Le 04.10.2020 23:02, Sudip Mukherjee a écrit :
I have modified d/rules and added the version in 'dh_gencontrol' and
you can see it in sudip/jni branch. It now builds
libequinox-executable-jni_3.8.900+eclipse4.17-2_amd64.deb package. Not
sure if there is some simple way to extract t
On Sun, Oct 4, 2020 at 3:03 PM Emmanuel Bourg wrote:
>
> Le 02.10.2020 18:14, Sudip Mukherjee a écrit :
>
> > Thanks. I did it in a fairly simple (hacky) way and have pushed to
> > 'sudip/jni' branch for you to have a look first.
> > It is now building '
Le 02.10.2020 18:14, Sudip Mukherjee a écrit :
Thanks. I did it in a fairly simple (hacky) way and have pushed to
'sudip/jni' branch for you to have a look first.
It is now building 'libequinox-executable-jni_4.17-2_amd64.deb' and
'libequinox-executable-jni-dbgsym_4
' but its
> > not built and packaged. I get the splash screen working when I build
> > it and use it as a launcher library. Just wanted to confirm if you
> > left it out intentionally? Is there any problem if I add it as a
> > package name "libequinox-launcher-j
s a launcher library. Just wanted to confirm if you
left it out intentionally? Is there any problem if I add it as a
package name "libequinox-launcher-jni" ?
No objection to add the jni package, but be careful with the version of
the binary package, it has to match the version of the
On Tue, Sep 29, 2020 at 5:10 PM Sudip Mukherjee
wrote:
>
> Hi Emmanuel,
>
> Is there any problem if I add it as a
> package name "libequinox-launcher-jni" ?
Sorry, it should be libequinox-executable-jni.
--
Regards
Sudip
it as a
package name "libequinox-launcher-jni" ?
--
Regards
Sudip
Hello Olek,
On Wed, Sep 09, 2020 at 10:44:35AM -0400, Olek Wojnar wrote:
> Hello fellow Java developers,
>
> Has anyone been looking at packaging the JNI bindings for Zstd? [1][2]
> Seems like a very useful piece of software and a fairly simple package. I
> didn't see an
Hello fellow Java developers,
Has anyone been looking at packaging the JNI bindings for Zstd? [1][2]
Seems like a very useful piece of software and a fairly simple package. I
didn't see anything on WNPP but I wanted to check here as well before
filing an RFP.
Thanks and I hope everyone is h
Am 20.06.20 um 11:12 schrieb Bernd Schatz:
> Hi Emanuel,
>
> Am 06.06.20 um 23:47 schrieb Emmanuel Bourg:
>> Hi Bernd,
>>
>> Le 31/05/2020 à 22:24, Bernd Schatz a écrit :
>>
>>> The libjinput-jni contains
>>> /usr/lib/jni/libjinput.so
>>>
Hi Emanuel,
Am 06.06.20 um 23:47 schrieb Emmanuel Bourg:
> Hi Bernd,
>
> Le 31/05/2020 à 22:24, Bernd Schatz a écrit :
>
>> The libjinput-jni contains
>> /usr/lib/jni/libjinput.so
>> but java is expecting it as jinput-linux64.so (on a x86_64 system).
>
> The
Hi Emmanuel,
Am 06.06.20 um 23:47 schrieb Emmanuel Bourg:
> Le 31/05/2020 à 22:24, Bernd Schatz a écrit :
>
>> The libjinput-jni contains
>> /usr/lib/jni/libjinput.so
>> but java is expecting it as jinput-linux64.so (on a x86_64 system).
>
> The code is patched to
Hi Bernd,
Le 31/05/2020 à 22:24, Bernd Schatz a écrit :
> The libjinput-jni contains
> /usr/lib/jni/libjinput.so
> but java is expecting it as jinput-linux64.so (on a x86_64 system).
The code is patched to load the library from /usr/lib/jni/libjinput.so, see:
https://salsa.debian.org/
Hi,
The libjinput-jni contains
/usr/lib/jni/libjinput.so
but java is expecting it as jinput-linux64.so (on a x86_64 system).
So a manual link is necessary
lrwxrwxrwx 1 root root 25 Mai 30 19:14 /usr/lib/jni/jinput-linux64.so ->
/usr/lib/jni/libjinput.so
Also the link to the homepage of
On Wed, Mar 27, 2019 at 06:19:14PM +0100, Thorsten Glaser wrote:
> Yes, but the output, at runtime, will match the native architecture,
> so it doesn’t matter if the i386, amd64, x32 packages are installed
> for them, or even e.g. the armel package, with qemu-user hooked up
> via binfmt-misc, the o
On Wed, 27 Mar 2019, Helmut Grohne wrote:
> * locales #669188
locales is arch:all, locales-all isn’t, and the locales you can
compile on your local system aren’t, but that’s rather a libc
issue (libc/locales aren’t M-A safe at all yet).
> * Package a shell script that calls `uname -m'. Its out
Quoting Helmut Grohne (2019-03-27 17:22:53)
> On Wed, Mar 27, 2019 at 03:24:27PM +0100, Thorsten Glaser wrote:
> > Yes, but these are all arch:all already, so unless they have not-arch:all
> > dependencies, this ought to work (I really can\u2019t think of a way to
> > implement something in arch:al
On Wed, Mar 27, 2019 at 03:24:27PM +0100, Thorsten Glaser wrote:
> Yes, but these are all arch:all already, so unless they have not-arch:all
> dependencies, this ought to work (I really can’t think of a way to
> implement something in arch:all with only arch:all dependencies that
> doesn’t work as
> On Tue, Mar 26, 2019 at 04:08:48PM +0100, Matthias Klose wrote:
> > According to http://crossqa.subdivi.de/src/openjdk-11 there is one missing
> > issue
> > to cross build OpenJDK itself (#925467, please make ant and ant-optional
> > M-A:
[…]
> https://bootstrap.debian.net/cross_all/openjdk-11.
Hi all,
Quoting Helmut Grohne (2019-03-26 17:39:48)
> On Tue, Mar 26, 2019 at 04:08:48PM +0100, Matthias Klose wrote:
> > According to http://crossqa.subdivi.de/src/openjdk-11 there is one missing
> > issue
> > to cross build OpenJDK itself (#925467, please make ant and ant-optional
> > M-A:
> >
Hi Matthias,
On Tue, Mar 26, 2019 at 04:08:48PM +0100, Matthias Klose wrote:
> According to http://crossqa.subdivi.de/src/openjdk-11 there is one missing
> issue
> to cross build OpenJDK itself (#925467, please make ant and ant-optional M-A:
> foreign). Note that the Debian tracker gives this M-
According to http://crossqa.subdivi.de/src/openjdk-11 there is one missing issue
to cross build OpenJDK itself (#925467, please make ant and ant-optional M-A:
foreign). Note that the Debian tracker gives this M-A as well.
Looking further, we should make other build systems like gradle and groovy
Hi Ole,
Le 2/01/2017 à 10:29, Ole Streicher a écrit :
> What is the best way to package a Java package that contains some JNI?
The recommended way is to put the jar in a libfoo-java package, and the
native library in a libfoo-jni package. Some projects use to embed the
native libraries ins
Hi all, and a Happy New Year!
What is the best way to package a Java package that contains some JNI?
What the original build.xml creates is
* a jar file `jniast_libs.jar` with the following content:
131 2017-01-02 10:16 META-INF/MANIFEST.MF
1869112 2017-01-02 10:16 libjniast.so
d a Debian package to use as an example. I've
found a number of ones with native libraries (.so) and many are under
/usr/lib/jni which seems like the place to put it, but I wasn't sure
it would be picked up by tomcat. I just need to test that, but first
I'm tripped up by the next iss
native libraries without writing
writing JNI code
Java Native Runtime (JNR) is a collection of Java libraries to make
interfacing with OS-level features easier. JNR uses an alternate
method to JNI or JNA to achieve programming simplicity while still
retaining performance.
The jnr-ffi package is a
then I believe you currently must do it manually.
>
> I think the issue is libswt-gtk-3-java missing the dependency, as java
> helper finds this dependency correctly.
>
> Hoping someone in debian-java can give a better insight.
>
>> ~Niels
>>
>
>
True; I over
[adding debian-java list]
On Tuesday 24 June 2014 10:14 AM, Niels Thykier wrote:
> On 2014-06-23 14:14, Praveen Arimbrathodiyil wrote:
>> package: javahelper, libswt-gtk-3-java
>> severity: important
>>
>> It is likely that libswt-gtk-3-java is missing a runtime dependency on .
>> To test this gnu
'-I/usr/lib/jvm/java-7-openjdk-amd64/jre/../include'
java libs : '-L/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server
-ljvm'
checking whether Java run-time works... yes
checking whether -Xrs is supported... yes
configure: error: Cannot compile a simple JNI
Le 06/11/2013 15:23, Mathieu Malaterre a écrit :
> severity 676618 important
> user 676618 multiarch-de...@lists.alioth.debian.org
> usertags 676618 multiarch
> thanks
>
> I am wondering if this make sense to remove /usr/lib/jni from openjdk
> and al. since we now have /us
Processing commands for cont...@bugs.debian.org:
> severity 676618 important
Bug #676618 [java-common] java-common: Update java policy for multiarch glue
lib (-jni package)
Severity set to 'important' from 'normal'
> user 676618 multiarch-de...@lists.alioth.deb
severity 676618 important
user 676618 multiarch-de...@lists.alioth.debian.org
usertags 676618 multiarch
thanks
I am wondering if this make sense to remove /usr/lib/jni from openjdk
and al. since we now have /usr/lib/$(DEB_MULTIARCH)/jni
$ cat openjdk-6-6b27-1.12.6/debian/patches/deb-multiarch
All:
I am working on updated packaging for JRuby [0] and I'm starting
with one of the depends JFFI [1]. But the current version of JRuby [2]
uses JFFI 1.2 whereas Debian currently only has 1.0.2.
So I need to update the libjffi-java and libjffi-jni packages.
The current Debian packaging
Processing commands for cont...@bugs.debian.org:
> tags 676618 patch
Bug #676618 [java-common] java-common: Update java policy for multiarch glue
lib (-jni package)
Added tag(s) patch.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
676618
tags 676618 patch
thanks
Here is an updated version of the patch
Thanks
multiarch-java2.patch
Description: Binary data
On Wed, Apr 25, 2012 at 9:53 AM, Niels Thykier wrote:
> On 2012-04-12 09:10, Mathieu Malaterre wrote:
>> [CC me pls]
>>
>> Hi there,
>>
>
> Hi,
>
>> I was able to find an example of multiarch with jni glue lib at:
>>
>> http://packages.d
=
--- policy.xml (revision 16122)
+++ policy.xml (working copy)
@@ -277,7 +277,9 @@
If a Java library relies on native code, the dynamic libraries
containing this compiled native code &should; be installed into
- the directory /usr/lib/jni. These dynamic
+
On 2012-04-12 09:10, Mathieu Malaterre wrote:
> [CC me pls]
>
> Hi there,
>
Hi,
> I was able to find an example of multiarch with jni glue lib at:
>
> http://packages.debian.org/sid/amd64/libaccess-bridge-java-jni/filelist
>
> Just to be sure, this is the new p
[CC me pls]
Hi there,
I was able to find an example of multiarch with jni glue lib at:
http://packages.debian.org/sid/amd64/libaccess-bridge-java-jni/filelist
Just to be sure, this is the new path [1] that package should use
for multiarch enabled package ? How should I go and update the
On Thu, Nov 18, 2010 at 8:59 PM, Matthias Klose wrote:
> not good. The license only allows unmodified distribution, plus it only
> "helps" when calling the "java" binary, not when starting the VM in other
> ways.
>
> Matthias
If that's the way it is, then that's it.
If the license only allows u
On 17.11.2010 17:09, Sylvestre Ledru wrote:
Le mercredi 17 novembre 2010 à 10:54 -0500, Scott Howard a écrit :
tags 382686 patch
thanks
On Sat, Nov 13, 2010 at 10:52 AM, Scott Howard wrote:
I also don't
know if a user setting LD_LIBRARY_PATH on their own overwrites our
java.library.path
Se
Le jeudi 18 novembre 2010 à 09:45 -0500, Scott Howard a écrit :
> > However, I don't see this change going in Squeeze. If you are OK, I will
> > upload your modification as soon as Squeeze is out (and also in Ubuntu).
> > This will allow us some deeper testing and potential side effects.
> >
> > Ho
> However, I don't see this change going in Squeeze. If you are OK, I will
> upload your modification as soon as Squeeze is out (and also in Ubuntu).
> This will allow us some deeper testing and potential side effects.
>
> How does it sound ?
> Sylvestre
Sounds great - I didn't expect it to get in
Le mercredi 17 novembre 2010 à 10:54 -0500, Scott Howard a écrit :
> tags 382686 patch
> thanks
>
> On Sat, Nov 13, 2010 at 10:52 AM, Scott Howard wrote:
> > I also don't
> > know if a user setting LD_LIBRARY_PATH on their own overwrites our
> > java.library.path
> >
>
> Setting LD_LIBRARY_PATH
-desktop:~$ LD_LIBRARY_PATH=/TEST java javalibraryfinder
/usr/lib/jvm/java-6-openjdk/jre/lib/amd64/server:/usr/lib/jvm/java-6-openjdk/jre/lib/amd64:/usr/lib/jvm/java-6-openjdk/jre/../lib/amd64:/TEST:/usr/java/packages/lib/amd64:/usr/lib/jni:/lib:/usr/lib
[2]
http://publib.boulder.ibm.com/in
Le vendredi 12 novembre 2010 à 09:51 -0500, Scott Howard a écrit :
> I would to revisit this bug. I agree with the debian policy decision
> to keep compiled binaries in /usr/lib/jni/, but I'm getting frequent
> bug reports and emails form users of a library I maintain telling me
>
Le vendredi 12 novembre 2010 à 09:51 -0500, Scott Howard a écrit :
> affects 382686 sun-java6-jre
> thanks
>
> I would to revisit this bug. I agree with the debian policy decision
> to keep compiled binaries in /usr/lib/jni/, but I'm getting frequent
> bug reports and
affects 382686 sun-java6-jre
thanks
I would to revisit this bug. I agree with the debian policy decision
to keep compiled binaries in /usr/lib/jni/, but I'm getting frequent
bug reports and emails form users of a library I maintain telling me
that I installed the library to the wrong locati
Thank you for the additional information you have supplied regarding
this Bug report.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will rep
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2010-09-18 12:31, Andrew Cowie wrote:
> The interdependency between libjava-gnome-java and libjava-gnome-jni is
> hard; so a >= in the versions isn't a good idea [from upstream's
> perspective]
>
Hi
(Context: see #58
Hello debian java maintainers,
The Java policy says [1]:
"If a virtual machine supports native code, it must include the
directory /usr/lib/jni in its search path for these dynamic
libraries."
openjdk6 was patched to allow looking for JNI libraries in
/usr/lib/jni in bug 517338 [2
: Java library that provide JNI code generation
HawtJNI is a code generator that produces the JNI code
needed to implement java native methods. It is based on the
jnigen code generator that is part of the SWT Tools project
which is used to generate all the JNI code which powers the
eclipse
On Thu, Aug 13, 2009 at 10:30 AM, Torsten
Werner wrote:
> Hi Onkar,
>
> On Thu, Aug 13, 2009 at 6:04 AM, Onkar Shinde wrote:
>> The java3d package has failed to build on all non-i386 platforms. I am
>> looking into build failures. It should be fixed in a day or two.
>
> default-jdk should be moved
Hi Onkar,
On Thu, Aug 13, 2009 at 6:04 AM, Onkar Shinde wrote:
> The java3d package has failed to build on all non-i386 platforms. I am
> looking into build failures. It should be fixed in a day or two.
default-jdk should be moved to Build-Depends.
Cheers,
Torsten
--
To UNSUBSCRIBE, email to
On Thu, Aug 13, 2009 at 7:51 AM, Duarte Silva wrote:
> Hi,
> first let me congratulate you for your efforts to maintain java.
> I would like to request something of you, could you add libjava3d-jni
> (AMD64) to sid?
>
> Thanks for your time.
Duarte,
The java3d package has fail
On Wed, Jul 15, 2009 at 1:37 PM, Denis Barbier wrote:
> On 2009/7/15 Mathieu Malaterre wrote:
> [...]
>> I tried:
>>
>> LD_LIBRARY_PATH="/usr/lib/jni${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
>> dh_shlibdeps -v -a -l /usr/lib/jvm/default-java/lib
> [...]
&g
On 2009/7/15 Mathieu Malaterre wrote:
[...]
> I tried:
>
> LD_LIBRARY_PATH="/usr/lib/jni${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
> dh_shlibdeps -v -a -l /usr/lib/jvm/default-java/lib
[...]
Oops, when called from a Makefile, dollar signs must be doubled, try
LD_LIBR
>> I get hundreds of:
>> ...
>> ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be
>> preloaded: ignored.
>> ...
>
> Indeed,
> LD_LIBRARY_PATH="/usr/lib/jni${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
> dpkg-shlibdeps...
>
e FTBS due to LD_PRELOAD problem...
>>
>> I meant something like
>> http://git.debian.org/?p=collab-maint/vtk.git;a=commitdiff;h=215a93c1998b88271a7a60a3fa3a6c5795ec3c6b
>
>
> I get hundreds of:
> ...
> ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_
On Wed, Jul 15, 2009 at 10:03 AM, Denis Barbier wrote:
> On 2009/7/15 Mathieu Malaterre wrote:
> [...]
>> What do you mean by altering 'LD_LIBRARY_PATH', if I explicitly export
>> this var, I get some bizarre FTBS due to LD_PRELOAD problem...
>
> I meant something like
> http://git.debian.org/?p=c
On 2009/7/15 Mathieu Malaterre wrote:
[...]
> What do you mean by altering 'LD_LIBRARY_PATH', if I explicitly export
> this var, I get some bizarre FTBS due to LD_PRELOAD problem...
I meant something like
http://git.debian.org/?p=collab-maint/vtk.git;a=commitdiff;h=215a93c1998b88271a7a60a3fa3a6
On Wed, Jul 15, 2009 at 12:45 AM, Denis Barbier wrote:
> Mathieu Malaterre wrote:
>> Hi there,
>>
>> I do not quite understand how to fix the following issue:
>>
>> dpkg-shlibdeps: error: couldn't find library libvtkCommonJava.so.5.2
>>
Mathieu Malaterre wrote:
> Hi there,
>
> I do not quite understand how to fix the following issue:
>
> dpkg-shlibdeps: error: couldn't find library libvtkCommonJava.so.5.2
> needed by debian/libvtkgdcm-java/usr/lib/jni/libvtkgdcmJava.so (ELF
> format: 'elf64
Hi there,
I do not quite understand how to fix the following issue:
dpkg-shlibdeps: error: couldn't find library libvtkCommonJava.so.5.2
needed by debian/libvtkgdcm-java/usr/lib/jni/libvtkgdcmJava.so (ELF
format: 'elf64-x86-64'; RPATH: '').
The libvtkgdcm-java use
severity 382686 important
tag 382686 + wontfix
thanks
these are binaries, and we are not allowed to ship those in modified form.
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
JNI is part of the platform and is supposed to be part of a
Java-Compatible JDK. There's nothing extra to install.
In case you need it, the reference documentation is here:
http://java.sun.com/javase/6/docs/technotes/guides/jni/index.html
- David Herron
Nilani Ganeshwaran wrote:
Generator Microsoft Word 11 (filtered medium)
Hi
I am new to Debian and using debian-etch. Could you please guide me to
setup/install jni?
Regards
Nilani
Nilani Ganeshwaran
Institutional Repository Technical Support and Software
* Grzegorz B. Prokopski [Tue, 09 Nov 2004 14:21:17 -0500]:
> I think mixing native and java code, especially in packages that are in
> main and are autobuilt on all architectures is bad idea. I'd kill
> libdcop3-java and libdcop3-jni and merge them in either qt or kde
> packag
ava library packages:
> lib{dcop,qt,kde}3-{jni,java}. the Java policy (section 2.4, last
> paragraph) states that
libdcop3-java
Installed-Size: 48 (kilobytes)
Size: 9052 (bytes)
libdcop3-jni
Installed-Size: 60
Size: 11274
libqt3-java
Installed-Size: 1512
Size: 640712
libqt3-jni
Install
the situation I'll expose.
>
> currently, kdebindings creates 6 Java library packages:
> lib{dcop,qt,kde}3-{jni,java}. the Java policy (section 2.4, last
> paragraph) states that
>
> "There may be situations, such as with very small packages, where it
>
[Please CC me on replies, M-F-T set.]
hi,
I'm seeking some advice from the Java maintainers as to what would the
best to do in the situation I'll expose.
currently, kdebindings creates 6 Java library packages:
lib{dcop,qt,kde}3-{jni,java}. the Java policy (section 2.4, last
I am unable to use the Java-Gnome glade bindings. There is suppose to be a
libglade2-jni package, just like there is a libgtk2-jni and libgnome2-jni
package. It seems in SID, libglade2-JAVA contains the JNI bindings. And in
experimental, nothing does.
Hello,
Whats the best way to split JNI libs into it's own package?
I have three arch dependend packages, which contain some small jni
libs and a binary starter. They are now part of the java packages,
which need them. This means that I need to compile all parts (slow, I
can't split t
Jeffrey Morgan wrote:
> > Actually, I reckon that the same argument applies to java-gnome in
> > general. Anyone who uses the java-gnome libraries in a GUI-based Java
> > application is risking tying that application into GNOME. By
> > contrast,
> > if they use Swing or SWT, they can easily port
On Sat, 2004-03-13 at 20:33, Momchil Velikov wrote:
> Bullshit, sorry.
Thanks for your politeness. I don't think that anything coming after
such a sentence is worth discussing.
Best regards,
Tom
Thomas Aeby, Kirchweg
t; "java-gnome" project to "gcj-gnome"? If not, stay with
Thomas> JNI, if yes, do this step with all consequences - you are
Thomas> talking about a library, then, which will not be available
Thomas> to generic Java programs/developers. One will then have to
On Thu, 2004-03-11 at 18:44, Mark Howard wrote:
> The big question is: should we switch to CNI?
Actually you already know the answer. Will you rename the "java-gnome"
project to "gcj-gnome"? If not, stay with JNI, if yes, do this step
with all consequences - you are talkin
1 - 100 of 252 matches
Mail list logo
