For me the postinst failed in the multi-sed at # Set custom settings in
settings_local.py
The failing part is the second expression doing ADMINS, which expaned as:
-e /^ADMINS = ($/,/^)$/{s|'root@localhost
('Kalle Kivimaa', 'kalle.kivi...@iki.fi'),'|'root@localhost’|}
If I simply removed
Package: wnpp
Severity: normal
I'm retiring from Debian and orphaning this low-maintenance package.
The only actions are usually related to ispell/aspell/myspell changes.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Package: wnpp
Severity: normal
I intend to orphan the jakarta-ecs package. This is a low-maintenace package.
The package description is:
Generation API directly supports HTML 4.0 and XML, but can easily be
extended to create tags for any markup language. Documents are created
through native
Which files would these be? A quick grep -i didn't find any that aren't
licensed either as Apache or BSD-ish. Or do you mean the clause in the
BSD-ish license saying The Software shall be used for Good, not Evil?
Is there really debian-legal consensus that such a general statement is
a real and
Rene Engelhard r...@debian.org writes:
I noticed I did a mistake in my previous NMU which broke
the symlinks. I fixed it and with this also fixed this bug
and uploaded the NMU.
Thanks!
--
* Sufficiently advanced magic is indistinguishable from technology (T.P) *
* PGP public key
David Paleino d.pale...@gmail.com writes:
I've prepared an NMU for jabsorb (versioned as 1.3-1.1) and am going to
upload it to DELAYED/7 on Sep, 21 (you then have ~10days to do an upload
and cancel the NMU).
Don't bother with the DELAYED, just do a zero-day NMU.
--
* Sufficiently advanced
Marcus Better mar...@better.se writes:
tomcat5.5 is probably going away in squeeze. Please move to tomcat6,
or even better, remove the hard dependency on a container.
The problem with a hard Tomcat dependency is that I haven't ever
gotten around fixing the package to work with eg. Jetty out of
Package: gammu
Version: 1.23.1-2
Severity: serious
Justification: Policy 2.1
It was brought to the ftpmasters' attention that gammu contains
binaries without source. This requires one of the three alternatives:
1. Add source for gnapplet.sis
2. Move gammu to contrib
3. Remove gammu from archive
Steve Langasek vor...@debian.org writes:
Can you expand here on the consequences of ignoring RFC1894? I'm aware that
qmail delivery failure mails look different (and, I might argue,
gratuitously so) than those of other mail systems, but does this cause
interoperability problems for other
Martin Bagge brot...@bsnet.se writes:
Please consider to add this file to translation of debconf.
I recently got the attached translation. Just to confirm that your
translation supercedes it?
--
* Sufficiently advanced magic is indistinguishable from technology (T.P) *
* PGP public
Olaf Zevenboom ozevenb...@gmail.com writes:
The baseURL is defined in my jspwiki.properties file as : jspwiki.baseURL =
wiki/
Umm, that is completely incorrect. It should be either like
jspwiki.baseURL = http://www.example.com:8180/JSPWiki/
or
jspwiki.baseURL = http://localhost:8180/JSPWiki/
Olaf Zevenboom ozevenb...@gmail.com writes:
In the DebConf phase of installation I presumed the baseURL te be a relative
path. Maybe you can hint during setup it should be a FQDN URL?
Will do, it is obviously not well enough written.
Next step for me will be to find out how to link in my old
Umm, you shouldn't need to run Install.jsp as all the relevant
settings are set by Debconf. How did you end up running it?
Could you file the /etc/jspwiki/jspwiki.properties contents?
olaf ozevenb...@gmail.com writes:
Package: jspwiki
Version: 2.8.0-3
Severity: important
Running on Debian
Olaf Zevenboom ozevenb...@gmail.com writes:
The baseURL did not do much at my system. http://localhost:8180/JSPWiki/ did
give a bit of a clumsy result:
Home http://localhost:8180/JSPWikiWiki.jsp?page=Main
This looks like you've missed the trailing / from the baseURL. In any
case, I can modify
I think what José is reporting is that in his opinion the BTS (and
actually all pseudopackages available in the BTS) should be considered
a part of the release and there should be Policy instructions as to
how the BTS should work, so that there would be clear grounds as to
which bugs against the
José Luis González jlgon...@ya.com writes:
Do you agree now?
If you mean do I agree that you should file a bug against
www.debian.org because it doesn't say anything specific about filing
bugs against Debian Policy, then no, I disagree. Any Debian Developer
(or at the very least, every package
José Luis González jlgon...@ya.com writes:
I am sorry but debian-policy isn't featured in
http://www.debian.org/Bugs/pseudo-packages
That's because it is a real package. Also, you could have asked on the
debian-policy mailing list.
If the right place to file bugs against the Policy is the
José Luis González jlgon...@ya.com writes:
System. This makes it impossible to report a bug with RC severity in
the Bug Tracking System that permits RC bugs to remain in Debian when
the report is closed incorrectly and nobody notices before it is
archived (please see bug #227941.) Since the
Package: wnpp
Severity: wishlist
Owner: Kalle Kivimaa [EMAIL PROTECTED]
* Package name: libjakarta-ecs-java
Version : 1.4.2
Upstream Author : Stephen Nagy [EMAIL PROTECTED] and Jon S. Stevens [EMAIL
PROTECTED]
* URL : http://jakarta.apache.org/ecs/
* License
Package: wnpp
Severity: wishlist
Owner: Kalle Kivimaa [EMAIL PROTECTED]
* Package name: libjabsorb-java
Version : 1.3
Upstream Author : Jabsorb Team [EMAIL PROTECTED]
* URL : http://jabsorb.org/
* License : Apache 2.0
Programming Lang: Java
Description
Philipp Matthias Hahn [EMAIL PROTECTED] writes:
Sorry, but 2.5.139 already violates this rule. The following .jar-files
Yes, and as you may have noticed, I have already filed a serious bug
against JSPWiki because of this. Most likely JSPWiki will move back to
contrib, at least for now, as some
Florian Grandel [EMAIL PROTECTED] writes:
If you use 1)
- How do you get your deleted binaries back in during clean phase?
AFAIK clean target has to reverse all changes the build process
introduced.
Easiest way to do this is to move the libraries somewhere else for
build, and then back
Package: liblucene-java
Version: 1.4.3.dfsg-3
Severity: important
/usr/share/java/lucene.jar links to ../lucene-1.4.3.jar which is
incorrect. It should link to ./lucene-1.4.3.jar.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500,
Philipp Matthias Hahn [EMAIL PROTECTED] writes:
1. Only in the final debian/jspwiki/ tree (but build with the original
.jar files)
2. Each time during the debian/rules run
3. Once in the .orig.tar.gz (the download is only availabe as .zip)
You can either modify the .orig.tar.gz not to
Package: jspwiki
Version: 2.6.3-1
Severity: serious
Justification: Policy 2.1
Seems that binary jars slipped through when the package was moved
to main from contrib. Will investigate on the best way of including
the source code of those jars which are not yet packaged in Debian
main.
-- System
Helge Kreutzmann [EMAIL PROTECTED] writes:
While translating your template to German I noticed the following
minor errors:
I think the current English translation process is taking care of this
bug, but I'll make sure that it does.
--
* Sufficiently advanced magic is indistinguishable from
Christian Perrier [EMAIL PROTECTED] writes:
Please review the suggested changes are suggested, and if you have any
objections, let me know in the next 3 days.
One comment.
Template: jspwiki/usepagecache
Type: boolean
@@ -25,80 +35,82 @@
Template: jspwiki/baseurl
Type: string
Rene Engelhard [EMAIL PROTECTED] writes:
how is unzip not found (so a missing build-dep on unzip) related to
the Java errors in gjdoc?
Hngh, sorry, got overzealous when correcting incorrectly filed mass
bug reports (assumed the whole batch was for the same gjdoc problem
instead of checking each
Alex Samad [EMAIL PROTECTED] writes:
Sorry maybe my miss understand of the java / debian world. Don't
you have to just distribute the war file and you can distribute the
java files. But because it doesn't compile under gcj (?) or gij or
jikes you can't distribute ?
All Debian software must
Alex Samad [EMAIL PROTECTED] writes:
argh, seems like its a problem in the gnu.javax.crypto.keyring, have
you filled a bug against classpath ?
No, because at the time it did very much look like I just wasn't using
the gkeytool correctly (even if it did claim to use exactly the same
syntax as
Alex Samad [EMAIL PROTECTED] writes:
Version 2.4.100 has been release for quite a while
Indeed it has been, but version 2.4 only compiles with the Sun JDK,
which is only available in non-free, at the moment.
--
* Sufficiently advanced magic is indistinguishable from technology (T.P) *
*
Roland Stigge [EMAIL PROTECTED] writes:
Is it only a bug in the maintainer's procedure or rather in the archive
maintaining software?
I guess that depends on your point of view :) I ran into this problem
with my jspwiki package, and IIRC the idea is to fix the archive to
handle this at some
Aurelien Jarno [EMAIL PROTECTED] writes:
libgnujaf-java's source package contains a debian/rules file which does not
contain the binary-arch target. This target required by both the section
4.9 of the Debian policy [1] and the Etch release standards [2].
This too is not a bug. The policy
Aurelien Jarno [EMAIL PROTECTED] writes:
jakarta-log4j1.2's source package contains a debian/rules file which does not
contain the binary-arch target. This target required by both the section
4.9 of the Debian policy [1] and the Etch release standards [2].
The policy manual says:
build-arch
Aurelien Jarno [EMAIL PROTECTED] writes:
libgnujmi-java's source package contains a debian/rules file which does not
contain the binary-arch target. This target required by both the section
4.9 of the Debian policy [1] and the Etch release standards [2].
From the Debian policy:
If one or
Ruben Puettmann [EMAIL PROTECTED] writes:
Yes this would be the best way. Cause so it is posible that tomcat5 and
tomcat5.5 runs on the same Server with different users. But if you do
you must keep the people in mind that already has installed the package.
I think the better way would be to
Bastian Kleineidam [EMAIL PROTECTED] writes:
Adding /usr/lib/jvm/java-1.5.0-sun to the JDK dirs tomcat starts up
without errors. Here is the patch:
Umh, how have you installed the Sun 1.5 JDK? make-jpkg should put it
into /usr/lib/j2sdk1.5-sun, not under lib/jvm.
--
* Sufficiently advanced
Arnaud Vandyck [EMAIL PROTECTED] writes:
I'm not sure it's the responsability of JSPWiki to add symlinks in the
tomcat5 directory tree.
Well, it does so already :) It has to register itself as a webapp and
it has to add a policy file.
--
* Sufficiently advanced magic is indistinguishable from
severity 341691 minor
retitle 341691 Please document that local file system type is no longer
supported
Bastian Kleineidam [EMAIL PROTECTED] writes:
Hi,
please try to replace 'local' in pam_mount.conf with the actual
filesystem type you are using (eg. 'ext3') and see if that works.
Your
Andreas Schildbach [EMAIL PROTECTED] writes:
I understand your point. Then what about a separate package just for the
symlink? The package could depend on both tomcat(5|4) and libmysql-java,
so it would disappear if either the database driver or tomcat is
uninstalled.
Umm, as far as I
Andreas Schildbach [EMAIL PROTECTED] writes:
I'm afraid I don't know about the packaging policy. I can only say that
the webapp can't know what database the server-admin or deployer is
going to use, especially since in the Realm case he's got the option of
an in-memory or file-based realm,
Package: libpam-mount
Version: 0.10.0-1
Severity: grave
Justification: renders package unusable
The following /etc/security/pam_mount.conf directive fails with the
latest version (worked fine previously). Mounting the encrypted
partition with mount works fine.
volume killer local - /dev/hda6 - -
Wolfgang Baer [EMAIL PROTECTED] writes:
tomcat5 will soon move to main. As its unlikely for various
reasons that tomcat4 will be in main I think it would be good
to start thinking about moving jspwiki to tomcat5.
I'm working on this, unfortunately it isn't just add tomcat5 to
Depends: and go
Wolfgang Baer [EMAIL PROTECTED] writes:
Why do you want to retain backwards compatibility to tomcat4 ?
IMHO tomcat4 shouldn't be part of etch anymore and be removed at some
time from the archive. We don't have enough developers interested
in java to maintain and keep old stuff around (just my
Package: libgnu-regexp-java
Severity: minor
As reported by George Danchev.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (1000, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13amd64
Locale:
Package: kernel-package
Version: 9.006
Severity: important
If I have a following config directive in .config, the make-kpkg produces
a kernel with the module library at /lib/modules/X.Y.Zamd64 as it should.
CONFIG_LOCALVERSION=amd64
Unfortunately modules_image target produces .deb's which
Package: enemies-of-carlotta
Version: 1.0.3-1
Severity: normal
The manual page says as follows:
/^your.virtual.domain$/ dummy
/^(yourlist|yourlist-.*)@(your.virtual.domain)$/ joe-virtual-$1
This is incorrect, as the joe-virtual should have a
Package: apache2
Version: 2.0.54-4
Severity: normal
When installing new Apache2 installation, I ran into the following
situation. I removed the default site from sites-enabled and added my
own NameVirtualHost and virtual hosts. Instead of NameVirtualHost * I
had NameVirtualHost X.Y.Z.W where
Package: ssh
Version: 1:4.1p1-3
Severity: grave
Justification: renders package unusable
I guess this dpkg -L snippet tells everything:
kaylee ~/src % dpkg -L ssh
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/ssh
/usr/share/doc/ssh/copyright
/usr/share/doc/ssh/NEWS.Debian.gz
Jeroen van Wolffelaar [EMAIL PROTECTED] writes:
The log4j transition took more than a year!
I didn't follow that at all, but why did this transition take so long?
Most transitions can be done easily within a month or even shorter.
Because the maintainer (me) was/is lazy.
--
* Sufficiently
Barry Hawkins [EMAIL PROTECTED] writes:
The JDKs are packaged by make-jpkg are non-free, and as such, we do not
tamper with the javac, java, etc. commands of any vendor's JRE/JDK.
People expect that sort of thing to be left the way the vendor made it,
and currently (for better or worse) a java
Andreas Jochens [EMAIL PROTECTED] writes:
CLASSPATH=/usr/share/java/servlet-2.3.jar ant opened-war
Unable to locate tools.jar. Expected to find it in
/usr/lib/kaffe/pthreads/lib/tools.jar
make: *** [build] Error 1
Which compiler are you using? Jikes, Kaffe or Sun/IBM JDK?
--
* Sufficiently
Andreas Jochens [EMAIL PROTECTED] writes:
Please also set JAVA_HOME correctly to the directories used by the
{sun,ibm,blackdown}-j2sdk1.x packages which are created by java-package.
I'm of two minds about this. Isn't it really more of make-jpkg's job
to make sure that any javac built sets any
Barry Hawkins [EMAIL PROTECTED] writes:
classes that IBM does not have. So, if Arnaud or Stefan could build
tomcat4 with what I have checked in and sponsor an upload, we will
likely have resolved this issue and gotten tomcat4 back into Sarge.
I'm trying to do this but as amd64 port is missing
Kalle Kivimaa [EMAIL PROTECTED] writes:
I'm trying to do this but as amd64 port is missing some libraries
(why, I have no idea) I'm having a slight difficulty with it. So, if
Stefan/Arnaud beat me to it, feel free. Barry's changes looked fine to
me and I tagged the HEAD already.
Oh well, I
Wolfgang Baer [EMAIL PROTECTED] writes:
IMHO this bug can be closed as it is not related to a testing or
unstable installation, nor a woody installation !
If you can end up with the problem using simply apt-get, then it is a
real bug and needs to be fixed. I'm going to do it today, so if
Christoph Martin [EMAIL PROTECTED] writes:
Ok. In jars.jar org/apache/commons/collections/ is included. Does
someone know how I check the version in a .jar file?
That's a bit difficult unless the jar file contains either a well
written META-INF file or a version file... I think you need to
Package: make
Version: 3.80-9
Severity: normal
The attached makefile fails to work correctly on i386. Strangely the same
file works fine on amd64. If you run the build target twice, the second
time it still tries to run the bzip command which then fails as the file
is already unzipped.
-- System
58 matches
Mail list logo
