Since I've got no way to reach debian-qa, I'll use this bug as a
reference. This should explain my previous closing.
Missatge reenviat
De: Javier Serrano Polo jas...@terra.es
Per a: debian...@lists.debian.org
Assumpte: How to orphan a bug
Data: Sat, 01 Aug 2009 14:40:07 +0200
I suggest the file be chmodded to 600 during installation.
I should note this file gets recreated during start-up. The restricted
folder solution is simpler than patching tomcat. If a world readable
tomcat-users.xml isn't acceptable, you could try a user not writable
folder. That would issue a
Package: tomcat5.5
Version: 5.5.25-1
Severity: wishlist
The password file may have another name, be in a different location or
not be at all.
___
pkg-java-maintainers mailing list
pkg-java-maintainers@lists.alioth.debian.org
tag 445857 patch
thanks
The attachment addresses this bug, removing the error message.
--- tomcat5.5-5.5.25.orig/debian/tomcat5.5.init 2008-01-01 20:09:00.0 +0100
+++ tomcat5.5-5.5.25/debian/tomcat5.5.init 2008-01-01 18:29:08.0 +0100
@@ -146,10 +146,14 @@
# Clean up and set
tag 445848 patch
thanks
This patch adds the private subfolder for tomcat-users.xml. The
overall permissions are the standard ones (root.root 644), which means:
* User instances are better supported (as said before)
* tomcat55 can't overwrite configuration files
Further remarks:
El dt 08 de 01 del 2008 a les 04:20 +0100, en/na Javier Serrano Polo va
escriure:
* A directory symlink in postinst is removed. It created a symlink
inside the pointed directory instead of overwriting the
directory symlink. Then purging the package didn't delete
This is the same patch with the pending stat overrides for /var folders.
The directory symlink in postinst isn't necessary because the migration
to /etc is done in the preinst stage.
private_users_2.diff.gz
Description: GNU Zip compressed data
___
Package: icedtea-gcjwebplugin
Version: 1.0+dak1-1
Severity: wishlist
Because user and system trust levels may be different, there should be a
way to override the trusted CAs set. My current setup looks for an
alternative truststore under .gcjwebplugin, but you may want to use a
different
* A directory symlink in postinst is removed...
aka #498487 fix included in 5.5.26-5. Updating the patch accordingly.
private_users_2.diff.gz
Description: GNU Zip compressed data
___
pkg-java-maintainers mailing list
That dependency isn't mandatory. I've got a working tomcat without
webapps, then the problem must be something else.
___
pkg-java-maintainers mailing list
pkg-java-maintainers@lists.alioth.debian.org
En/na Pierre Machard ha escrit:
Hi,
I am sorry but the directory webapps is only created by tomcat-webapps.
And this directory is required to lanch Tomcat4..
Indeed, I have tomcat-admin installed, which takes care of webapps
directory. But even tomcat-admin isn't required, it's all about
En/na Pierre Machard ha escrit:
Hi,
Note that tomcat4 is present in stable and I do not believe that your
plan could be accepted bye the stable release managers. The proper way
to deal with it is definitely to depend upon tomcat-webapps.
Right, the problem is in stable too. But Depends is
Package: libgnujaf-java
Version: 1.1-1
Severity: important
Please update to version 1.1.1
There's a bug in ObjectDataContentHandler, writeTo() always throws an
exception.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing')
Architecture:
Hi.
I don't see any reason why this is a serious bug, neither a bug at all,
apart from preventing Tomcat entering etch.
Like other libraries, it is the local administrator's responsibility to
set the CLASSPATH accordingly or, in Tomcat's case, use the common and
shared directories, as you already
Package: tomcat5.5
Version: 5.5.20-1
Severity: important
A compatibility package is required to run Tomcat with
java-gcj-compat-dev or kaffe.
This package can be downloaded from the Tomcat download page.
Alternatively, the following symlinks will do the trick.
In /usr/share/tomcat5.5/bin:
ln
El dt 24 de 04 del 2007 a les 19:17 +0200, en/na Florian Weimer va
escriure:
I guess the documentation shoud be clarified:
I don't know where that text came from (it's in a previous link, I
know). From:
http://java.sun.com/j2ee/1.4/docs/api/javax/mail/internet/MimeBodyPart.html#getFileName()
El dc 25 de 04 del 2007 a les 07:12 +0200, en/na Florian Weimer va
escriure:
It's from the GNU implementation against which this bug report was
filed.
I still don't know the origin. It may be from JavaMail 1.3.2
implementation.
El dc 25 de 04 del 2007 a les 11:44 +0200, en/na Javier Serrano Polo va
escriure:
I still don't know the origin. It may be from JavaMail 1.3.2
implementation.
Looking at section 7. VULNERABLE SOURCE CODE, it looks like the
original submitter didn't check any documentation
18 matches
Mail list logo