Re: Null Pointer exceptions in servlets since latest Apache/Jserv update
Andreas Tille wrote:
> java.lang.NullPointerException:
> where line 70 is something like
>
> rs = stmt.executeQuery("SELECT * FROM Table");
This simply means that stmt is NULL at this point, i.e. the previous call
to Connection.createStatement() failed. We can't help you unless you post
the whole source file.
> I have included the line
>
>repositories=/usr/share/java/servlets,/usr/share/java/freetds_jdbc.jar
>
> in /etc/jserv/zones/root.properties.
You should not do this as the classes in the propsitory are loaded using a
special classloader which detects changes files. You should rather put
freetds_jdbc.jar into wrapper.classpath in /etc/jserv/jserv.properties and
make sure that the system classes (classes.zip for JDK 1.1) are also included
in this classpath.
BTW: This is the wrong mailinglist for this question, please use debian-user
next time (it's also off topic on debian-java).
--
Stefan Gybas
Re: libgd1 vs. libgd1g
Gerfried Fuchs wrote: > webalizer and linuxconf now depends on libgd1g, which currently isn't > anymore available from our ftp-servers. Not any longer. The newest linuxconf package in woody depends on the new libgd1: Package: linuxconf [...] Version: 1.20r2-1 Depends: netbase (>= 3.16-1), logrotate, sysvinit (>= 2.77-1), freetype2 (>= 1.3.1), libc6 (>= 2.1.2), libgd1 (>= 1.8.3-3), libjpeg62, libncurses5, libpng2, libstdc++2.10, libxpm4, libz1, xlib6g (>= 3.3.6-4) The libgd maintainer decided to drop support for a libc5-based libgd and renamed the libgd1g package to libgd1 (I personally don't think that this was a good idea as it might cause problems during upgrades). -- Stefan Gybas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Work-needing packages report for Jul 11, 2003
Arnaud Vandyck wrote: [junit-freenet (#165504), orphaned 264 days ago] When I look at the cvs, two classes have been commited 8 month ago, the other 23 month ago!.. I will adopt this package but I won't upload a new version. I have asked for its removal instead (#200949). Let's see which other useless Java packages we can get rid of this way... ;-) Stefan
Re: stack protection
Russell Coker wrote: It sounds like we need a propolice enabled GCC. I have talked to Matthias Klose, one of the GCC maintainers, about this. He included the patch so he could built ProPolice-enables packages of gcc and g++ but he's currently too busy with other things. He might accept a patch that builds these packages but we really need to hurry if we want these compilers released with sarge. Maybe some of the Adamantix developers will help? However, ProPolice has not been ported to all architectures yet, see http://www.research.ibm.com/trl/projects/security/ssp/statuschart.html for details. There are other stack protection mechanisms too, but propolice seems the most popular. Some investigation would need to be done into the relative merits of the various options (propolice has much better support apparently which will be a major factor). I think ProPolice is the best choice, first because Adamantix has tested it for quite some time. Second, ProPolice offers the best protection according to http://www.research.ibm.com/trl/projects/security/ssp/node4.html#SECTION00045000 and finally it even offers the best performance (http://www.research.ibm.com/trl/projects/security/ssp/node5.html). IMHO innovations in Debian have been rare in the past 2 years (compared to other major distributions), so maybe this is a chance for Debian... Stefan
Re: Planned mass-filing of bugs: java packages only depending on java-common
On Wed, Nov 27, 2002 at 09:33:49AM -0800, Stephen Zander wrote: > To that end I will be filing important bugs against any lib*-java > package that does not depend on either java1-runtime or java2-runtime > (should the package required features of the standard java.* classes > that are only included in the j2se specification). Currently the following packages in testing provide java1-runtime: gij-3.0, gij-3.2, orp-classpath and sablevm. All of them include (or depend on) a Java virtual machine so if I add this dependecy to the lib*-java packages I end up with a de-facto dependency on a virtual machine (which is e.g. not needed for autobuilders). Could you first file bug reports against all Java apckages that should provide java1-runtime (like classpath)? Regards, Stefan Gybas
Re: Planned mass-filing of bugs: java packages only depending on java-common
Stephen Zander wrote: Depending on the core classes does not provide javac which is what the autobuilders actually require. The build dependencies for Java packages could be for example: jikes, classpath, lib*-java (all other required Java packages) If all lib*-java packages in main depend on java1-runtime (the core classes, not a complete JRE with JVM) this dependency is satisfied by classpath. So I don't need a JVM (which is not available on all architectures) to build the package. Also, depending on a java-virtual-machine does not provide the java.* classes necessary at *runtime*. That's correct. I just changed this for tomcat4 yesterday: It now depends on java-virtual-machine, java2-runtime, ... since I also thought that javaX-runtime meant "core classes + JVM" in the past. Regards, Stefan Gybas
FAQ and call for help: Linuxconf and Debian
Hi! I'm getting a lot of mails full of questions about my Linuxconf Debian package so I've put together a little FAQ (attached). I also want to further intergate Linuxconf into Debian but this requires a lot of work. If you want to help me with this please contact me. If you want to reply to this mail please choose the right mailing list. For general Linuxconf questions please use linuxconf@xc.org, for Debian specific issues please use [EMAIL PROTECTED] -- Stefan Gybas1. What is Linuxconf? Linuxconf is a program for Linux systems with three major functions: (a) configuration utility With Linuxconf you can do basic and advanced system administration and configuration. Linuxconf has some core functionality (like creating and managing users, groups and file systems) and several modules for other system components, e.g. bind, apache, sendmail, samba and squid. Currently there are over 20 modules available. The configuration is done using a GUI with lot of help texts that can either use a text, X11 or web interface. Linuxconf does not use a database to store the configuration, instead it just uses the normal system configuration files like /etc/fstab, /etc/hosts - while trying very hard to preserve their structure (like manually added comments). So you can always switch between a text editor and Linuxconf. (b) configuration activator and manager Linuxconf can keep track of changes made to configuration files (either using Linuxconf itself of some text editor) and then update the system to reflect those changes. An example might be vi /etc/inetd.conf vi /etc/apache/httpd.conf linuxconf --update # This will cause inetd and apache to # reload their configuration files Another feature is the ability to archive and restore configuration files (using RCS if available): linuxconf --archive linuxconf --diff linuxconf --extract (c) boot selector The third main feature of Linuxconf is called askrunlevel and this is exactly what it does. It shows a little menu during boot up where you can select the system runlevel and the profile. A profile is a name for an archived configuration (see section b) like "office" or "home", so you can e.g. have different IP addresses or XFree configurations with your laptop depending on your location. Each of these features can be turned on or off independently, that means you don't need to activate the boot selector if you just want to do some Samba configuration. And you can always De-install the Linuxconf package and everything is as it was before. 2. Where can I get the Linuxconf Debian package? I've split up Linuxconf into four seperate Debian packages: linuxconf The main Linuxconf binary (text and web interface only, with all modules) linuxconf-x The X11 GUI for Linuxconf (this is in a sperate package so the main package does not depend on xlib6g, wxxt1 and xpm4g) linuxconf-locale The foreign language files (all except English) linuxconf-bootThe boot selector (see 1c) - if you don't want to enable this features, simply don't install this package and Linuxconf will not make any grave modifications to your system. All packages are in the "experimental" distribution - available on all Debian mirrors in project/experimental/. They can be installed on a Debian 2.1 (slink) system but require a newer netbase package. 3. What is working on Debian GNU/Linux? And what is not? All of the configuration stuff (see 1a) except network configuration is working on Debian. The configuration activator (1b) and boot selector (1c) are partly working (see question 4). 4. What needs to be done in order to make the other features work? The problem with network configuration is that this is done differently on each Linux distribution and thus Linuxconf does not know where to store the host name, IP addresses and routing table. So distribution specific modules were written to handle this part, but unfortunately there is none available for Debian yet. For the configuration activator, Linuxconf needs to know which config file belongs to which service/daemon and how to make this daemon reload its configuration. Again, this is distribution specific but Linuxconf has a little bit basic knowledge here, e.g. it knows that inetd uses /etc/inetd.conf and can be restarted using "kill -HUP". But as you might probably know, Debian uses SysV init scripts in /etc/init.d/ that can also make a daemon reload its configuration, like in "/etc/init.d/proftpd reload". So it would be a good idea to tell Linux
