Processing commands for cont...@bugs.debian.org:
> reassign 983690 java-policy
Bug #983690 [java-common] Care for FAQ
Bug reassigned from package 'java-common' to 'java-policy'.
Ignoring request to alter found versions of bug #983690 to the same values
previously set
Ig
java-policy 0.57 is marked for autoremoval from testing on 2022-06-30
It (build-)depends on packages with these RC bugs:
1011146: nvidia-graphics-drivers-tesla-470: CVE-2022-28181, CVE-2022-28183,
CVE-2022-28184, CVE-2022-28185, CVE-2022-28191, CVE-2022-28192
https://bugs.debian.org/1011146
Hello everyone,
Le 29/03/2022 à 11:59, Markus Koschany a écrit :
Am Montag, dem 28.03.2022 um 21:06 -0700 schrieb tony mancill:
[...]
I am interested to hear other opinions from the Debian Java Team.
I have no objections with implementing this change and I agree that a
versionless symlink is
Am Montag, dem 28.03.2022 um 21:06 -0700 schrieb tony mancill:
> [...]
> I am interested to hear other opinions from the Debian Java Team.
I have no objections with implementing this change and I agree that a
versionless symlink is preferable for consistency reasons. The current behavior
doesn't d
s -la /usr/share/java/htmlcleaner*
> > -rw-r--r-- 1 root root 176219 23 mars 15:27
> > /usr/share/java/htmlcleaner-2.26.jar
> > lrwxrwxrwx 1 root root 20 23 mars 15:27
> > /usr/share/java/htmlcleaner.jar -> htmlcleaner-2.26.jar
>
> Many thanks for the propo
wxrwxrwx 1 root root 20 23 mars 15:27
> /usr/share/java/htmlcleaner.jar -> htmlcleaner-2.26.jar
Many thanks for the proposed patch. It seems we need a decision now on
which one is actually buggy: maven-debian-helper or java-policy. I would
vote for upholding the java-policy if only the
Hi,
> > I vaguely remember that replacing a symlink with a file during a package
> > update was causing some issues (i.e. the target is updated but the symlink
>
> Wasn’t that only for directories?
Seems to work:
$ ls -la /usr/share/java/htmlcleaner*
lrwxrwxrwx 1 root root 15 18 mars 1
On Wed, 23 Mar 2022, Emmanuel Bourg wrote:
> I vaguely remember that replacing a symlink with a file during a package
> update was causing some issues (i.e. the target is updated but the symlink
Wasn’t that only for directories?
bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
A
I vaguely remember that replacing a symlink with a file during a package
update was causing some issues (i.e. the target is updated but the
symlink isn't replaced). If that's still true I'd refrain from applying
this change to maven-debian-helper. The slight deviation from t
re fine in my opinion.
> >
> > This seems to trigger https://lintian.debian.org/tags/bad-jar-name
>
> Exactly. Thus lintian seems to follow the current Java policy and
> correctly emit warnings.
>
> I am trying to understand if this is a bug in maven-*-helper, or a
> result of
conditions that provoke Lintian's recommendations. In our
> > view, your policy [9] should be named "Java Policy for Debian."
>
>
> "Debian Policy for Java" or "Java Policy for Debian", which one is correct?
Why not "Debian Java Policy"
"Java Policy for Debian."
"Debian Policy for Java" or "Java Policy for Debian", which one is correct?
Emmanuel Bourg
Package: java-policy
Hi,
Lintian cites your manual as supporting documentation for several
tags. [1][2][3][4][5][6][7][8] Such references help users when
grasping the conditions that provoke Lintian's recommendations. In our
view, your policy [9] should be named "Java Policy for Debi
oth styles are fine in my opinion.
>
> This seems to trigger https://lintian.debian.org/tags/bad-jar-name
Exactly. Thus lintian seems to follow the current Java policy and
correctly emit warnings.
I am trying to understand if this is a bug in maven-*-helper, or a
result of overly strict policy. One of these should be changed.
Best,
Andrius
Hi,
> > Not sure though what is the impact of this policy inversion. Most of
> > Java-related software seems to read both regular files and symbolic
> > links transparently.
>
> There isn't much impact, both styles are fine in my opinion.
This seems to trigger https://lintian.debian.org/tags/bad
Le 15/10/2021 à 15:17, Andrius Merkys a écrit :
> Not sure though what is the impact of this policy inversion. Most of
> Java-related software seems to read both regular files and symbolic
> links transparently.
There isn't much impact, both styles are fine in my opinion.
Emmanuel Bourg
Hi Markus,
On 2021-10-15 14:34, Markus Koschany wrote:
> Indeed, that looks like a bug in libcommons-lang3-java or rather maven-debian-
> helper to me. I have just checked some other Maven packages and there the
> policy is implemented correctly. The bug in libcommons-lang3-java could be
> related
Hello,
Am Freitag, dem 15.10.2021 um 12:41 +0300 schrieb Andrius Merkys:
> Hello,
>
> Java policy on Java libraries (Ch. 2.4.) reads [1]:
>
> Their classes must be in jar archive(s) in the directory /usr/
> share/java, with the name packagename[-extraname]
>
Hello,
Java policy on Java libraries (Ch. 2.4.) reads [1]:
Their classes must be in jar archive(s) in the directory /usr/
share/java, with the name packagename[-extraname]
-fullversion.jar. The extraname is optional and used internally
within the package to separate the different
Your message dated Mon, 27 Jul 2020 12:19:37 +
with message-id
and subject line Bug#966303: fixed in java-policy 0.57
has caused the Debian Bug report #966303,
regarding java-policy: Please specify the reference more precisely
to be marked as done.
This means that you claim that the problem
Processing control commands:
> tag -1 pending
Bug #966303 [java-policy] java-policy: Please specify the reference more
precisely
Added tag(s) pending.
--
966303: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966303
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Hi Emanuel,
Thanks for your reply.
On Tue, 2019-01-22 at 09:17 +0100, Emmanuel Bourg wrote:
> Hi Bill,
>
> Le 22/01/2019 à 01:09, Bill Zaumen a écrit :
>
> > the following commands will cause java to crash:
> >
> > java -p /usr/share/java --list-modules
> > java -p /usr/share/java --
Hi Bill,
Le 22/01/2019 à 01:09, Bill Zaumen a écrit :
> the following commands will cause java to crash:
>
> java -p /usr/share/java --list-modules
> java -p /usr/share/java --describe-module MODULE
I don't think this is a use case we can reasonably support. Even if
there were no sy
The Debian java policy appears to need some clarification regarding
how to handle modular jar files. A few things don't work the way
one might expect with Java 11 (the default jdk on my system).
1. If you create a file with a version string such as
libfoo-1.1.0.jar and symbolic
On Tue, 22 Sep 2015, Markus Koschany wrote:
>
> I think we can drop lynx from Build-Depends since it is commented out
> anyway and I would remove Thorsten Werner from Uploaders.
I agree, this important package for the team (and the project) should
have an up-to-date list of Uploaders. I guess Emm
Am 23.09.2015 um 09:53 schrieb Emmanuel Bourg:
> I pushed the java-policy package on Alioth [1], reviews are welcome.
> I'll remove the policy from java-common once the java-policy package is
> in unstable.
I think we can drop lynx from Build-Depends since it is commented out
anyw
I pushed the java-policy package on Alioth [1], reviews are welcome.
I'll remove the policy from java-common once the java-policy package is
in unstable.
Emmanuel Bourg
[1] http://anonscm.debian.org/cgit/pkg-java/java-policy.git
h a move. Will the Java Team be able to
> easily amend the Java policy if it's tied to the general debian-policy?
> Can we still publish updates of the Java policy independently of the
> debian-policy? Will we have to debate about changes on the debian-policy
> list?
I think we shoul
Le 22/09/2015 13:49, Thorsten Glaser a écrit :
> It’s 56K installed, the overhead is probably too big.
To be exact, it's 172K with the .ps .txt and .xml versions in
/usr/share/doc/java-common, and 260K if you include the FAQ.
Emmanuel Bourg
On Tue, 22 Sep 2015, Emmanuel Bourg wrote:
> > Can’t you get it merged into the normal debian-policy package?
>
> Good question, and that would probably close #395374, but I'm unsure
> about the implications of such a move. Will the Java Team be able to
> easily amend
but I'm unsure
about the implications of such a move. Will the Java Team be able to
easily amend the Java policy if it's tied to the general debian-policy?
Can we still publish updates of the Java policy independently of the
debian-policy? Will we have to debate about changes on the debian-policy
list?
Emmanuel
On Tue, 22 Sep 2015, tony wrote:
> in the archive. We may want to iterate over policy frequently, and do
> so without triggering upgrades for every installed copy of java-common.
Hmm. But in that case you also must split the source package.
Just saying.
Can’t you get it merged into the normal d
Le 22/09/2015 17:13, tony a écrit :
> It would also be nice if the policy package was named something
> obvious, like java-policy. :)
Actually I was thinking about something like
"somewhat-normative-best-practices-collection-for-java-packages", but
your suggestion is shorter :)
Emmanuel
We may want to iterate over policy frequently, and do
so without triggering upgrades for every installed copy of java-common.
In that case, a separate package may take a bit more disk on the
mirrors, but it could also result in less overall network bandwidth.
It would also be nice if the poli
Le 22/09/2015 16:44, Markus Koschany a écrit :
> I agree with Thorsten that this would imply a packaging overhead for
> only a little gain. Although I think that splitting the documentation
> would be cleaner, it is probably not worth the effort for a few KB. No
> strong preferences from my side t
Am 22.09.2015 um 13:02 schrieb Emmanuel Bourg:
[...]
> What do you think?
I agree with Thorsten that this would imply a packaging overhead for
only a little gain. Although I think that splitting the documentation
would be cleaner, it is probably not worth the effort for a few KB. No
strong prefere
ages
> - the Java FAQ
>
> Including the Java policy in java-common is a bit odd, it means Java
> users automatically gets the policy documents on their systems, but this
> is only useful to people doing actual packaging work. I suggest moving
> it to a separate java-policy package. The
On Tue, 22 Sep 2015, Emmanuel Bourg wrote:
> What do you think?
It’s 56K installed, the overhead is probably too big.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT
Hi all,
The src:java-common package currently contains:
- the default-jre/jdk meta packages defining the default Java per
architecture
- the update-java-alternatives mechanism
- the packaging policy for Java packages
- the Java FAQ
Including the Java policy in java-common is a bit odd, it means
Hi,
2015-07-07 22:41 GMT+02:00 Emmanuel Bourg :
> Sorry for the lack of reply, I would recommend posting your next RFS on
> the debian-java list instead, you'll get more reviews here. I'll get a
> look at your package.
Thanks again for your first feedback on
https://bugs.debian.org/cgi-bin/bugrep
On 07/07/2015 01:13 PM, Guillaume Turri wrote:
> 2015-07-07 15:26 GMT+02:00 tony mancill :
>> On 07/07/2015 04:15 AM, Emmanuel Bourg wrote:
>>> Le 06/07/2015 06:36, tony mancill a écrit :
>>>
This warning is useful because
some components of the Debian Java toolchain fail when JAR files d
Le 07/07/2015 22:13, Guillaume Turri a écrit :
> By the way, quick question -since I submitted a RFS [2] for axmlrpc,
> and got not reply yet-:
Hi Guillaume,
Sorry for the lack of reply, I would recommend posting your next RFS on
the debian-java list instead, you'll get more reviews here. I'll g
2015-07-07 15:26 GMT+02:00 tony mancill :
> On 07/07/2015 04:15 AM, Emmanuel Bourg wrote:
>> Le 06/07/2015 06:36, tony mancill a écrit :
>>
>>> This warning is useful because
>>> some components of the Debian Java toolchain fail when JAR files don't
>>> comply with the naming policy.
>>> [...]
>
>
For my understanding, what are the tools relying on this naming policy?
> I'm asking because I'm pretty sure many packages don't strictly adhere
> to the Java policy on this point (for example liblog4j1.2-java vs
> /usr/share/java/log4j-1.2.jar) and I'm not under
because I'm pretty sure many packages don't strictly adhere
to the Java policy on this point (for example liblog4j1.2-java vs
/usr/share/java/log4j-1.2.jar) and I'm not under the impression it's
causing such a havoc.
Emmanuel Bourg
--
To UNSUBSCRIBE, email to debian-java-req
Package: lintian
Version: 2.5.31
Severity: wishlist
Dear Maintainer,
Please consider adding the attached check for JAR names that are
compliant with the Debian Java Policy. This warning is useful because
some components of the Debian Java toolchain fail when JAR files don't
comply wit
Your message dated Mon, 05 Aug 2013 16:33:25 +
with message-id
and subject line Bug#687841: fixed in java-common 0.49
has caused the Debian Bug report #687841,
regarding java-common: [Policy] please explicitly state copyright and license
in Java Policy
to be marked as done.
This means that
Your message dated Sat, 09 Feb 2013 11:18:14 +0100
with message-id <51162266.1030...@zorglub.s.bawue.de>
and subject line Re: Bug#698164: Info received (Bug#698164: mandate unique
package names in Debian Java policy)
has caused the Debian Bug report #698164,
regarding mandate unique package
On Sat, Jan 26, 2013 at 11:28 AM, Wolodja Wentland wrote:
> On Fri, Jan 25, 2013 at 15:56 -0300, Miguel Landaeta wrote:
>
> There are not many Clojure libraries and I still prefer a $LANG-$LIBRARY
> naming
> scheme as is used by, for example the Python team. But then there are
> numerous examples
On Fri, Jan 25, 2013 at 15:56 -0300, Miguel Landaeta wrote:
> Some days ago I noticed a new package queued at NEW named
> libtools-macro-clojure[1] and that reminded me about how I don't
> remember about any discussion or some formal document with a
> description about how library packages of JVM l
Hi folks,
Some days ago I noticed a new package queued at NEW named
libtools-macro-clojure[1] and that reminded me about how I don't
remember about any discussion or some formal document with a
description about how library packages of JVM languages like Scala,
Clojure, Groovy and others should be
On 16/01/13 09:05, Eric Lavarde - Debian wrote:
> Hi,
>
> Daniel Pocock said:
>>> B. I doubt that such a badly named package would be of enough interest /
>>> quality for Debian packaging (but I might be wrong, I don't know any
>>> example)
>>
>> There are examples like this. It has been argued
Hi,
Daniel Pocock said:
>> B. I doubt that such a badly named package would be of enough interest /
>> quality for Debian packaging (but I might be wrong, I don't know any
>> example)
>
> There are examples like this. It has been argued by some developers
> that to compile using some toolchains (
es concurrently on a single system, I would contend that we should
>>> mandate the use of this "suggestion"
>>> http://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#d5e6504
>>
>> The package domain is a decision of upstream, not of the packager, hence
&
use of this "suggestion"
>> http://docs.oracle.com/javase/specs/jls/se7/html/jls-6.html#d5e6504
>
> The package domain is a decision of upstream, not of the packager, hence
> I don't think that such recommendation has its place in the Java policy:
> 1. it doesn&#x
/se7/html/jls-6.html#d5e6504
The package domain is a decision of upstream, not of the packager, hence
I don't think that such recommendation has its place in the Java policy:
1. it doesn't create any collision in terms of packaging
2. it might create collision in terms of using two such li
ain is a decision of upstream, not of the packager, hence
I don't think that such recommendation has its place in the Java policy:
1. it doesn't create any collision in terms of packaging
2. it might create collision in terms of using two such libraries BUT
a. developers using two such li
Package: java-common
Severity: important
Version: 0.47
I just had a read over the policy
http://www.debian.org/doc/packaging-manuals/java-policy/
One thing not mentioned is the use of namespaces/package names in Java
The vast majority of projects use unique namespaces, specifically, using
a
//www.debian.org/doc/packaging-manuals/java-policy/index.html
[2]
http://packages.debian.org/changelogs/pool/main/j/java-common/current/copyright
[3] http://www.debian.org/doc/debian-policy/
[4] http://www.debian.org/doc/packaging-manuals/python-policy/
--
To UNSUBSCRIBE, email
On 08/04/2012 01:48 PM, Vincent Fourmond wrote:
> Hi,
>
> On Sat, Aug 4, 2012 at 4:37 PM, Damien Raude-Morvan
> wrote:
>>> Le 04/08/2012 09:59, Thomas Koch a écrit :
>>>> do you think we should change the java policy and relax the requirement
>>>>
Hi,
On Sat, Aug 4, 2012 at 4:37 PM, Damien Raude-Morvan wrote:
>> Le 04/08/2012 09:59, Thomas Koch a écrit :
>>> do you think we should change the java policy and relax the requirement
>>> to
>>> install java libraries to /usr/share/java in favour of
>>&g
Le 04/08/2012 10:10, Sylvestre Ledru a écrit :
Le 04/08/2012 09:59, Thomas Koch a écrit :
Hi,
do you think we should change the java policy and relax the requirement to
install java libraries to /usr/share/java in favour of /usr/share/maven-repo?
At least I'd like to see a very s
Le 04/08/2012 09:59, Thomas Koch a écrit :
> Hi,
>
> do you think we should change the java policy and relax the requirement to
> install java libraries to /usr/share/java in favour of /usr/share/maven-repo?
>
> At least I'd like to see a very strong recommends to install
Hi,
do you think we should change the java policy and relax the requirement to
install java libraries to /usr/share/java in favour of /usr/share/maven-repo?
At least I'd like to see a very strong recommends to install to /u/s/m-r. I
feel like having filled a dozen bugs against java libr
reassign 553619 java-common
thanks
Le Sun, Nov 01, 2009 at 04:46:56PM +0200, Tom Feiner a écrit :
> Subject: debian-policy: include java policy
> Package: debian-policy
> Version: 3.8.3.0
> Severity: wishlist
>
> Currently, the java policy is provided as part of the jav
Processing commands for cont...@bugs.debian.org:
> reassign 553619 java-common
Bug #553619 [debian-policy] debian-policy: include java policy
Bug reassigned from package 'debian-policy' to 'java-common'.
No longer marked as found in versions debian-policy/3.8.3.0.
Ignoring
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
Package: java-common
Version: 0.40
Severity: normal
Please consider applying the attached patch for the debian java policy
-- System Information:
Debian Release: 6.0.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (200, 'te
Your message dated Mon, 16 Aug 2010 08:30:02 +0200
with message-id <4c68daea.3060...@thykier.net>
and subject line java-package: generated package should provide java1-runtime
has caused the Debian Bug report #354026,
regarding Debian Java Policy needs to be updated regarding java*-runtime
Your message dated Sun, 11 Apr 2010 16:21:15 +0200
with message-id <4bc1dadb.2090...@thykier.net>
and subject line java-common: JAVA POLICY: define default
JAVA_HOME=/usr/lib/java as alternative.
has caused the Debian Bug report #283557,
regarding java-common: JAVA POLICY: define d
Your message dated Sun, 11 Apr 2010 14:01:03 +0200
with message-id <4bc1b9ff.1000...@thykier.net>
and subject line Re: [Java Policy] no dependencies on real java versions
has caused the Debian Bug report #228532,
regarding [JAVA POLICY] No upgrade when sablevm is alternatvie for /usr/bin/j
Your message dated Sun, 11 Apr 2010 14:01:03 +0200
with message-id <4bc1b9ff.1000...@thykier.net>
and subject line Re: [Java Policy] no dependencies on real java versions
has caused the Debian Bug report #228532,
regarding [JAVA POLICY] can't find working java on install when JAVA_HOME
tony mancill wrote:
> Niels Thykier wrote:
>
>> Change 3:
>> -
>> Finally doc packages were set to a Recommends rather than a Depends. The
>> exact wording was changed to:
>
>> The API &must; be place in a separate doc package. This package
>> &must; recommend the doc packages i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Niels Thykier wrote:
> Change 3:
> -
> Finally doc packages were set to a Recommends rather than a Depends. The
> exact wording was changed to:
>
> The API &must; be place in a separate doc package. This package
> &must; recommend
Hi
I have just applied and committed the patches to the SVN with the
following changes.
Change 1:
-
Corrected typo reported by Pablo Duboue in the gcj patch (Message ID
<201003300143.06669.pablo.dub...@gmail.com>).
Change 2:
-
The parts about tests were rephrased to:
Programs
On Sunday 28 March 2010, Niels Thykier wrote:
> Hi
>
> I just had a conversation with Damien Raude-Morvan and Matthew Johnson
> about the strict dependencies between javadoc packages. We considered
> lowering the requirement from a Depends to a Recommends.
>
> The rationale is that the javadoc is
Hi
I just had a conversation with Damien Raude-Morvan and Matthew Johnson
about the strict dependencies between javadoc packages. We considered
lowering the requirement from a Depends to a Recommends.
The rationale is that the javadoc is functional even without the docs it
links too and it allows
Damien Raude-Morvan wrote:
> Hi Niels,
>
> Le vendredi 26 mars 2010 22:15:18, Niels Thykier a écrit :
>> How do these suggestions sound?
> [...]
>> Programs and libraries &should; enable JUnit tests,
>> if these are present. The build &may; ignore test
>> failures.
>
> This one is fine for
Hi,
Niels Thykier wrote:
Eric Lavarde wrote:
Vincent Fourmond wrote:
On Fri, Mar 26, 2010 at 5:47 PM, Eric Lavarde wrote:
one more thing: we could actually also get rid of all javaX-runtime
where X
< 6, or is there any package left in Debian that provides only less than
java6?
Package: gcj-
Niels Thykier wrote:
> I will just give a quick summery, in case you lost the overview of this
> debate.
>
> Currently there are three patches active:
> * p1_trival_changes.patch
Applied and committed to the SVN.
> * p2_fosdem06_r3.patch
No change here (yet). The JUnit phrase needs to be modi
Hi Niels,
Le vendredi 26 mars 2010 22:15:18, Niels Thykier a écrit :
> How do these suggestions sound?
[...]
> Programs and libraries &should; enable JUnit tests,
> if these are present. The build &may; ignore test
> failures.
This one is fine for me.
--
Damien Raude-Morvan - http://www.d
Vincent Fourmond wrote:
> On Fri, Mar 26, 2010 at 11:33 AM, Matthew Johnson wrote:
>>> I think we are missing the point here; for instance, I've mostly
>>> disabled junit tests because they depend on not-yet-packaged or even
>>> non-DFSG-free libraries. I think both formulations are too oriented
Eric Lavarde wrote:
> Vincent Fourmond wrote:
>> On Fri, Mar 26, 2010 at 5:47 PM, Eric Lavarde wrote:
>>> one more thing: we could actually also get rid of all javaX-runtime
>>> where X
>>> < 6, or is there any package left in Debian that provides only less than
>>> java6?
>>
>> Package: gcj-4.4-j
Vincent Fourmond wrote:
On Fri, Mar 26, 2010 at 5:47 PM, Eric Lavarde wrote:
one more thing: we could actually also get rid of all javaX-runtime where X
< 6, or is there any package left in Debian that provides only less than
java6?
Package: gcj-4.4-jre
Provides: java-runtime, java1-runtime,
Le vendredi 26 mars 2010 21:21:05, Vincent Fourmond a écrit :
> On Fri, Mar 26, 2010 at 5:47 PM, Eric Lavarde wrote:
> > one more thing: we could actually also get rid of all javaX-runtime where
> > X < 6, or is there any package left in Debian that provides only less
> > than java6?
>
> Package:
On Fri, Mar 26, 2010 at 5:47 PM, Eric Lavarde wrote:
> one more thing: we could actually also get rid of all javaX-runtime where X
> < 6, or is there any package left in Debian that provides only less than
> java6?
Package: gcj-4.4-jre
Provides: java-runtime, java1-runtime, java2-runtime, java5-r
Hi,
one more thing: we could actually also get rid of all javaX-runtime
where X < 6, or is there any package left in Debian that provides only
less than java6?
Backport might be a concern, but then sun-java5 is not present in older
versions than sun-java6, so...
Eric
--
To UNSUBSCRIBE, e
Hello,
Matthew Johnson wrote:
But, from your patches, I understand that javaX-runtime survives and
that we add default-jre/jdk (default-j) into the picture, which,
depending on the platform, provides either cp-j or java-j, because they
pull gcj-j or openjdk-j.
IMO javaX-runtime should be
hing I've to take care of, what a unit test may not do on a
> build server? Like accessing the internet, connecting to localhost?
You certainly can't rely on internet access and starting any kind of local
server is a little dodgy, particularly if it doesn't do random port selecti
There are two questions I had about Debian-Java unit tests and which I propose
to answer in the policy:
- Is there any time limit, how long unit test suites may take?
- Is there anything I've to take care of, what a unit test may not do on a
build server? Like accessing the internet, connectin
On Fri, Mar 26, 2010 at 11:33 AM, Matthew Johnson wrote:
>> I think we are missing the point here; for instance, I've mostly
>> disabled junit tests because they depend on not-yet-packaged or even
>> non-DFSG-free libraries. I think both formulations are too oriented
>> towards: "junit tests sho
On Fri Mar 26 11:24, Vincent Fourmond wrote:
> > Programs and libraries &should; enable JUnit tests, if these are present.
> > *However, these tests &should; not lead to build failures unless
> > Maintainer is confident enough that tests are stable between builds*
>
> I think we are missing th
Hello,
On Fri, Mar 26, 2010 at 10:56 AM, Damien Raude-Morvan
wrote:
> Programs and libraries &should; enable JUnit tests, if these are present.
> *However, these tests &mustnot; lead to build failures.*
>
> For some library packages (ie. commons-maths), I'm confidence enough to
> enable unit
Hi,
On Thu, 25 Mar 2010 21:32:50 +0100, Niels Thykier
wrote:
> Currently there are three patches active:
> * p1_trival_changes.patch
> * p2_fosdem06_r3.patch
> * p3_fosdem06-gcj.patch
I'm OK with all three patches, except one small addition from
"p2_fosdem06_r3.patch" :
Programs and librari
On Fri Mar 26 09:42, Eric Lavarde wrote:
> Hi Niels,
>
> I have some problems to understand the resulting document, not knowing
> what the baseline is, but after reading through the patches, I think
> that the new policy doesn't address the main problem which is the fact
> that we have 2 inco
et values corresponding to this X.
Even less important, a typo in the GCJ patch:
A request for permission to add gcj should packages should convince the
Java Team that [...]
(the "should packages" is probably too much)
Participating to my confusion: I'm not sure where in the
I will just give a quick summery, in case you lost the overview of this
debate.
Currently there are three patches active:
* p1_trival_changes.patch
* p2_fosdem06_r3.patch
* p3_fosdem06-gcj.patch
I just noticed that my email client have behaved weirdly when I sent the
last two and have made all
Matthias Klose wrote:
> On 23.03.2010 10:26, Niels Thykier wrote:
>> Hi
>>
>> I have compiled two patches against the current policy that I intend to
>> apply Friday assuming there are no objections.
>
> mentioning default-jdk-doc would be useful.
>
>
It is mentioned once:
Java library packa
I have decided to extract the GCJ part into its own patch. I have
created an interdiff between the last and the current version of the
fosdem06 patch. I would have made an interdiff for the GCJ part as well,
but it failed.
Matthias Klose wrote:
> On 23.03.2010 11:54, Niels Thykier wrote:
>> Sylves
1 - 100 of 740 matches
Mail list logo
