-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Onkar Shinde wrote:
> and dom4j on pkg-java svn checkout are taking up approx 85MB and 82MB
> of space. These folders contain source and/or documentation for
> respective packages.
> Is this intentional?
Yes. That was an experiment with an alternativ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Onkar Shinde wrote:
> So are you going to remove these files from svn?
They are used to build the packages. But feel free if you want to
convert back to the usual layout.
(dom4j is quite inactive upstream, I think, and tomcat5.5 should be
going away,
Hi,
now that tomcat6 is in Debian, I think it is time to retire tomcat5.5. The
tomcat6 packagers have done a very good job and the packages seem to work
well from my limited testing. Clearly we do not have enough manpower to fix
the outstanding bugs even in the tomcat5.5 packages, so I don't se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Emmanuel Bourg wrote:
> I reviewed the files in SVN and build a patch to reflect
> the change. I also updated the information about former Jakarta projects
> that moved to their own top level project (Velocity and Struts)
Thanks a lot!
> Could someon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ludovic Claude wrote:
> I am looking for a sponsor for my package "jetty6".
Nice, it is badly needed.
> The upload would fix these bugs: 425152, 454529, 458399, 498582, 527571,
> 528389, 530720
No it wouldn't. Those are filed against the "jetty" pac
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Johnson wrote:
> who is still active here and interested in the Java packaging policy?
I am... And BTW if anyone feels they have stopped being active, please drop
a line so we can keep an eye on your packages.
Cheers,
Marcus
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Markus and James,
the Java team is certainly in need of more manpower so any help is
appreciated. There are a lot of tasks, just check the BTS [1] and pick one
:) However regarding Eclipse packaging, I don't think there are any small
tasks that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Johnson wrote:
> 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?
And then maybe som
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ludovic Claude wrote:
> Thanks for your suggestions. I have uploaded a new version of jetty into
> mentors.d.o, plus a new version of tomcat6 which contains a little
> packaging change used by jetty.
Great (but someone else will have to sponsor since
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Emmanuel Bourg wrote:
> Reposting to debian-java if someone can look at this there.
Applied, thanks.
Cheers,
Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpA5PUACgkQXjXn6TzcAQm8AQCbBGQf/w/H1JpTV8o47Y0TuC3E
Tl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Emmanuel Bourg wrote:
> What happens to the bugs I filed regarding the invalid license?
Oh, I forgot about those. I will add the necessary changelog entries.
> Should the components be repackaged and uploaded before marking the bugs as
> fixed?
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Emmanuel Bourg wrote:
> I don't want to step on anyone's feet, but may I put the updated
> packages on mentors.debian.net and request for a sponsor to upload it?
In general only people listed as Maintainer or Uploader should do that.
Otherwise you sho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Johnson wrote:
> Separate -dev packages
> --
>
> The heavy-weight approach that is most like C and relies on the package
> manager a lot.
>
> + build-depends don't change between versions
By this you mean we build-depend
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Torsten Werner wrote:
> How do I find out if the API has changed in a new upstream version?
Well, that is never easy, also not with C libraries if upstream is clueless.
If you are lucky, upstream is responsible enough to document it. Otherwise
it ma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ludovic Claude wrote:
> I have recently packaged the clirr tool which does exactly that: give it
> 2 versions of a jar, and it will report any API breaking changes.
Nice, looks useful, but note that it only detects visible API changes, not
more subtl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Johnson wrote:
>> By this you mean we build-depend on a virtual package like libfoo-dev,
>> which is Provided by libfoo0-dev, libfoo1-dev and so on?
> Well, there's two ways of doing this in C libraries. Some provide
> versionned -dev packages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jan-Pascal van Best wrote:
> I've received a request (see below) to move the packaging of solr to a
> git repository.
Just FYI: I use git+TopGit for packaging testng, you may "debcheckout" it
if you want to have a look. Works pretty well so far. (Ad
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sune Vuorela wrote:
> I'm puzzled it isn't more packages than that. Last I tried building it,
> maven ended up downloading ~100 jars totally filling ~28mb where only a
> few of them was available in debian.
>
> Or are the build process just downloadi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Andreas Tille wrote:
> I found out that the antlib.xml file is not part of the Debian package
It is, but earlier versions omitted it (#524878).
Cheers,
Marcus
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkrEfm8ACgkQ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher Bertels wrote:
> I was just wondering, if there is any interest at all to include the
> packages into Debian?
I'm interested but not sure when I can squeeze in some time to check the
packages.
Cheers,
Marcus
-BEGIN PGP SIGNATURE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Koch wrote:
> - Should all java stuff be repackaged? For example the xmlenc upstream
> tarball contains only one jar and some docs. I could as well have removed
> these files during package building.
You must remove any jars that are not built
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Koch wrote:
> Now I saw, that in the eclipse GIT repository[3] there's one tag
> upstream/3.5.1 and another one upstream/3.5.1+repack. I don't know,
> whether the eclipse package is doing so, but we could standardize on:
>
> - import the upstre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
reassign 560142 openjdk-6
forcemerge 560056 560142
thanks
> So somehow Java started to use IPv6 yesterday. Is this connected with the
> change in the "netbase" package?
Yes, looks like it. Not sure which JRE you use, but it affects both
OpenJDK and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Koch wrote:
> I'm not experienced enought with eclipse to know, whether such a setup
> would make sens for eclipse too. However what surely makes sense, would be
> the ability to install plugins not only as debian packages, but also via
> the ec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Alan Greenberger wrote:
> So it is a java futex problem always showing up on printing and
> triggered by iceweasel but not konqueror. It wasn't happening on
> Lenny-slow in March. Does anyone have an idea what I could have done to
> this system
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Onkar Shinde wrote:
>> Would it be useful to have PACKAGE-dev packages for java containing the
>> source code, so that I can refer to it when developing on top of a
>> library?
>
> Ideally you shouldn't refer to source code of libraries for writing
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Koch wrote:
> The ivy thing will of course be patched out and replaced by the correct
> classpath entries to /usr/share/java/...
No need. Ivy is already in Debian, and many packages provide Maven metadata.
The Ivy config just needs to be tweak
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Koch wrote:
> Ivy spits some errors on me, already asked upstream for help[2], but maybe
> someone of you could also help.
I don't think the "master" configuration is supported by our Maven
repository. You would need proper Ivy metadata, since
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[CC gradle-devel]
Torsten Werner wrote:
> Cc-ing the debian-java list now. This message is about packaging
> gradle and gant for Debian and Ubuntu.
>
> On Sat, Feb 13, 2010 at 9:41 AM, Russel Winder
> wrote:
>> So to get Gradle into Debian it seems
Hi,
I am the author of "Ganymed SSH-2 for Java" and would like to point you
to the new build 250 available at http://www.cleondris.ch/ssh2/
Thanks. I've filed a wishlist bug for this, but I don't have resources
to do the work at the moment.
Cheers,
Marcus
--
To UNSUBSCRIBE, email to debi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
since some time (weeks, or a couple of months at most) my Eclipse 3.5.1
cannot contact any update sites whatsoever. It complains about connections
failing with "invalid argument".
The strange thing is that I tried with both settings of net.ipv6
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Niels Thykier wrote:
>> While I'm at it: how would the maintainers feel about converting this
>> package to use quilt?
+1.
> I am not sure about Marcus Better,
Hello :) I'm active, but lost interest in commons-daemon
On 2010-07-22 23:15, Torsten Werner wrote:
On Wed, Jul 21, 2010 at 8:08 PM, Marcus Better wrote:
I worked on it together with the Tomcat packages, but our Tomcat doesn't use
commons-daemon anymore (a mistake if you ask me).
I am asking you. What is the mistake?
Tomcat is prone to ha
Robert Schuster wrote:
> first: I think this discussion fits better on the debian-java list. :)
Why? It's about specific policies listed on the pkg-java web pages.
> As far as I understood it you should do the 'repackaging' programmatically.
> Put
> every needed operation to make the upstream so
Arnaud Vandyck wrote:
> pkg-java-maintainers is for the bug reports, not for the discussions. We
> have to comment that on the website.
Yes, and change the instructions on
http://pkg-java.alioth.debian.org/developers.html which say that new
developers should send a message to pkg-java-maintainers
Do I have SVN access to the pkg-java repository? I'm having difficulties
importing the code.
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Marcus Better wrote:
> Do I have SVN access to the pkg-java repository? I'm having difficulties
> importing the code.
It's working now for some reason.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hello,
I am looking for a sponsor for my package "nekohtml".
-
* Package name : nekohtml
Version : 0.9.5
Upstream Author : Andy Clark
* URL or Web page : http://people.apache.org/~andyc/neko/doc/html/
* License : CyberNeko Software License, V
Hello,
the pkg-jboss project needs DFSG-free versions of Sun's JavaMail and Java
Activation Framework libraries. Can anyone tell me whether the GNU versions
(already in Debian) will work out of the box?
Thanks,
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscri
Second attempt: Anyone willing to sponsor this please?
Marcus Better wrote:
> Hello,
>
> I am looking for a sponsor for my package "nekohtml".
>
> -
> * Package name : nekohtml
> Version : 0.9.5
> Upstream Author : And
Matthias Klose wrote:
> what do you mean by "out of the box"?
Sorry for being unclear. Can the classpathx versions work as drop-in
replacements for the Sun packages?
(JBoss contains jar files for JavaMail 1.3.1 and JAF 1.0.2. I intend to
replace them with the ones from classpathx.)
Marcus
--
Arnaud Vandyck wrote:
> Why did you put the original tarball in subversion?
It needed to be repackaged (upstream contained binaries). So the tarball
needs to be stored somewhere, to enable collaborative development. This
location was suggested by Russ Allbery:
http://www.eyrie.org/~eagle/notes/d
Tom Marble wrote:
> Why not use Sun's JavaMail and JAF?
It seems that the CDDL is not considered sufficiently free for Debian. At
least that's what I gathered from the lengthy discussions on mailing lists.
Or is there a decision to the opposite effect?
Anyway I would rather leave it to someone el
MrDemeanour wrote:
>> Hmm, to me it seems that oddly enough FSF considers it free:
> That seems to mean that it's Debian-compatible
There is apparently no consensus on this point. See
http://lists.debian.org/debian-legal/2006/08/msg00028.html
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECT
Hello,
I'm working on a few packages related to JBoss. One problem is that the
build files often contain targets and taskdefs which depend on lots of
external JAR files, but which are really not needed to build the package.
The problem is that Ant tries to load those external classes on each run,
Hi,
what is the status of JaxMe (bug #296117)? Is it ready for upload?
It is needed for packaging JBoss.
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Barry Hawkins wrote:
> Unless the targets of the project allow you to exclude the ones with the
> dependencies that you have deemed as unnecessary, then you may be
> relegated to patching the build file,
Ok, thanks. I think it should work if I wrap the taskdefs in conditional
targets.
> I hope t
Hello,
I have a curious endianness problem. I get different results with the Sun
JVM and gij. Consider this simple program:
=
import java.io.*;
public class Test
{
public static void main(String[] args) throws java.io.IOException
{
OutputSt
Tom Tromey wrote:
> Could you file this in the gcc bugzilla?
Will do. Already filed Debian bug #386443.
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
(sorry if you get this twice, I sent it to the wrong list...)
Hi,
since the packaging of JaxMe seems to have stalled and it's blocking other
things, I'm thinking of simply finishing it up and getting it uploaded,
starting from Wolfgang's work:
http://www.home.uos.de/wbaer/downloads/ForUpload/
Hi,
I've been looking into packaging Maven 1, for some other projects that still
use it (such as Jackrabbit).
Of course I hit the problem with bootstrapping, as the Maven 2 effort. But I
hope it will be manageable.
I have a different question though: There are lots of plugins which seem to
be ve
...and the same goes for dom4j.
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package: gcj-4.1
Version: 4.1.1-13
Severity: normal
The following test program gives different results with gcj and Sun JDK:
// A.java
import java.nio.charset.Charset;
import java.nio.charset.CharsetEncoder;
public class A {
public static void main(String[] args) throws java.io.IOException
Hi developers,
I've finished packaging of JaxMe 2 (based on Wolfgang Baer's work), expect
it to be uploaded soon. I will now look at dom4j.
Eric: what is the status of xsdlib? Did you manage to sort out the license
issues?
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject o
Marcus Better wrote:
> I've finished packaging of JaxMe 2 (based on Wolfgang Baer's work), expect
> it to be uploaded soon. I will now look at dom4j.
Hmm, turns out that we have to update jaxen to 1.1 first, Wolfgang also
started doing that. It gets really messy because jaxen use
Package: wnpp
Owner: Marcus Better <[EMAIL PROTECTED]>
Severity: wishlist
* Package name: backport-util-concurrent
Version : 2.2
Upstream Author : Dawid Kurzyniec, Doug Lea et al
* URL or Web page : http://dcl.mathcs.emory.edu/util/backport-util-concurrent/
* L
Hi Java team,
I would like to point to a few problems that I see in the functioning of the
Java packaging team. This is probably not news to anyone, but some things
are worth repeating from time to time. Please view this as an attempt at
constructive discussion. These are my observation after work
Arghh... Did you guys repack the orig tarball for tomcat5? If so, why?
--- Begin Message ---
Rejected: md5sum for
/org/ftp.debian.org/ftp/pool/main/t/tomcat5/tomcat5_5.0.30.orig.tar.gz doesn't
match tomcat5_5.0.30-12.dsc.
Rejected: size for
/org/ftp.debian.org/ftp/pool/main/t/tomcat5/tomcat5_5.
Hi Gerardo,
I noticed that in your pacakge libitext-java you use the javax.imageio
interfaces to encode JPEG images. Did you check if this works with libgcj? I
have problem packaging stylebook, which requires a JPEG encoder, and it seems
that nothing is returned by ImageIO.getImageWritersByForm
Holger Rauch wrote:
> So, that means the Depends: field of tomcat5.5 should probably be changed
> from
>
> Depends: java-gcj-compat-dev (>= 1.0.30-5) | kaffe (>= 2:1.1.6-3) |
> java2-runtime
>
> to
>
> Depends: java-gcj-compat-dev (>= 1.0.30-5) | kaffe (>= 2:1.1.6-3) |
> java2-compiler
No, it s
Holger Rauch wrote:
> The point I was trying to come up with was that it should be possible to
> install tomcat5.5 *regardless* of the JDK installed on the system,
Yes, I agree with you.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROT
Javier Serrano Polo wrote:
> * java-gcj-compat-dev
> It looks like this option is completely broken, both in version 5 and 5.5.
> Regarding bug #395167, turning security off leads to a
> ClassCastException. Perhaps the logging issue has nothing to do with the
> crash.
I'm working on a fix for #395
Benjamin Mesing wrote:
> However it requires Java 5.0 and I haven't found any information if
> there is a 5.0 compatible free java compiler available.
I don't think so, but check GCJ upstream. It's not just the compiler, but
also the class library that needs to support some new features, such as
g
Burak Emir wrote:
> Would the existing packages be moved to main?
Many, perhaps most, of the existing packages in contrib can already be moved
to main. It's just a question of migrating them to use GCJ. This is being
done slowly, volunteers are welcome to help.
Marcus
--
To UNSUBSCRIBE, email
Hi,
I'm working on squashing some ugly bugs in tomcat5.5, and right now I've
just about had enough with the patch system. I have better things to do
with my time than regenerating patches and sorting out conflicts for every
little change. I feel that the complexity of the package has outgrown the
> I have now determined that it can build using itself as compiler
> (If I make a preliminary version bootstrapped with binary sun javac).
Then it would have to go in non-free unfortunately. Can the bootstrap
compiler be built with gcj instead?
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTEC
Arnaud Vandyck wrote:
>> I'm working on squashing some ugly bugs in tomcat5.5,
> You mean upstream bugs?
No, packaging problems, #395167 being the most serious.
> Please, provide the result with the *original* tarball and a serie of
> patches so it's easy to isolate the patches.
I agree that th
Barry Hawkins wrote:
> Marcus Better wrote:
> Are you
> proposing here that you are going to place the Tomcat source under
> version control and then make your orig.tar.gz from that?
No, only the source will be under version control. The orig.tar.gz is still
the same.
> If you f
Can anyone tell me why we process XML documentation with xsltproc instead of
the way upstream does it, with
Hi,
I've prepared an updated Tomcat5.5 package which fixes bugs #395167,
#397996, #393224, #398044, and a few minor issues. This version should work
with java-gcj-compat.
Due to the number of changes, I would appreciate if a few people could help
me test it before upload. You can find the package
Hi!
thanks for your work, here are a few comments:
debian/control: You are using ant-trax and xalan2 in the rules file, so add
ant-optional and libxalan2-java to build-depends. (Did you build it with
pbuilder?)
AFAIU cdbs calls ant in the "clean" target. So it seems ant has to go into
Build-Depe
Teresa Dannette McGrew wrote:
> Java is installed here, /usr/java/jre1.5.0_09.
Please install the Debian package sun-java5-jre (from non-free). It installs
in /usr/lib/jvm/java-1.5.0-sun. That should help.
> jre1.5.0_09 worked great and I never heard of SableVM.
SableVM is a different JVM, an al
[Moving to debian-java list.]
Joost van Baal wrote:
> I've packaged cocoon 2.1.9, for usage with tomcat5.5.
Very interesting! A few comments:
*There are dozens of jars in the source. It will be a huge task to package
those. Would be good to start working on the most important ones that are
not a
Hi,
I believe that commons-daemon should be built for the s390 architecture, as it
is for all the other architectures. Please remove it from the "not-for-us"
state.
Thanks,
Marcus
pgp8S6YFffMOr.pgp
Description: PGP signature
Hi,
commons-daemon is currently in the "Dep-Wait: kaffe-pthreads" state. Since the
package no longer build-depends on kaffe, it should be possible to build it
now.
Thanks,
Marcus
pgp1MXj4fNtv9.pgp
Description: PGP signature
It's preferable to leave the package contents exactly as upstream, and just
repackage into a tarball. In that case you don't need to tag the orig
filename.
See
http://people.debian.org/~daniel/documents/packaging.html
for some recommendations.
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROT
Benjamin Mesing wrote:
> Generally speaking yes, but the Debian Java Policy suggests, that class
> files should be removed from upstream release [1].
That advice is plain wrong. (And it's not part of the actual Java policy as
the page says.)
Many Java packages come with jar files for dependencies
Arnaud Vandyck wrote:
> It's a good idea to remove generated javadoc and jar files and classes.
Well, let's agree to disagree. :)
> They can be removed to use less space and be sure not to include code
> that has been build with non free dependencies.
The space argument is rather weak IMHO, and
Andrew Haley wrote:
> > It's a good idea to remove generated javadoc and jar files and classes.
>
> Very much so. Unless you build from source, you have no way to know
> that the binaries correspond to that source code. You can't even
> guarantee that you're not violating the GPL, which require
Matthias Klose wrote:
> Marcus Better writes:
>> instance we ship a lot of packages that build with Maven, but since we
>> don't have Maven in Debian, we use the included, pre-generated, Ant build
>> file instead. What should we do about those?
>
> if these packag
Matthias Klose wrote:
> looked at libcommons-logging-java, jaxen, dom4j, which do not use
> maven for the build. so which sources are actually including maven
> jars?
I think we are talking about two different things here. No packages include
maven jars. Some packages use maven upstream, but in al
Matthew Johnson wrote:
> Hmm, arbitrarily depending on one rather than the 'current installed
> system' seems wrong.
No, it's precisely the correct course. Please read the Java policy and the
information on
http://pkg-java.alioth.debian.org/
You should not build-depend on a virtual package, but
he symlink `/usr/share/java/mysql.jar'. Thanks to Javier
Kohen. (Closes: #404858)
-- Marcus Better <[EMAIL PROTECTED]> Fri, 29 Dec 2006 13:29:04 +0100
mysql-connector-java (5.0.4+dfsg-1) unstable; urgency=low
* New upstream release. (Closes: #404153, #366808, #394878)
Hi,
just some quick comments.
> http://mjj29.matthew.ath.cx/debian-upload/libmatthew-java/
Your package contains about 40 source files and builds five different binary
packages. How do you justify this? Why not simply roll the classes into the
main package? Since your classes appear to solve pro
Matthew Johnson wrote:
>>> Package: libunix-java
>>
>> Please choose a less ambiguous name.
>
> Ambiguous in that it's ambiguous as to what it does (in which case
> libunixsocket-java?)
Yes, sounds better.
> Well, to use it you need either a Java runtime or a Java compiler, and
> not all compil
Matthew Johnson wrote:
> Currently the lib and jar provided by upstream are called
> libunix-java.so and unix.jar; should those also be renamed
I was thinking more of the package name.
> So the make line would be:
>
> $(MAKE) JAVA_HOME=/usr/lib/jvm/java-gcj
> JAVAC=/usr/lib/jvm/java-gcj/bin/java
Hi,
in light of discussions [1, 2] about the best way to manage Maintainer and
Uploaders fields, I suggest we introduce a minor change, with the goal of
improving quality and minimising bit rot.
The problem is, in short, that a package may go without attention because
uploaders don't feel respons
Petter Reinholdtsen wrote:
> I believe this is a bad idea, because only the maintainer get the bug
> reports by default, and I believe the entire team should get a message
> when new bugs arrive.
An even bigger problem is that nobody gets the bug reports in person now.
Uploaders are supposed to su
Marcus Better wrote:
> Isn't it possible to get bug reports forwarded automatically to the
> mailing list anyway?
Apparently the mailing list can be subscribed to the PTS. I guess someone
has to do it manually for each package though.
--
To UNSUBSCRIBE, email to [EMAIL PROTEC
Stefan Gybas wrote:
>> The Maintainer has ultimate responsibility for the package,
> What if this person becomes MIA?
One of the Uploaders will notice and take over the package and replace the
Maintainer, which would be an improvement over the current situation.
If nobody steps forward the packa
Paul Cager wrote:
> which seems more sensible to me. Should I change it to
> /usr/share/doc/$package/api? I assume I should also create a doc-base.
Yes, sounds reasonable.
The draft policy [1] suggests /usr/share/doc//api. Check this
thread [2] about how to write the doc-base file.
Marcus
[1] h
Matthias Klose wrote:
>> which seems more sensible to me. Should I change it to
>> /usr/share/doc/$package/api? I assume I should also create a doc-base.
> where $package is the name of the library package, not the name of the
> doc package (if there exists an extra -doc package).
How come? I tho
Michael Koch wrote:
> Please just add yourself. Wolfgang is MIA currently but thats not yet a
> reason to remove them.
What _is_ a reason to remove someone? A package maintained by a MIA would
normally be orphaned. It's easy enough to add the person back when (s)he
starts working again.
In the sp
Matthias Klose wrote:
>> How come? I thought we put api docs in the -doc package, if there is
>> one.
> exactly, but into the /usr/share/doc/$package/api directory, not into
> the /usr/share/doc/$package-doc/api directory.
Oh, I wasn't aware of that. I've been doing it the other way around. But i
Arnaud Vandyck wrote:
> As you mentionned, a lot of packages does not need a lot of attention.
> Why do you want to orphan a package that could be just here because a
> lot of people use it and it does not need upload!
*Because at a certain point it will need attention, perhaps urgently, and
then
Arnaud Vandyck wrote:
> On 1/12/07, Marcus Better <[EMAIL PROTECTED]> wrote:
>> Michael Koch wrote:
>> > Please just add yourself. Wolfgang is MIA currently but thats not yet a
>> > reason to remove them.
>>
>> What _is_ a reason to remove someone? A
Eric Lavarde - Debian wrote:
> 1. you say twice in your email that Debian has a Java quality issue. Can
> you please be more specific,
Yes, I can give examples, but not until next week though. It has to do with
bugs, even important ones, not getting attention. For a quick idea, look at
the history
Eric Lavarde - Debian wrote:
> 1. you say twice in your email that Debian has a Java quality issue. Can
> you please be more specific, I don't understand which issue(s) you're
> aiming at?
One more thing: Don't get me wrong, there are many parts of the Java effort
that are very well maintained, su
Arnaud Vandyck wrote:
>> *Also because it would make the danger of bit-rot visible.
>
> English problem here, I don't understand this sentence :'(
I mean that there will be a visible difference between these cases:
(a) A package that has gone a long time without activity because it works
well, an
Matthias Klose wrote:
> Assuming that the doc is installed in /usr/share/doc/libfoo-java/api,
> a reference to a class Bar should point to ../../libbar-java/api. Not
> yet sure how to find the location for this reference
I seem to remember that javadoc can be given a command line parameter giving
1 - 100 of 154 matches
Mail list logo
