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
-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
-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
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
[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
-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
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
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
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
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
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:
> 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
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
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
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
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
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
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
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
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
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
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
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:
> 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
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
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
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:
> 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
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
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
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
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,
-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
Hi,
Johannes Ernst wrote:
> I have a self-contained web application built into a WAR file, say
> foo.war.
>
> I'm trying to package it up as foo.deb on a custom server so users of
> that web application can simply use
> apt-get install foo
> to get this application deployed on their applicat
Onkar Shinde wrote:
> Debian currently contains three libjdom packages, libjdom-java,
> libjdom0-java, libjdom1-java.
This is a disaster! I wasn't even aware of the existence of libjdom-java.
Please, can the maintainers of reverse dependencies migrate to
libjdom1-java in time for lenny?
The only
Hi Jonas,
Jonas Granvik wrote:
> Thanks for your reply. I thought this would be the situation. With no
> knowledge about how making packages for Debian I doubt that I could
> make this myself, but I filed a RFP at
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481869
A good next step would be
Paul Cager wrote:
> So I propose we create a new package, libservlet2.5-java, using the
> Tomcat 6 source code (I realise Tomcat 6 isn't in Debian yet).
There is an open bug (#452370) about building libservlet2.4-java from
tomcat5.5 source package, and so get rid of the libservlet2.4-java source
p
Michael Koch wrote:
> To solve #1 I would like to create a sister directory for 'trunk'
> called 'old'
And same for tags and branches probably?
Cheers,
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Daniel Pocock wrote:
> JBoss and Tomcat detect new deployments automatically.
It probably doesn't make sense to auto-deploy a new webapp to all installed
servers. Probably the user wants to select which server to deploy to,
similar to the traditional installation where the servers have separate
di
Paul Wise wrote:
> Perhaps people on the debian-java list should be given the chance to
> adopt or fix groovy or give an opinion on it's usefulness? CCing them.
Groovy is emerging as an important new language for the Java platform, and
would be very useful to have in Debian. Of course the package
Matthew Johnson wrote:
>- #363165 mentions the version number in jar names. The parallel with C
> libraries is .so name.
No, our version numbers are very different - they are upstream release
numbers, whereas sonames are ABI versions.
> When compiling the symlink is use and at
>
Michael Koch wrote:
>> I just did the XS prefix removal in svn (with a little script) for all
>> the packages that were in the list.
>
> Please add a changelog entry for all you changes.
I try to avoid cluttering the changelog with minor packaging changes that
are of no interest to users. What is
Paul Cager wrote:
> Regarding the email below, how about an automated mass update of the
> pkg-java trunk to convert the old XS-Vcs entries into new Vcs ones?
I just did the XS prefix removal in svn (with a little script) for all the
packages that were in the list.
> Or possibly even add in missi
Hi,
I would like to try building Eclipse from the SVN repo. How is the orig
tarball built? Where do the parts come from?
$ tar tzf eclipse_3.2.1.orig.tar.gz
eclipse-3.2.1.orig/
eclipse-3.2.1.orig/upstream/
eclipse-3.2.1.orig/upstream/eclipse-sourceBuild-srcIncluded-3.2.1.tar.bz2
eclipse-3.2.1.ori
I have recently had problems building Java packages. The build would just
eat memory, and occasionally show things like:
GC Warning: Repeated allocation of very large block (appr. size 524288000):
May lead to memory leak and poor performance.
GC Warning: Out of Memory! Returning N
Arnaud Vandyck wrote:
> Marcus is working on tomcat, maybe Michael is also working on it. I'm
> ok but you have to wait for them to confirm.
I'm more than happy if someone wants to help. Please file bug reports and
use "bts owner" to indicate that you are working on it.
Marcus
--
To UNSUBSCRI
Michael Koch wrote:
> This is a single-cpu/single-core machine.
That fits the pattern. The problem seems to hit SMP machines.
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Michael Koch wrote:
> The buildf failed but differently:
>
>
> [junit] Running org.dom4j.xpath.MatrixConcatTest
> [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.833 sec
Ok, so the ThreadingTest succeeded at least.
Could you send me the test result for the MatrixConcatTest
Michael Koch wrote:
> the usual suspects failed which have already filed FTBFS bugs in the
> BTS.
What was the result for dom4j? I would like to have more data on #427456.
What is the arch and CPU of the build system?
Regards,
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subj
Arnaud Vandyck wrote:
> The RC bug has been closed, but moving argouml, libgef-java and
> arbortext-catalog to xerces2 should be done. And then, remove xerces1.
Care to file some bugs? :)
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [E
Hi,
Michael(tm) Smith wrote:
> I need a bit of advice around best practices for upstream Java
> builds. In particular, if/how/where system-specific Java
> properties should be set, and how to avoid hard-coding them in
> build files.
The most common way is to let your Ant build file include build.
Tom Marble wrote:
> And please... if you have ideas for interesting libraries and/or
> applications to package please add them to the wiki.
Please, that's the umpteenth wiki page with requested packages. For instance
there is
http://wiki.debian.org/Java/RequestedPackages
which is longer and h
Petteri Räty wrote:
>> I don't know how Gentoo works, but it's not enough for us to know which
>> ABI version of a particular dependency we need, we also need the mapping
>> of that ABI to Debian packages to avoid upgrade problems.
>
> So you install to /usr/share/ as you need to have the ABI in t
Petteri Räty wrote:
>> I think we will need something similar to the shlibs system, no?
> Well why would they be any different for a binary distribution?
I don't know how Gentoo works, but it's not enough for us to know which ABI
version of a particular dependency we need, we also need the mappin
Petteri Räty wrote:
> We solved this by installing to /usr/share/- where slot is
> roughly the ABI (we increase it every time a new version breaks
> something using the library).
For a binary distribution like Debian there are other issues, for instance
*how to generate dependencies on the correct
Tom Marble wrote:
> Packaging
> -
I think we need to add:
* Library ABI handling and support for parallel installation of multiple
versions (as discussed in another thread [1]).
Marcus
[1] http://thread.gmane.org/gmane.linux.debian.devel.java/6537
--
To UNSUBSCRIBE, email to [EMAIL
Jan-Pascal van Best wrote:
> What is the policy about this issue?
It's generally not acceptable to duplicate code, so Debian versions of
libraries should be used.
Regards,
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Michael Koch wrote:
> Is this an amd64 machine with a 32-bit Debian version installed and
> 64-bit kernel running?
No, this is pure amd64.
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Suddenly I get the infamous "java.lang.Object cannot be resolved" when building
on amd64. Any ideas?
I'm not using any chroots or anything.
~$ /usr/lib/jvm/java-gcj/bin/javac Test.java
--
1. ERROR in Test.java (at line 1)
public class Test
^
The type java.lang.Object cann
(Please use [EMAIL PROTECTED] for discussions, otherwise it can be drowned
in BTS mail.)
Paul TBBle Hampson wrote:
> Is the issue just that java-package is no longer interested to the
> original maintainers, with the admission of Sun's JDK/JRE to non-free?
I guess people are more motivated to wor
Florian Weimer wrote:
>>* When building the package a new Jar must be built (from source)
>> that could replace the bootstrap Jar.
>
> This is a bit tricky. Theoretically, you are supposed to bootstrap
> from an installed version (IOW, a self-depdency).
I assume maven2 will be an archit
[EMAIL PROTECTED] wrote:
> I could not agree more. I assume you mean the packager needs to
> reference the right version of a library.
That too, but also the _user_ who runs third-party code using the library,
and needs to set the classpath.
> I actually have a question about that. What do we nee
Andrew Haley wrote:
> In my opinion, Java libraries without stable interfaces shouldn't be
> deployed in free OSes.
That's a nice goal but unfortunately the world is not so perfect, because
users occasionally require new software with shiny new bells and whistles.
Besides we cannot control upstrea
I'm about to upload a new tomcat5.5 package (5.5.20-5). I would normally
have sent it to experimental, but the current version in sid is hardly
usable so this should be a big improvement with a ton of bugfixes. So give
it a spin if you like, but not on production machines of course.
I hope to make
(Please don't CC me, I am subscribed to the list.)
Elliott Hughes wrote:
> the application will be better with Java 6, so i'd really like
> to Depends: it, but i don't want to shut out people on systems that have
> an available sun-java5-jre but no sun-java6-jre.
Why not? sun-java6-jre is availab
Elliott Hughes wrote:
> Marcus Better wrote:
> > Benjamin Mesing wrote:
> > > I want to build a package which requires Java 5. Therefore I
> > > build-depend on (sun-java5-jdk | sun-java6-jdk).
> >
> > Please don't do this, just select one of them.
> is tomcat5.5 really broken?
Somewhat, please refer to the bug reports for details. If you want to help,
use "reportbug" to report any additional problems you run into.
Also check README.Debian and follow the debugging instructions there if you
have a problem. In particular check the security po
popcon reports 516 installs, versus 22756 for libxerces2-java. For the
dependents, there are 172 of argouml, 222 of libgef-java and 67 of
arbortext-catalog, so apparently some people did install it separately.
Nevertheless I don't think it makes sense to keep it in lenny.
Marcus
--
To UNSUBSC
Paul Cager wrote:
> The maven2 distribution contains about 7 wagon jars (wagon-file,
> wagon-http-shared etc). What would be the best way to package this:
I suggest one source file and several binary packages. This is because
(a) the top-level svn directory has a project file listing the other
su
Paul Cager wrote:
> For packages that are built by Maven it would take no more than a few
> minutes to write a debian/build.xml for the Debian build system.
That is probably true for most projects, but it also means we have to
maintain that build.xml file. I think some projects are more complicate
Benjamin Mesing wrote:
> I fail to see the reason why the results should be the same.
Because otherwise we will get interesting FTBFS bugs at random times, that
someone will have to fix.
> Using /usr/bin/javac might as well lead to the usage of different Java
> compilers
Which is why we don't us
Paul Cager wrote:
> [javac] The type java.lang.Object cannot be resolved.
My sponsor had this one too. He was building in a 32-bit environment on
amd64, and apparently gcj has some problems with this. Building on real
i386 should work.
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Benjamin Mesing wrote:
> I want to build a package which requires Java 5. Therefore I
> build-depend on (sun-java5-jdk | sun-java6-jdk).
Please don't do this, just select one of them.
> How do I ensure, that the correct compiler is used.
> Is the only way, to explicitly set the java
> compiler p
[guys, please don't CC me, I am subscribed.]
[EMAIL PROTECTED] wrote:
> I think it would be better to just leave the version as is and accept
> that multiple version sit around on the file system. They don' cause
> any harm anyway.
The Debian package will support this for _users_, it will work ju
[EMAIL PROTECTED] wrote:
> As far as I can tell the problem exists because many libraries do
> dramatic changes to their API quite regularly ..
Major API changes may warrant having two different versions of a library in
Debian. This happens from time to time. However if such changes happen very
of
Arnaud Vandyck wrote:
> I was not talking of the dependencies version problem for debian but
> for someone using maven in debian with a debian repository ;-)
I don't see the need for a special Debian-Maven repository.
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "uns
user pkg-java-maintainers@lists.alioth.debian.org
usertag 323050 maven2-packaging
thanks
> But I currently try a different route. I put all maven dependencies
> (jars) into a new big package maven-dependencies and will then build
> maven2 with it as Build-Dependency.
Ok, fine. As you see I userta
Michael Koch wrote:
> And the dependencies mostly need maven2 for building too. Bootstrapping
> can be fun.
But we can use your preliminary maven2 package to build the dependencies, I
assume? That would solve the bootstrapping problem.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a sub
Arnaud Vandyck wrote:
>> The only requirement I have from the Debian packagers is that Maven from
>> Debian still behaves *exactly* like Maven from Apache from a users point
>> of view.
> we cannot distribute a software for Debian that could install non free
> software in all ~'s.
Of course we ca
Arnaud Vandyck wrote:
>> 2. For building Debian packages: This needs to use Debian versions of
>> dependencies.
> Also, we try to have less possible different versions (we try to have
> the latest stable), but with Maven, you can work with older versions
> of a lib. Do we accept this?
IMHO we sh
Trygve Laugstøl wrote:
> As a user Maven should behave just like
> upstream Maven, meaning that it will download from the internet and
> install stuff under ~/.m2/repository.
[...]
> For the dpkg builder Maven should still behave like Maven *but* with
> some environmental changes it can comply wi
Daniel Leidert wrote:
> But if Michael Smith really offers splitting the source, I would prefer
> this way
Very well, please file an RFP and CC me when it is done.
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Daniel Leidert wrote:
> Update: The docbook-xsl upstream is willing to release a separate
> (source-)tarball for the extension Java classes
Ok, doesn't make much difference from a packaging perspective though.
Marcus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe
Daniel Leidert wrote:
> Just in SVN. There is no source-tarball.
But I see the sources for the extensions are contained in the docbook-xsl
tarball (1.72.0), but either they are not in the 1.71 version, or the
sources have been stripped from the Debian tarball (which would be a
mistake, only the j
[moving discussion to debian-java list]
Daniel Leidert wrote:
> I wanted to ask what you guys think about creating a package for just
> the extensions Norman Walsh wrote for docbook-xsl. The Java-classes can
> be found at
> http://docbook.svn.sourceforge.net/viewvc/docbook/trunk/xsl/extensions/.
Michael Koch wrote:
> A there are only several hundred open wnpp bugs nobody cares about.
I think usertags can be used quite effectively to sort out and display the
bugs that we do care about. They can replace all information that is on
that wiki page now, without risk of getting outdated. But fee
Bruno Dusausoy wrote:
> We've put a page[1] on the Debian Wiki in order to gather the Java
> apps you want to be packaged.
The existing infrastructure is very well suited to keeping track of such
things. Please use it, it's much more effective than having a wiki page
which is guaranteed to become
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
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
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
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
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
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
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
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:
>> 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
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
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
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
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
1 - 100 of 154 matches
Mail list logo
