I've copied the
Debian Java team list, hopefully someone there can help.
Matt
> -- Forwarded message --
> From: Milan Antonijevic
> Date: 13 October 2015 at 15:06
> Subject: A typo in the description-en of libtrilead-ssh2-java
> To: Matthew Johnson
>
>
Can you check for me that you have java-gcj-compat-headless installed,
it contains those files and that /usr/bin/java and
/etc/alternatives/java exist and look sane? the output of
update-alternatives --list java would also be useful.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
un on every build?
It looks pretty good in general though, I'm happy to upload if you at
least fix the depends.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Sun Mar 15 23:58, Damien Raude-Morvan wrote:
> On Sunday 15 March 2009 21:09:33 Matthew Johnson wrote:
> > Hi Damien, I'm looking at it now, I've got a couple of points,
Hi, sorry for the delay.
> Sounds reasonable: I've downgraded openjdk-6-jre-headless to a S
when you had openjdk to stop it taking such a long time).
Hence, the library can still be used with default-jre, it just might be
slow.
I don't mind too much though. An alternative could be to compile with
-target 1.5 to ensure you use a classfile version compatible with gcj.
Matt
--
d my package as is ?
Yes, I'll do it this evening when I've booted my pbuilder machine.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Fri Mar 20 13:47, Damien Raude-Morvan wrote:
>
> Could you upload my package as is ?
Done
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
e you've uploaded it then the debian
mirror is the canonical source of that version of the upstream tarball
anyway.
Mantt
--
Matthew Johnson
signature.asc
Description: Digital signature
a versionned jar and a plain
symlink in /usr/share/java. I'm unconvinced of the utility of this, but
it's what's recommended. javahelper also can do this for you.
Finally, please remove all the dh_ lines which are commented out if you
aren't using them.
HTH,
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
eople find it
when looking at the ML, is jarwrapper.
jarwrapper allows you to just have executable jar files on your path and
it uses the main-class, class-path and other manifest entries to run the
program.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
r with javahelper and cdbs, I didn't
> know about these...
Ditto, whether you use javahelper/cdbs (or both, there's a cdbs class
for it now) or not, you should install the jar as png-$version.jar and
then a symlink from png.jar to it.
Looking pretty good though,
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
#x27;ll do what Dominik needs, no writing of ant scripts at all
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Wed Mar 25 19:53, Onkar Shinde wrote:
> On Wed, Mar 25, 2009 at 6:33 PM, Matthew Johnson wrote:
> > On Wed Mar 25 18:17, Onkar Shinde wrote:
> >> > You still don't explicitly set which javac and jar program you are
> >> > using. You must use /usr/lib/jvm/
e identical, but someone said jh_installibs was more in
line with the dh_ command names.
It all seems to build properly. My only question, why aren't you
packaging version 2.0, which seems to be on the project page?
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
ssary if you already have someone who can
upload the package for you. I'm happy to do that since I've already
reviewed it.
If you don't want to use mentors, but do have web space elsewhere,
please upload a signed source package and send me the link to the .dsc
so I can do a final review and upload, once you are happy with the
package.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
to have a look at your two RFS tomorrow night, I
was out tonight)
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Thu Mar 26 16:14, Dominik Smatana wrote:
> Hello,
>
> On Thu, Mar 26, 2009 at 4:02 PM, Matthew Johnson wrote:
>> If you don't want to use mentors, but do have web space elsewhere,
>> please upload a signed source package and send me the link to the .dsc
>> so I
upload, but it would be good to add one in
the near future.
Uploaded
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
at I'd
do, but up to you
> Sorry, I've just uploaded my public key to subkeys.pgp.net server. Is it
> enough please? Or should I export it somewhere else too?
Aha, I have it now. Cool
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Sat Mar 28 13:56, Dominik Smatana wrote:
> On Sat, Mar 28, 2009 at 12:30 AM, Matthew Johnson wrote:
>> One small point for next time you change it, debian/copyright doesn't
>> actually give the licence of the packaging. It's been like that for a
>> while thou
., '7' or '7.0'): 1.2
BUILD FAILED
/home/mjj29/scm/debian/build/jargs-1.0.0/build.xml:22: Compile failed; see the
compiler error output for details.
Looks like the build.xml needs to be patched to have a source version higher
than 1.2
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Tue Apr 21 18:55, Onkar Shinde wrote:
> Any developers free enough for this sponsorship?
I can, if you send me the source package / a link to the dsc
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
I'm uploading rhino and tomcat-native now
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
than faff with checking things out of a repository. This
probably varies between sponsors, but I would expect everyone to be
happy with a link to a dsc.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
that's the case, you should drop the dependency. No biggie
though, I'm uploading it anyway.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Thu Apr 30 09:02, Onkar Shinde wrote:
> On Thu, Apr 30, 2009 at 4:29 AM, Matthew Johnson wrote:
> > On Wed Apr 29 10:26, Onkar Shinde wrote:
> >> I finally got time to upload it to mentors.debian.net.
> >> http://mentors.debian.net/cgi-bin/sponsor-pkglist?act
standard. I've CC'd debian-java
in case anyone there isn't reading debian-devel.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
;
>
I'm not quite sure what you mean or what such a hint would do?
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
the java.library.path Java system property.
Matt
--
Matthew Johnson
www.matthew.ath.cx
signature.asc
Description: Digital signature
27;t need to know
whether there is JNI in the implementation or not (LD_LIBRARY_PATH
not withstanding)
--
Matthew Johnson
signature.asc
Description: Digital signature
one to grok, Java experience or
not.
Jens, and anyone else who is interested in this, do you want to send me
any questions you have?
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
Hi all,
Relating to both the Eclipse stuff and the fact that I'd like to try and
improve the Java packaging policy in Debian and have booked a debconf
session to discuss it, who is still active here and interested in the
Java packaging policy? (DD or otherwise)
Matt
--
Matthew Jo
d it's build
depends, you'll just be building against the jars, which will be
compatible with either JDK. You should find the one that GDCM builds
with and explicitly use that in your debian/rules (rather than relying
on the currently installed default).
What specific error are you gettin
On Tue Jun 16 14:04, Pantelis Koukousoulas wrote:
> If some debianers help by dealing with dependencies, the job becomes
> much easier.
Can someone post a list of needed deps and URLs to tarballs?
I'll see what I can do
--
Matthew Johnson
signature.asc
Description: Digital signature
also been contacted by someone from Eclipse, to whom I offered any
help they needed in getting it to work, but I've not heard anything
back.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
ion the built SDK
In terms of dependencies, is this all built to use the
platform-installed copies of dependent libraries? Is there a list of
these anywhere?
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
icked up from there at runtime. With the additional bonus
that javahelper (or similar tools in other distros) can calculate the
dependencies on other packages automatically.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
. If you don't have anywhere to
upload it I suggest mentors.debian.net.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
RC or using SIP to conference call people in, for example.
Matt
1. http://wiki.debian.org/Java/Draft
2. http://packages.debian.org/source/squeeze/javatools
--
Matthew Johnson
signature.asc
Description: Digital signature
that openjdk probably becomes the most used JRE once 7 is out,
> would it make sense to try and improve the manifest with version
> numbering etc upstream? it might get java programmers to add this
> information for us, reducing the amount of work on our end.
Yes, once we decide on what we are doing, pushing it upstream is always
useful.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
put jh_depends? Do I need to add a common
> 'install' target?
> Any help is appreciated.
If you have javahelper 0.19 or later I supply a CDBS snippet, so you can
just:
include /usr/share/cdbs/1/class/javahelper.mk
and it will call jh_depends (and jh_exec, jh_manifest and
jh_ins
send me the logs with -v (see below) and the contents of
debian/*.substvars after the build? A source package would be even
better.
> Is it possible that jh_depends is being run at wrong time? Is there
> any way to pass -v (verbose) option to jh_depends.
Yes, set JH_DEPENDS_ARGS=-v
.
Yes, that is correct.
If the jars you are processing don't have a Class-Path attribute you can
use java-propose-classpath to suggest one (it has to be run manually as
there's no way to do so automatically) and then jh_manifest to add one.
Matt
--
Matthew Johnson
signature.as
On Thu Jul 16 22:42, Torsten Werner wrote:
> On Sun, Jul 12, 2009 at 4:47 PM, Matthew Johnson wrote:
> > I've arranged for a Debian Java BOF at Debconf this year which I know many
> > people won't be at, so I'd like to have some sort of pre-discussion first.
>
&g
modules in Java).
When it comes to glue; generally it's assumed that the same source
package will be building both the java side of the glue and the C side,
so there's no need to SONAME it for that. However, if we want parallel
installable versions of the java library, that namin
se versions
for classpaths or dependencies, which makes all the transitions either
very painful, or everyone ignores the versions and therefore you don't
get any benefit from it.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
s.html
4. http://lists.debian.org/debian-devel/2009/07/msg00861.html
5. https://edge.launchpad.net/~openjdk/+archive/ppa
--
Matthew Johnson
Index: policy.xml
===
--- policy.xml (revision 9398)
+++ policy.xml (working copy)
@@ -5,11
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
ns of themselves and contain
the unversionned symlink.
+ transitions don't need to be coordinated so much
- can't have coinstalled packages of different versions
- build-depends do change between versions
- transitions can't be binnmus
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
alwayl install the *-doc package to fulfill the
> runtime dependency?
See above, you would just need it at build time.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
t package version). This gives
us another option then:
Coinstallable packages but without symlinks
---
jars have api version in the name, there are no 'plain' symlinks and
hence no -dev packages.
+ coinstallable old versions
+ transitions don't have to be coordinated
+ no -dev packages
- transitions need build-dep / rules changes
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
we change you'll just
have to rebuild the package (see http://wiki.debian.org/Java/Packaging).
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
/Java/Packaging).
>
> thanks for the link. I will investigate with the javahelper.
> Do I have to replace the ant build by the jh_build process ?
Nope, it's just there for upstreams that don't have a nicely working
build process. If ant works, then you can just call it (or in CDBS
eport.cgi?bug=539315
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
ve not written all the supporting code is that I
don't fully understand yet how maven works.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
the
source package. You need to call ant clean in the
override_dh_auto_clean target
- *embarassed* you seem to have triggered a bug in jh_depends where it
depends on jarwrapper but not a JVM. I've fixed it and just uploaded
0.21. Once that's in I can rebuild and upload a version
fixable (trivially except for the manpage). I would
upload with them, but the error really needs to be fixed.
Other than that it all looks good.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
(to allow code exchange between me and Maven).
Sure, go ahead
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Sat Aug 08 15:18, Torsten Werner wrote:
> I don't think that is true as long as the debian dir doesn't ship java
> code that gets compiled and shipped with the binary packages.
It's part of the build system and the FSF, and others, believe that it
counts (I think)
Mat
Hi Damien,
I've reviewed the package and it looks clean, but I have one question.
Which bit is licenced under the apache-derived licence? I can only find
BSD-licenced files.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*/
--
Matthew Johnson
signature.asc
Description: Digital signature
; > it depends on jarwrapper but not a JVM. I've fixed it and just
> > uploaded 0.21. Once that's in I can rebuild and upload a version of
> > remote tea with any fixes from the above.
>
> Ok so once you answer my questions, I will trigger you to look at the
> maybe "final" version of remotetea.
Sure
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
-stable backports, I don't see any
reason why it shouldn't be the standard compat version.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
ddress, which is presumably still the same.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Wed Aug 12 11:44, Adrian Perez wrote:
> Sure it did. Uploaded to mentors, and commited at:
> svn://svn.debian.org/svn/pkg-java/trunk/azureus.
Uploaded
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
est that the
> orig.tar.gz be taken from Ubuntu [1]
Where in svn?
I'd rather if you could upload a source package somewhere for me to
check.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Thu Aug 13 10:56, Onkar Shinde wrote:
> >I'd rather if you could upload a source package somewhere for me to
> >check.
>
> Done. Package is available at
> http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=excalibur-logkit
>
Uploa
old name.
(For those in the debconf/post-debconf discussions, this is precisely
why I want to reformulate our version handling policies for Java)
Matt
--
Matthew Johnson
www.matthew.ath.cx
signature.asc
Description: Digital signature
becomes too late in this release
cycle.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
should be allowed by
d-j policy anywhere that they are allowed by normal policy.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
g dh_javadoc which looks
superfluous, since ant creates the javadoc, but also is in the package
gjdoc, which you don't depend on.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
e wants to file a bug against them and/or javahelper about this
then I'll be more likely to remember (-:
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
ava-arch.sh
is provided in jarwrapper as well as javahelper if any packages need it
at runtime.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
bundle.)
I'll happily add something like this to javahelper if it's useful.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
ad, there's always apt-get source.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
surely we can think about how we can patch
> IDEs to read them (in long term).
Yes, this is a good idea. I don't know whether this is helpful, but all
the docs should be registered with doc-base so there is a central
location for them.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
ce
improvement, but it's very useful for things like debugging and (iirc?)
eclipse completion.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
/usr/share/doc/${docpackage}/api (though it can do so by simply placing
> a symlink from ${libpackage}/api to ${docpackage}/api).
Indeed, that's what, I think, we want. It makes it easier to find if
they are in a consistent location.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
;t
like sponsoring from a git repo (for a start, I still don't know how to
get an orig.tar.gz from there)
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
e a Java Devroom at FOSDEM. Should we meet their to discuss
> > Debian-
> > Java stuff?[5]
> >
> I'm still thinking about it, but Brussels is not too far and quite nice
> for a week-end, so maybe.
I'd love to be involved in such a meeting, but spring is always
massively busy for me
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
rce form). Unless we can get a statement (from sun)
that these are also under the GPL I think they need to be stripped from
the source tarball (everything under
com/sun/electric/tool/simulation/test looks like a good bet)
I have uploaded java-gnome now though.
Matt
--
Matthew Johnson
s
an send me the source package I can probably sponsor it this
weekend.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
one the package and I'll be happy to look
over it again for you.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
s not a problem. You might
want to mention it to upstream though.
I've uploaded it
Matt
0.
libjboss-remoting-java-2.5.2.SP1/tests/org/jboss/test/remoting/transport/bisocket/BisocketImmediateShutdownTestCase.java
--
Matthew Johnson
signature.asc
Description: Digital signature
On Sat Jan 16 21:35, Onkar Shinde wrote:
> I have committed the changes in pkg-java svn. Source package is also
> available at [1] on mentors.debian.net
>
> java-gnome (4.0.14-2) unstable; urgency=low
uploaded
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Sun Jan 17 01:28, Onkar Shinde wrote:
> I have committed the change in pkg-java svn. A source package is also
> uploaded to mentors.debian.net [1]
>
> java3d (1.5.2+dfsg-5) unstable; urgency=low
uploaded
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
are/doc/$library/api, jh_installlibs will strip
the upstream version before installing if it's there and I've fixed a bug with
the dh 7 script.
It's all there in 0.27, just uploaded.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
d think that having a separate project is sensible, but certainly
coordination is a good idea.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Tue Jan 26 22:06, Miguel Landaeta wrote:
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/c/cobertura
> - Source repository: deb-src http://mentors.debian.net/debian unstable
> main contrib non-free
> - dget
> http://mentors.debian.net/debian
d this version even ignoring that, since it doesn't build
with the latest version of javahelper, as jh_build now calls javadoc by
default, so you need to pass in "--javadoc-opts=-source 1.4" (or --no-javadoc).
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
quot;
>
> If this is not clear, what's the correct thing to do? Contact
> upstream? debian-legal?
Ah, thank you, yes, this is perfectly correct, you should paste that into
debian/copyright so everyone knows what is going on (particularly the FTP
masters when they do the same review in the NEW queue)
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
der Apache 1.1, so this does not
help.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
in java5-runtime-headless and java6-runtime-headless? Do
Um, maybe. I include them all.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
d to mentors still only depend on
> java2-runtime-headless but I could add java5-runtime-headless and
> java6-runtime-headless if it's wanted.
That's fine, I've uploaded it
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
I've finally gotten around to extracting javatools and putting it in pkg-java.
You can find it at:
ssh://alioth.debian.org/git/pkg-java/javatools.git
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
ling in gcj. It should probably
be depending on default-jdk instead.
matt
--
Matthew Johnson
signature.asc
Description: Digital signature
just rotated logfile?
If it's easy to do (not significant upstream patching etc) then I'd favour the
system logrotate. Normally this works by HUPing the program to reopen it's log
files, but I don't know now log4j does this.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Sat Feb 20 13:46, Niels Thykier wrote:
> Hi
>
> I am looking for a sponsor for liboro-java.
Uploaded
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
On Sun Feb 21 12:10, Morten Sørensen wrote:
> Dear mentors,
>
> I am looking for a sponsor for the new version 122-2
> of my package "libtggraphlayout-java".
I'm in the process of uploading
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
e jars
in debian/package.jlibs and it will do everything for you. There's also support
for installing javadoc correctly, filling out depends: lines and so on.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
1 - 100 of 240 matches
Mail list logo
