Re: Installing runnable Eclipse from Debian packages

[Steinar Bang]

> Gervase :

> Currently, I have access to the packages 'eclipse'/'eclipse-platform' on
> Ubuntu.  Having either installed then allows additional packages/plug-
> ins to be installed for the various computer languages (e.g. JDT, CDT,
> pydev).

FWIW I've been running eclipse on debian desktops and laptops ince 2013.

Initially I used the deb packaged version, but that was so antiquated
compared to the current eclipse version at the time, that I moved to
eclipse's own installer and have used that since then, installing under
$HOME/eclipse/ (I am the only user on these debian systems anyway).

"error: Unmet build dependencies: maven default-jdk (>= 2:1.8)" when running dpkg-buildpackage

[Steinar Bang]

Build system configuration: debian 10.2 "buster", amd64
openjdk-11-jdk 11.0.5+10-1~deb10u1
openjdk-8-jdk 8u222-b10-1~deb9u1
apache maven 3.6.2 (installed from tar-ball, not 
from deb package)

I'm trying to build karaf 4.2.7 using my karaf debian package project,
 https://github.com/steinarb/karaf-debian
but I get errors when running dpkg-build package:
 sb@lorenzo:~/git/karaf-debian$ dpkg-buildpackage
 dpkg-buildpackage: info: source package apache-karaf
 dpkg-buildpackage: info: source version 0-0
 dpkg-buildpackage: info: source distribution UNRELEASED
 dpkg-buildpackage: info: source changed by Steinar Bang 
 dpkg-buildpackage: info: host architecture amd64
  dpkg-source --before-build .
 dpkg-checkbuilddeps: error: Unmet build dependencies: maven default-jdk (>= 
2:1.8)
 dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
 dpkg-buildpackage: warning: (Use -d flag to override.)
 sb@lorenzo:~/git/karaf-debian$

I have tried the following:
 1. Switching to openjdk-8 as the default JDK
 2. Set JAVA_HOME pointing to /usr/lib/jvm/java-8-openjdk-amd64
 3. Removing JAVA_HOME and switching back to opendjdk-11 as the default JDK 

But they all make dpkg-buildpackage fail with the same error.

Does anyone know what's the underlying error?

Thanks!

Re: Bug#896708: ITP: maven-cache-cleanup -- Utility to purge timestamped snapshots from Maven repositories

[Steinar Bang]

> Emmanuel Bourg :

> Package: wnpp
> Severity: wishlist
> Owner: Emmanuel Bourg 

> * Package name: maven-cache-cleanup
>   Version : 1.0.4
>   Upstream Author : Yuri Nadestin
> * URL : https://github.com/nadestin/tools
> * License : Apache-2.0
>   Programming Lang: Java
>   Description : Utility to purge timestamped snapshots from Maven 
> repositories

> Maven 3 dropped support for non-unique snapshot versions, which had the
> side effect of filling up Maven caches on developer machines and on CI
> build hosts. The Maven Cache Cleanup utility scans a specified Maven cache
> directory for snapshot versions and deletes all but the latest version of
> the timestamped artifacts.

Hm... just a side observation: I ended up writing something similar
myself, a very simple one:
 https://github.com/steinarb/maven-repository-snapshot-pruner

I use it to prune snapshots from my own maven repository.

My entry level VPS (Virtual Private Server) in the cloud, wasn't big
enough to run nexus in addition to its other stuff. So I set up a simple
maven repository, using ftp to deploy to a directory structure, with
nginx serving up the same structure in HTTP.

And since what I'm mainly deploying to this maven repository is
snapshots, and what I want is just a single snapshot, I wrote the above
utility. 

Re: Summary: the state of the karaf debian package

[Steinar Bang]

I have posted an update to the RFP bug describing the latest
fixes/improvements made to the karaf debian package:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881297#40

The following fixes/improvements have been made:
 1. I've run lintian with the following argument and fixed all of the
complaints:
 lintian -vIiE --pedantic --color=auto karaf*.changes 
karaf_4.1.4-10~9.30_all.deb

 2. I've corrected the ownership of /etc/karaf:
- The ownership has been changed from karaf.karaf to root.karaf
- The mode has been set to 2770 on /etc/karaf/ itself (karaf,
  running as user karaf, must be allowed to create new .cfg files in
  this directory)
- Set ownership root.karaf and mode 2750 on all files in /etc/karaf/
  except for the .cfg files and config.properties
- Set ownership karaf.karaf and mode 2770 on all of the .cfg files
  and config.properties, because karaf needs to be able to write to
  them

 3. Moved KARAF_HOME to /var/lib/karaf and let /usr/share/karaf/ have
ownership root.root.
$KARAF_HOME/bin, $KARAF_HOME/lib and $KARAF_HOME/system are all
symlinks to /usr/share/karaf/

 4. Added SYSV init.d files
Note: these are not extensively tested, because the only way I had
to test them was to build .deb packages with the systemd stuff
removed and try to install them and see that the daemon started, and
that was a lot of work

 5. Moved karaf.log from $KARAF_DATA/log/ to /var/log/karaf/

 6. Bumped the upstream karaf version from 4.1.4 to 4.1.5

Re: Summary: the state of the karaf debian package

[Steinar Bang]

>>>>> Steinar Bang :

> I believe the following steps are needed to make this an official
> package:
>  1. Replace the remaining non-karaf boot jars with debian packages,
> these packages are:
> a. apache felix framework 5.6.10
>- Already a debian package, but currently in version 4.6.12 in
>  stretch, testing and unstable [3]

I've filed a bug to have this updated:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890143

> b. apache felix metatype 1.1.6 [4]

I've filed an RFP for this package:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890144

> c. apache felix configadmin 1.8.16 [5]

I've filed an RFP for this package:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890145

> d. apache felix file install 3.6.4 [6]

I've filed an RFP for this package:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890146

> e. OPS4J PAX URL Aether 2.5.3 [7]

I've filed an RFP for the parentt projec for this package:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890181

> f. OPS4J PAX Logging API 1.10.1 [8]
> g. OPS4J PAX Logging Log4J2 1.10.1 [9]

I've filed an RFP for the parent project for these two packages:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890182

Re: Summary: the state of the karaf debian package

[Steinar Bang]

>>>>> Thorsten Glaser :

> Hi Steinar,
> congratulations on getting this far, that’s a nontrivial
> amount of work!

Thanks! :-)

> On Thu, 1 Feb 2018, Steinar Bang wrote:

>> 4. lintian no longer gives any warnings on the package (I have only run
>> lintian with "lintian karaf_xxx.deb", I haven't tried with any
>> arguments)

> You want "lintian -vIiE --pedantic --color=auto karaf*.changes" normally.

Ok, I will try that.

>> 6. A karaf service is added to systemd, running as user karaf and

> Does it work without systemd?

Hm... do you mean being started from the command line, or with SYSV
script instead of systemd?

Karaf by itself works fine without being started by systemd or SYSV init
for that matter.  Karaf can be started from the command line and result
in the same console one sees when SSHing in.

But the way I've packaged it the start from command line behaviour isn't
easily accessible (and also easily combined with the daemon behaviour,
ie. diretories owned by user karaf.  A karaf started from the command
line is typically used for development and run as the developers user).

I don't much like systemd myself.  But I just figured "if there are two
alternatives, pick one, and pick the one most likely to be used in the
future".

Switching to SYSV wouldn't be hard (copy the SYSV scripts from the
source tarball and remove the disabing of SYSV maintscript generation,
and remove the use of systemd).

What's preferred from a debian viewpoint? SYSV? Or systemd?

>> logging to /var/log/syslog and using the following directories:
>> KARAF_ETC = /etc/karaf/
>> KARAF_HOME = /usr/share/karaf/
>> KARAF_DATA = /var/lib/karaf/data/
>> all directories are owned by user karaf, group karaf

> /etc/karaf should be root-owned. If it contains secrets,
> then root:karaf 2750, otherwise root:root 755.

The directory has to be karaf-writable, because karaf allows
configuration changes from the karaf console command line as well as
from the API.

There is one file that contains secrets (and that file does not have to
be writable by karaf, I think.  But it has to be readable by karaf).

Applications may create their own configuration files in this directory,
so karaf needs to be allowed to create new files here.

> /usr/share/karaf MUST be root-owned, it is NOT writable
> during normal system operation (admins MAY mount /usr as
> read-only filesystem).

Hm... that's harder.  Karaf creates stuff under $KARAF_HOME/instances/

One way of doing it would be to switch KARAF_HOME to /var/lib/karaf/

But there are stuff in KARAF_HOME that are read-only: the jar files (or
symlinks to jar files) in $KARAF_HOME/lib and $KARAF_HOME/system.

Would it be proper to install these under /var/lib/karaf/?  Or would it
be best to leave them where they are, under /usr/share/karaf but to
create symlinks to them from /var/lib/karaf/ ?

>> IMO I'm not sure if this is worth the effort, because the karaf jar
>> files aren't really meaningful outside of karaf, or in a version
>> independent manner

> I agree. So I guess it boils down to packaging all libraries
> used to run karaf so it doesn’t use anything that’s not in
> Debian (otherwise, it’s at best usable in the contrib suite).

Ok on that. :-)

>> Thanks in advance to anyone who will create an official debian package,
>> whether it is based on my package or not! :-)

> Why not you, as part of the team, getting help from other
> team members, and someone sponsoring your uploads? You’re
> a user, so you can actually test changes and new versions;
> the rest is just mentoring you and doesn’t use it themselves.

Ok, I will try to create an official state package, when/if the
dependencies becomes available (and maintain it going forward, if noone
else wants to).

> Also: I’m impressed with the amount of work you did to
> document this all! Hats off.

Thanks! :-)

It was actually quite fun.  And also easier to use the standard debian
tools than fpm that was used to package the package I found and forked
when googling for "karaf debian package", back in November 2016.

(I guess it helped that I was familiar with make and GNUMakefile syntax
so that the debian/rules file syntax wasn't a mystery).

Summary: the state of the karaf debian package

[Steinar Bang]

My karaf debian package[1] is now in a state where it does what I need
for my own use.  I'm serving it from my own unofficial APT repository
(which I will discontinue if the RFP[2] results in an official karaf
package).

I don't plan to do any more work on this packaging, except what is
needed to make new stable karaf releases run (ie. I will roll a new
version of the package when karaf 4.1.5 is out).

I'm leaving some notes on the current state of the packaging here
(ie. in the mailing list archives) in case someone wants to use this
package as a starter for an official package.  I will send a message to
the RFP with the same information.

The current state of the karaf debian package, is:
 1. The package is created using native debian packaging tools

 2. The package is built from the source tarball of karaf releases

 3. The source is built with maven and openjdk-8

 4. lintian no longer gives any warnings on the package (I have only run
lintian with "lintian karaf_xxx.deb", I haven't tried with any
arguments)

 5. The package creates a system user named karaf, with group karaf, and
home directory /var/lib/karaf

 6. A karaf service is added to systemd, running as user karaf and
logging to /var/log/syslog and using the following directories:
 KARAF_ETC = /etc/karaf/
 KARAF_HOME = /usr/share/karaf/
 KARAF_DATA = /var/lib/karaf/data/
all directories are owned by user karaf, group karaf

 7. The karaf package works with "apt-get dist-upgrade", config changes
in KARAF_ETC gets the usual APT dialog on modified config change
(ie. "user the package maintainer's version or the modified file
from the old version?), the karaf cache is flushed during an
upgrade, which means that all installed features are lost and must
be reinstalled, contents in KARAF_ETC not installed by the karaf
package is untouched

 8. Those karaf boot requirements that could be satisfied by current
debian stable (debian 9, stretch) uses debian dependencies:
 - Java 8 RE
 - OSGi core 6
 - libjna-java (not strictly needed, but part of the boot directory)
 - libjansi-java
   - This one can be used as a pattern for how to setup
 startup.properties dependencies, the changes are[3]
 a. Add a debian dependency to the control file
 b. Replace the jansi version number with "debian" in
$KARAF_ETC/startup.properties
 c. Remove jansi from the $KARAF_HOME/system maven repository
 d. Symlink the "debian" version from debian's maven repository
into the $KARAF_HOME/system repository
 
 9. The jar files that make up karaf are structured as a maven
repository under $KARAF_HOME/system

10. The initial boot is done from the jar files found in
$KARAF_HOME/lib/boot/ (I have replaced non-karaf dependencies here
with symlinks to the jar files of debian packages)

11. The jar files needed to boot to a state where karaf can start
downloading dependencies from maven central (or other maven
repositories), are listed in $KARAF_ETC/startup.properties

12. The $KARAF_HOME/system maven repository has been cleaned for files
not built by source that aren't needed for karaf boot.  The
non-karaf jar files currently in there are needed for boot, and
cannot be satisfied by existing debian java packages


I believe the following steps are needed to make this an official
package:
 1. Replace the remaining non-karaf boot jars with debian packages,
these packages are:
a. apache felix framework 5.6.10
   - Already a debian package, but currently in version 4.6.12 in
 stretch, testing and unstable [4]
b. apache felix metatype 1.1.6 [5]
c. apache felix configadmin 1.8.16 [6]
d. apache felix file install 3.6.4 [7]
e. OPS4J PAX URL Aether 2.5.3 [8]
f. OPS4J PAX Logging API 1.10.1 [9]
g. OPS4J PAX Logging Log4J2 1.10.1 [10]
 2. Restructure karaf into two packages, karaf and libkaraf-java, with
libkaraf-java containing the jar files structured like debian java
packages (ie. in /usr/share/maven-repo both with their actual
version and with the "debian" version).
IMO I'm not sure if this is worth the effort, because the karaf jar
files aren't really meaningful outside of karaf, or in a version
independent manner


Thanks in advance to anyone who will create an official debian package,
whether it is based on my package or not! :-)


- Steinar


References:
 [1] 
 [2] 
 [3] 

 [4] 
 [5] 

 [6] 

 [7] 

Re: Is it possible to run maven from a postinst mainscript?

[Steinar Bang]

> Emmanuel Bourg :

>> 1. Some of the dependencies aren't available as debian packages

> They'll have to be packaged. What libraries are missing?

The non-karaf packages needed for boot, are:
 mvn:org.apache.felix/org.apache.felix.metatype/1.1.6
 mvn:org.ops4j.pax.url/pax-url-aether/2.5.3
 mvn:org.fusesource.jansi/jansi/1.16
 mvn:org.ops4j.pax.logging/pax-logging-api/1.10.1
 mvn:org.ops4j.pax.logging/pax-logging-log4j2/1.10.1
 mvn:org.apache.felix/org.apache.felix.configadmin/1.8.16
 mvn:org.apache.felix/org.apache.felix.fileinstall/3.6.4

>> 2. Some are packaged in debian, but in a different, and incompatible
>> version to what karaf needs (e.g. libfelix-framework-java)

> These packages will have to be upgraded.

I was a bit quick here.  libfelix-framework-java isn't needed for the
boot, can be removed from the system default repository, and will be
downloaded as needed to ~karaf/.m2/repository/

The packages that exist:
 libjansi-java (1.14 in stable, 1.16 in testing, so that's OK)

But that's the only one as far I can tell.

The OPS4J packages come from here
 https://github.com/ops4j/org.ops4j.pax.logging
 https://github.com/ops4j/org.ops4j.pax.url

The maven build artifacts from releases are pushed to maven central, but
I don't know if the source tarballs are available from anywhere.

The OPS4J license is Apache-2.0.

The Apache felix projects for the final three bundles, are:
 
http://felix.apache.org/documentation/subprojects/apache-felix-metatype-service.html
 
http://felix.apache.org/documentation/subprojects/apache-felix-config-admin.html
 
http://felix.apache.org/documentation/subprojects/apache-felix-file-install.html

All of the felix subproject are available as source tarballs.

Is it possible to run maven from a postinst mainscript?

[Steinar Bang]

I am working on a debian package for apache karaf:
  https://github.com/steinarb/karaf-debian

Karaf has an area, called the "system" default repository, containing
jar files structured like a maven repository.

This repository contains all of the karaf modules, some maven
dependencies needed for karaf boot, and some maven dependencies needed
later.

I'm currently in the process of slimming down the "system" default
repository, by removing all dependencies that are needed post boot.  If
needed, karaf can download them from maven central.

I have already removed a dependency that always will be needed, but that
isn't needed for the boot phase, the apache sshd, and that worked fine:
  
https://github.com/steinarb/karaf-debian/commit/eb9aff77f5355621c6ba48b5dbd65d3ef2377ee2

Installing this version worked fine, and had an sshd running just after
karaf start, and pulled the sshd dependency into ~karaf/.m2/repository/
(I checked before install that it wasn't there, and verfied after
install that it now was in place).

But the problems appear when I get to the maven dependencies that are
needed for the boot.

In an ideal world these dependencies would be provided by debian
packages and fetched from /usr/share/maven-repository/.

But:
 1. Some of the dependencies aren't available as debian packages
 2. Some are packaged in debian, but in a different, and incompatible
version to what karaf needs (e.g. libfelix-framework-java)

So I have to choose a different route.

What I would like to do, is to have the postinst script populate the
missing jars into the system default repository using maven and the
maven-dependency-plugin.

To do this I need to have a pom.xml that is used by the postinst
script.  Is there a place where this pom.xml could live?  Is there a
convention for where to put support files needed by mainscripts?

Thanks!


- Steinar

Re: Do transitive dependencies need to be specified in the control file?

[Steinar Bang]

>>>>> Steinar Bang :

> I thought the unmet dependency was libjna-jni that was added by
> 'apt --fix-broken install'? And that this was a transitive depdenency? 

I removed the versions from libjna-java and libjna-platform-java in
Depends in the control file:
 Depends: adduser, default-jre (>=2:1.8), libosgi-core-java (>=6), libjna-java, 
libjna-platform-java

After removing the versions and building a new package with
dpkg-buildpackage, then apt-get managed to resolve the transient
dependencies even from my improvised /tmp repo:
 root@lorenzo:~# apt-get install karaf
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 The following additional packages will be installed:
   libjna-java libjna-jni libjna-platform-java
 Suggested packages:
   libjna-java-doc
 The following NEW packages will be installed:
   karaf libjna-java libjna-jni libjna-platform-java
 0 upgraded, 4 newly installed, 0 to remove and 13 not upgraded.
 Need to get 968 kB/23.8 MB of archives.
 After this operation, 30.8 MB of additional disk space will be used.
 Do you want to continue? [Y/n]

Re: Do transitive dependencies need to be specified in the control file?

[Steinar Bang]

> Markus Koschany :
>> I tried adding two dependencies, libjna-java and libjna-platform-java to the 
>> debian/control file:
>> Depends: adduser, default-jre (>=1.8), libosgi-core-java (>=6), libjna-java 
>> (>=4.2.2), libjna-platform-java (>=4.2.2)
>  ^^
> This should be >= 2:1.8 (note the epoch) otherwise even a Java 7 JDK
> would satisfy this dependency.

Thanks! I will correct that.
>> The following packages have unmet dependencies:
>> karaf : Depends: libjna-java (>= 4.2.2) but it is not going to be installed
>> Depends: libjna-platform-java (>= 4.2.2) but it is not going to be installed
>> E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or 
>> specify a solution).
>> root@lorenzo:~#

> The versions for libjna-java (>= 4.2.2) and libjna-platform-java (>=
> 4.2.2) are already present in Stretch, so if you declare these
> dependencies in debian/control they should be downloaded automatically.
> I assume this error message is caused by your special build environment.

I thought the unmet dependency was libjna-jni that was added by
'apt --fix-broken install'? And that this was a transitive depdenency? 

Re: How should the systemd setup in a postinst script look?

[Steinar Bang]

>>>>> Emmanuel Bourg :

> Le 26/01/2018 à 19:26, Steinar Bang a écrit :
>> W: karaf: codeless-jar 
>> usr/share/karaf/system/org/apache/aries/blueprint/org.apache.aries.blueprint.core.compatibility/1.0.0/org.apache.aries.blueprint.core.compatibility-1.0.0.jar

> You can ignore this one, this jar has indeed no .class file in Maven
> Central.

Ah! That's what the message meant?

I thought this was a complaint about the jar not being built from
source, and wondered why there weren't more...

>> W: karaf: codeless-jar 
>> usr/share/karaf/system/org/apache/karaf/demos/4.1.4/demos-4.1.4.jar

> This one isn't empty on Maven Central, but maybe the demos don't have to
> be installed anyway.

Probably not.

The current git version of the package skips both demos and itests, but
the demos.jar is still present (and empty) in the .deb package.

 https://github.com/steinarb/karaf-debian

Do transitive dependencies need to be specified in the control file?

[Steinar Bang]

Working on my karaf debian package
 https://github.com/steinarb/karaf-debian

I tried adding two dependencies, libjna-java and libjna-platform-java to the 
debian/control file:
Depends: adduser, default-jre (>=1.8), libosgi-core-java (>=6), libjna-java 
(>=4.2.2), libjna-platform-java (>=4.2.2)

However, that wasn't enough to make apt-get pull in the dependencies:
 root@lorenzo:~# apt-get install karaf
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 karaf is already the newest version (4.1.4-9~9.30).
 You might want to run 'apt --fix-broken install' to correct these.
 The following packages have unmet dependencies:
  karaf : Depends: libjna-java (>= 4.2.2) but it is not going to be installed
  Depends: libjna-platform-java (>= 4.2.2) but it is not going to be 
installed
 E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or 
specify a solution).
 root@lorenzo:~#

I tried the suggested command and it added libjna-jni as a dependency to
be installed:
 Reading package lists... Done
 Building dependency tree   
 Reading state information... Done
 Correcting dependencies... Done
 The following additional packages will be installed:
   libjna-java libjna-jni libjna-platform-java
 Suggested packages:
   libjna-java-doc
 The following NEW packages will be installed:
   libjna-java libjna-jni libjna-platform-java
 0 upgraded, 3 newly installed, 0 to remove and 13 not upgraded.
 1 not fully installed or removed.
 Need to get 968 kB of archives.
 After this operation, 1,231 kB of additional disk space will be used.
 Do you want to continue? [Y/n] n
 Abort.
 root@lorenzo:~#

Do I need to add transitive dependencies to my control file? (I thought
APT took care of that...?)

Or is this an artifact of the faked "repo" I use to test my package?

I have this in /etc/apt/sources.list:
 deb file:///tmp repo/

I add new version of my package there by:
 mv ~/git/karaf_4.1.4-9~9.30_all.deb /tmp/repo
 (cd /tmp; dpkg-scanpackages repo >repo/Packages)

Is this simple faked APT repo the reason apt-get can't resolve the
libjna-jni dependency without help?

Thanks!


- Steinar

Re: How should the systemd setup in a postinst script look?

[Steinar Bang]

>>>>> Steinar Bang :

> However, lintian aren't happy with the results:
>  sb@lorenzo:~/git/karaf-debian$ lintian ~/git/karaf_4.1.4-8~9.30_all.deb 
>  W: karaf: init.d-script-not-marked-as-conffile etc/init.d/karaf
>  E: karaf: init.d-script-not-included-in-package etc/init.d/karaf
[snip!]
> There isn't any debian/karaf/etc/init.d/ directory which means that no
> init.d script was created automatically, and it looks like the packaging
> tools expected an init.d script to be supplied...?

I googled and found this:
 https://askubuntu.com/a/943226

I added this to the debian/rules file and then the SysV init.d stuff
went away from the generated maintscripts:
 https://github.com/steinarb/karaf-debian/blob/master/debian/rules#L41

Problem solved! :-)

Re: How should the systemd setup in a postinst script look?

[Steinar Bang]

>>>>> Steinar Bang :

>  4. Changed the "%:" rule of debian/rules to be
>  dh $@ --with systemd

I figured out the problem, I had this
%:
dh $@ --with-systemd

instead of this:
%:
dh $@ --with systemd

Now I again get a .deb package with a daemon that starts after
installation and stops on uninstallation.

However, lintian aren't happy with the results:
 sb@lorenzo:~/git/karaf-debian$ lintian ~/git/karaf_4.1.4-8~9.30_all.deb 
 W: karaf: init.d-script-not-marked-as-conffile etc/init.d/karaf
 E: karaf: init.d-script-not-included-in-package etc/init.d/karaf
 W: karaf: codeless-jar 
usr/share/karaf/system/org/apache/aries/blueprint/org.apache.aries.blueprint.core.compatibility/1.0.0/org.apache.aries.blueprint.core.compatibility-1.0.0.jar
 W: karaf: codeless-jar 
usr/share/karaf/system/org/apache/karaf/demos/4.1.4/demos-4.1.4.jar
 sb@lorenzo:~/git/karaf-debian$

There isn't any debian/karaf/etc/init.d/ directory which means that no
init.d script was created automatically, and it looks like the packaging
tools expected an init.d script to be supplied...?

Do I need both a SYSV init.d script and as well as the karaf.system file?

Re: How should the systemd setup in a postinst script look?

[Steinar Bang]

> Eugene Zhukov :

> The service will be enabled and started automatically upon package
> install, you don't need to do that.

> Just put your .service file into debian/ folder and the
> rest will be handled by Debian tools.
> The line in debian/rules quoted below is also needed. Don't forget to
> add dh-systemd into build-depends of your package.

Thanks!

I did the following:
 1. Moved the karaf.service file to the debian/ directory
 2. Made build-depend to version 10 or larger of debhelper
 3. Removed all systemd enabling, start, update and purge from
debian/karaf.postinst and debian/karaf.postrm 
 4. Changed the "%:" rule of debian/rules to be
 dh $@ --with systemd

Then I ran dpkg-buildpackage

Then I ran lintian on the package:
 sb@lorenzo:~/git/karaf-debian$ lintian ~/git/karaf_4.1.4-8~9.30_all.deb 
 W: karaf: init.d-script-not-marked-as-conffile etc/init.d/karaf
 E: karaf: init.d-script-not-included-in-package etc/init.d/karaf
 W: karaf: codeless-jar 
usr/share/karaf/system/org/apache/aries/blueprint/org.apache.aries.blueprint.core.compatibility/1.0.0/org.apache.aries.blueprint.core.compatibility-1.0.0.jar
 W: karaf: codeless-jar 
usr/share/karaf/system/org/apache/karaf/demos/4.1.4/demos-4.1.4.jar
 sb@lorenzo:~/git/karaf-debian$

(Note: I'm not concerned with the codeless jars right now.  That's for
later. There are more of them than the two jars reported above...)

When I look in the debian/directory, there are some new files with
extension .debhelper:
   ...
  -rw-r--r-- 1 sb sb  560 Jan 26 17:14 karaf.postinst
  -rw-r--r-- 1 sb sb  257 Jan 26 17:18 karaf.postinst.debhelper
  -rw-r--r-- 1 sb sb  274 Jan 26 17:15 karaf.postrm
  -rw-r--r-- 1 sb sb  340 Jan 26 17:18 karaf.postrm.debhelper
  -rw-r--r-- 1 sb sb  690 Jan 22 22:23 karaf.prerm
  -rw-r--r-- 1 sb sb  148 Jan 26 17:18 karaf.prerm.debhelper
  -rw-r--r-- 1 sb sb 1151 Jan 25 20:23 karaf.service
  ...

Looking at the karaf.postinst.debhelper script it tries to create a SYSV
service for karaf:
 # Automatically added by dh_installinit
 if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ]; then
if [ -x "/etc/init.d/karaf" ]; then
update-rc.d karaf defaults >/dev/null
invoke-rc.d karaf start || exit $?
fi
 fi
 # End automatically added section

What am I missing?

The karaf.postrm.debhelper removes a SYSV initd service in purge, and
does a "systemctl --system daemon-reload" after that (ie. for all
invocations of the script).

The karaf.prerm.debhelper stops a SYSV initd service.

Thanks in advance, for pointers and hints to what I'm doing wrong.


- Steinar


PS Since they didn't work as expected, I haven't yet pushed my latest changes to
 https://github.com/steinarb/karaf-debian

How should the systemd setup in a postinst script look?

[Steinar Bang]

I am trying to get rid of the lintian messages of my apache karaf debian
package:
 https://github.com/steinarb/karaf-debian

One of the warnings still present, is:
 W: karaf: maintainer-script-calls-systemctl postinst:30

The relevant part of the script, is:
 case "$1" in
 configure)
 create_daemon_user
 change_karaf_files_ownership
 deb-systemd-helper enable karaf.service
 systemctl daemon-reload
 systemctl start karaf
 echo "Started karaf daemon"
 ;;
 esac

By experimentation I've found that I need both the "systemctl
daemon-reload" and the "systemctl start karaf",
and I don't know how to
replace this with the recommended dh_systemd_enable and
dh_systemd_start.

And what should I do about "deb-systemd-helper enable karaf.service"?

Remove it?

Is none of this needed if I change the default rule in the rules file to this?

%:
dh $@ --with systemd

This is from the "Pragmatic Debian Packaging" article:
 https://vincent.bernat.im/en/blog/2016-pragmatic-debian-packaging

Thanks!


- Steinar

Re: dpkg-buildpackage mvn command tries to use /root/.m2/repository

[Steinar Bang]

> Markus Koschany :

>> until mh_make eventually failed with the following error message:
>> Checking the parent dependency in the sub project itests/pom.xml
>> Analysing manual/pom.xml...

> I suggest to ignore this sub project for now (sounds like it is only
> needed for tests anyway). If you get more errors ignore even more
> modules until mh_make succeeds. Then you can start over again and add
> those modules you really need step by step.

I tried, but it was very strange.

The "manual" module wasn't in  in the top POM of the unpacked
apache-karaf-4.1.4-src.tar.gz 

I first tried removing all of the "unnecessary" modules from 
in the top pom of karaf 4.1.3, ie.
demos
archetypes
itests

But that didn't help.  I still got the same error.

I then did:
 rm -rf demos
 rm -rf archetypes
 rm -rf itests
 rm -rf manual

But I *still* got the same error from mh_make.

I guess I need to start with a fresh source tarball unpack _and_ delete
~/.m2/repository, remove the "unneccessary" modules and subdirectries,
and try running mh_make again and see what happens.

> I would also use option 1 (change the version to the symbolic "debian"
> version). Otherwise the dependencies would be very strict which makes it
> more difficult to upgrade possible reverse-dependencies in the future.

I'm sure this is good advice in the general case.  But in the case of
karaf, the jars aren't intended for use outside karaf (at least, most of
the URLs).  And for karaf itself, all of the bundles of a particular
version belong together, and a karaf instance should not use bundles
from a different karaf version.

(I think (actually: "I guess"...) the reason karaf consists of so many
jars, is that it makes it possible for karaf to load and unload the
stuff at runtime, and not load things that aren't needed.)

Re: dpkg-buildpackage mvn command tries to use /root/.m2/repository

[Steinar Bang]

>>>>> Steinar Bang :

> Outline of the plan
>  1. Download the sources and build them with maven (this is where I'm now)
>  2. Create the directories that will receive the built karaf stuff:
>  mkdir -p /etc/karaf
>  mkdir -p /usr/share/karaf
>  mkdir -p /var/lib/karaf
>  3. Move the built stuff in 
> unpacked-src/assemblies/apache-karaf/target/assembly
> to the appropriate places the final structure
> a. mv unpacked-src/assemblies/apache-karaf/target/assembly/bin to 
> /usr/share/karaf
> b. mv unpacked-src/assemblies/apache-karaf/target/assembly/data to 
> /var/lib/karaf
> c. mv unpacked-src/assemblies/apache-karaf/target/assembly/deploy to 
> /var/lib/karaf
> d. mv unpacked-src/assemblies/apache-karaf/target/assembly/etc/* to 
> /etc/karaf
> e. mv unpacked-src/assemblies/apache-karaf/target/assembly/lib to 
> /usr/share/karaf
> f. mv unpacked-src/assemblies/apache-karaf/target/assembly/system to 
> /usr/share/karaf
>  4. Create a systemd config that sets up the appropriate environment 
> variables before 
> starting the karaf daemon
>   KARAF_BASE=/usr/share/karaf
>   KARAF_ETC=/etc/karaf
>   KARAF_DATA=/var/lib/karaf/data
>  5. Create postinst and postrm scripts that creates/removes a karaf user
> (and group) and sets up and removes the systemd daemon
>  6. Replace all of the non org.apache.karaf.*.jar needed for boot with
> deb dependencies
>  7. Move the org.apache.karaf.*.jar part of /usr/share/karaf/system to
> /usr/share/maven-repository and use this as the system repo in karaf

> After point 5 in this, there will hopefully be a running
> non-debian-package compliant karaf that's installable by a debian
> package (ie. about the same level of functionality as my current fpm
> based package, but built from sources instead of the binary tar-ball and
> using the debian tools).

I've now have a working package that is at step 5, ie. at the same level
as the fpm package I've been using up until now.
  https://github.com/steinarb/karaf-debian

Improvments wrt. the fpm package:
 1. Built from the apache karaf src tar-ball instead of the binary
tar-ball
 2. Built using the standard debian packaging tools

It's also a bit simpler.  I used the systemd template of the karaf
distribution as a basis for the systemd file (so now the KARAF_DATA
directory actually works the way it was supposed to do).

I also wrote the maintscripts from scratch, making them a lot simpler
than the ones in the fpm package.

Re: dpkg-buildpackage mvn command tries to use /root/.m2/repository

[Steinar Bang]

> Emmanuel Bourg :

> Ok, I suggest reading the excellent article from Markus about mh_make,
> the Vincent's tutorial is a good introduction but it isn't really suited
> to Java based projects.

> https://gambaru.de/blog/2017/08/02/pdfsam-how-to-upgrade-a-maven-application-for-debian/

Thanks for the pointer. I'm reading it now.

> The rules file you posted disables the build target, there is no chance
> it could work.

Ah, OK.

I will study more closesly what I actually have done in the script,
instead of just pasting in stuff from howtos (I will try both this track
and the mh_make track to see what seems like way that most probably will
take me to a deb-installed running karaf).

>> There are 34 org.apache.karaf.*.jar files built from the karaf sources,
>> and creating individual .deb packages for all of them seems like a lot of 
>> work.

> You don't have to do that. Just put all the karaf jar files in a
> libkaraf-java package, and put the other files required to run the
> server in a karaf package. You can start with the karaf source package
> building only two binary packages (karaf and libkaraf-java, the former
> depending on the later).

> I recommend looking at the jetty9 package for an example. That's the
> package closest to the structure of karaf (multi module Maven project
> building a daemon, with no systemd unit file yet though).

Ok, I will study what the jetty9 package does.

Re: dpkg-buildpackage mvn command tries to use /root/.m2/repository

[Steinar Bang]

>>>>> Steinar Bang :

> I can try running mh_make, but as this is a multi-module project with
> lots of non-standard maven stuff, most of the examples I've been able to
> google up hasn't.

I tried running mh_make, told it to
 - Use "karaf" for the source package name
 - Use "karaf" for the binary package name
 - Not run tests
 - Not build javadoc
 - Keep the distro version (ie. in this case 4.1.4)
 - Build all modules

Then I stepped through all of the modules (quite a few, lost count),
telling them to 
[2] - Keep the version
until mh_make eventually failed with the following error message:
 Checking the parent dependency in the sub project itests/pom.xml
 Analysing manual/pom.xml...
 Jan 20, 2018 11:12:01 AM org.debian.maven.packager.DependenciesSolver 
resolveDependencies
 SEVERE: Error while resolving ./manual/pom.xml: Dependency not found 
org.apache.karaf:karaf:pom:4.1.3-SNAPSHOT
 Jan 20, 2018 11:12:01 AM org.debian.maven.packager.DependenciesSolver 
resolveDependencies
 SEVERE: 
 org.debian.maven.repo.DependencyNotFoundException: Dependency not found 
org.apache.karaf:karaf:pom:4.1.3-SNAPSHOT
at org.debian.maven.repo.Repository.registerPom(Repository.java:414)
at 
org.debian.maven.packager.DependenciesSolver.resolveDependencies(DependenciesSolver.java:321)
at 
org.debian.maven.packager.DependenciesSolver.resolveDependencies(DependenciesSolver.java:421)
at 
org.debian.maven.packager.DependenciesSolver.solveDependencies(DependenciesSolver.java:261)
at 
org.debian.maven.packager.DependenciesSolver.main(DependenciesSolver.java:962)

(hm... that actually looks like an issue with the karaf release: some
modules haven't haved their parent version bumbed as part of the
release.  Perhaps mh_make scans modules not part of the  of the
parent?)

Re: dpkg-buildpackage mvn command tries to use /root/.m2/repository

[Steinar Bang]

> Emmanuel Bourg :

> The rules file disables most of the targets, that looks wrong. Did you
> generate the package with mh_make from maven-debian-helper?

No, I startet with creating files as in this article
  https://vincent.bernat.im/en/blog/2016-pragmatic-debian-packaging

I can try running mh_make, but as this is a multi-module project with
lots of non-standard maven stuff, most of the examples I've been able to
google up hasn't.

But the problem I have isn't really related to the structure of the
rules file, I think.  The problem is that dpkg-buildpackage thinks $HOME
is "/root" and that user "sb" doesn't have write access to root.

> If you share the repository on GitHub I'll get a look.

I will share it on github eventually but I'm still working on my first
commit. :-)

> I suggest running mh_make and selecting only the first core karaf
> modules, and then enabling more modules gradually as needed.

Actually I planned to go the other way: first build karaf, and then move
the files where they should go.

Outline of the plan
 1. Download the sources and build them with maven (this is where I'm now)
 2. Create the directories that will receive the built karaf stuff:
 mkdir -p /etc/karaf
 mkdir -p /usr/share/karaf
 mkdir -p /var/lib/karaf
 3. Move the built stuff in unpacked-src/assemblies/apache-karaf/target/assembly
to the appropriate places the final structure
a. mv unpacked-src/assemblies/apache-karaf/target/assembly/bin to 
/usr/share/karaf
b. mv unpacked-src/assemblies/apache-karaf/target/assembly/data to 
/var/lib/karaf
c. mv unpacked-src/assemblies/apache-karaf/target/assembly/deploy to 
/var/lib/karaf
d. mv unpacked-src/assemblies/apache-karaf/target/assembly/etc/* to 
/etc/karaf
e. mv unpacked-src/assemblies/apache-karaf/target/assembly/lib to 
/usr/share/karaf
f. mv unpacked-src/assemblies/apache-karaf/target/assembly/system to 
/usr/share/karaf
 4. Create a systemd config that sets up the appropriate environment variables 
before 
starting the karaf daemon
  KARAF_BASE=/usr/share/karaf
  KARAF_ETC=/etc/karaf
  KARAF_DATA=/var/lib/karaf/data
 5. Create postinst and postrm scripts that creates/removes a karaf user
(and group) and sets up and removes the systemd daemon
 6. Replace all of the non org.apache.karaf.*.jar needed for boot with
deb dependencies
 7. Move the org.apache.karaf.*.jar part of /usr/share/karaf/system to
/usr/share/maven-repository and use this as the system repo in karaf

After point 5 in this, there will hopefully be a running
non-debian-package compliant karaf that's installable by a debian
package (ie. about the same level of functionality as my current fpm
based package, but built from sources instead of the binary tar-ball and
using the debian tools).

Point 6 and 7 are for moving this to a more debian-package-compliant
structure.

There are 34 org.apache.karaf.*.jar files built from the karaf sources,
and creating individual .deb packages for all of them seems like a lot of work.

dpkg-buildpackage mvn command tries to use /root/.m2/repository

[Steinar Bang]

When I run "dpkg-buildpackage -us -uc -b" on a packaging area with this
control file
 https://gist.github.com/steinarb/5b0b6d771e2fae3873abac15c21a4f82
it fails with:
 (cd unpacked-src; mvn clean install -DskipTests=true )
 [ERROR] Could not create local repository at /root/.m2/repository -> [Help 1]

I'm running as my own user.

I've tried setting
 export M2_REPO=/home/sb/.m2/repository
but it didn't help.

Do I need to be root to build a debian package? (I thought fakeroot took
care of the path access stuff...?)

Thanks!


- Steinar

Tool for automatically resolving maven depdencies to debian dependencies?

[Steinar Bang]

Is there a tool that can automatically resolve maven dependencies to the
closest matching debian package dependencies?

(The tool doesn't necessarily have to go all the way.  Something that
justs lists the dependencies in a form that can be massaged in a text
editor would still be useful (but of course a fully automated tool would
be best...))

Re: Is it possible to have multiple versions of a java-lib installed?

[Steinar Bang]

>>>>> Emmanuel Bourg :
> Le 17/01/2018 à 23:32, Steinar Bang a écrit :

>> Is pulling the jars in from maven central from maven depdencies
>> acceptable?  Or do they need to be acually built by the packaging
>> project?

> It's ok at run time but not at build time (the packages are built in
> offline mode).

Right.

This is incidentially exactly how karaf works: pulling down runtime
dependencies from maven central (or, potentially, other repos, I have
e.g. used my own[1]) and then loading and starting them.

But karaf needs its boot directory jars and the jars in the
system.properties file (the set of jars discussed earlier in the
thread), locally, before it can start using maven to pull stuff down.


References:
[1] 
<https://github.com/steinarb/ukelonn#oppsett-av-webappen-på-en-server-med-debian-gnulinux>
(Text in Norwegian, but the extra maven repo setup config, is in step 6)
(the deb package mentioned there is my home rolled, non-compliant
package, and I'm trying to replace this with a real debian package)

Re: Is it possible to have multiple versions of a java-lib installed?

[Steinar Bang]

>>>>> Emmanuel Bourg :

> Le 17/01/2018 à 22:44, Steinar Bang a écrit :
>> Would be legal for a karaf debian package to bundle its own version of
>> these jars?

> It's fine as long as they are built from source (i.e. no prebuilt jar
> files in the source package),

Is pulling the jars in from maven central from maven depdencies
acceptable?  Or do they need to be acually built by the packaging
project?

Re: Is it possible to have multiple versions of a java-lib installed?

[Steinar Bang]

One property of karaf: it can load its dependencies using maven.

Ie. it will download its dependencies to ~/.m2/repository and use it
from there.  It doesn't have to be provided by other debian packages.

The question is: how much must be in place for karaf to boot far enough
to start loading files using maven?

I asked on the karaf-users mailing list, and the answer[1] is these in
the boot directory:
>   -rw-r--r-- 1 sb sb 1440500 Dec 15 20:14 jna-4.5.0.jar
>   -rw-r--r-- 1 sb sb 2324986 Dec 15 20:14 jna-platform-4.5.0.jar
>   -rw-r--r-- 1 sb sb   31235 Dec 15 20:14 
> org.apache.karaf.diagnostic.boot-4.1.4.jar
>   -rw-r--r-- 1 sb sb   18181 Dec 15 20:14 
> org.apache.karaf.jaas.boot-4.1.4.jar
>   -rw-r--r-- 1 sb sb  150582 Dec 15 20:14 org.apache.karaf.main-4.1.4.jar
>   -rw-r--r-- 1 sb sb  475256 Dec 15 20:14 org.osgi.core-6.0.0.jar

and these (the contents of etc/startup.properties in the karaf specific
maven URL notation):
 mvn:org.apache.karaf.features/org.apache.karaf.features.extension/4.1.4 = 1
 mvn:org.apache.felix/org.apache.felix.metatype/1.1.6 = 5
 mvn:org.apache.karaf.services/org.apache.karaf.services.eventadmin/4.1.4 = 5
 mvn:org.ops4j.pax.url/pax-url-aether/2.5.3 = 5
 mvn:org.fusesource.jansi/jansi/1.16 = 8
 mvn:org.ops4j.pax.logging/pax-logging-api/1.10.1 = 8
 mvn:org.ops4j.pax.logging/pax-logging-log4j2/1.10.1 = 8
 mvn:org.apache.felix/org.apache.felix.configadmin/1.8.16 = 10
 mvn:org.apache.felix/org.apache.felix.fileinstall/3.6.4 = 11
 mvn:org.apache.karaf.features/org.apache.karaf.features.core/4.1.4 = 15

The org.apache.karaf.* jars won't be in conflict with anything else,
they can be packaged as lib*-java.deb packages and used by the karaf
package.

This leaves the following jars in boot:
   -rw-r--r-- 1 sb sb 1440500 Dec 15 20:14 jna-4.5.0.jar
   -rw-r--r-- 1 sb sb 2324986 Dec 15 20:14 jna-platform-4.5.0.jar
   -rw-r--r-- 1 sb sb  475256 Dec 15 20:14 org.osgi.core-6.0.0.jar

And the following in system:
 mvn:org.apache.felix/org.apache.felix.metatype/1.1.6 = 5
 mvn:org.ops4j.pax.url/pax-url-aether/2.5.3 = 5
 mvn:org.fusesource.jansi/jansi/1.16 = 8
 mvn:org.ops4j.pax.logging/pax-logging-api/1.10.1 = 8
 mvn:org.ops4j.pax.logging/pax-logging-log4j2/1.10.1 = 8
 mvn:org.apache.felix/org.apache.felix.configadmin/1.8.16 = 10
 mvn:org.apache.felix/org.apache.felix.fileinstall/3.6.4 = 11

Would be legal for a karaf debian package to bundle its own version of
these jars?

And since the org.apache.karaf.* boot set jars probably isn't of
interest to other packages than karaf itself, would it be ok to bundle
these as well?


References:
[1] 

Re: Is it possible to have multiple versions of a java-lib installed?

[Steinar Bang]

> Thorsten Glaser :

>> Do you have a compatibility issue with libjna-java?

> … those.

I used it as an example since it's part of the boot set of apache karaf,
which in karaf 4.1.4, is:
  -rw-r--r-- 1 sb sb 1440500 Dec 15 20:14 jna-4.5.0.jar
  -rw-r--r-- 1 sb sb 2324986 Dec 15 20:14 jna-platform-4.5.0.jar
  -rw-r--r-- 1 sb sb   31235 Dec 15 20:14 
org.apache.karaf.diagnostic.boot-4.1.4.jar
  -rw-r--r-- 1 sb sb   18181 Dec 15 20:14 
org.apache.karaf.jaas.boot-4.1.4.jar
  -rw-r--r-- 1 sb sb  150582 Dec 15 20:14 org.apache.karaf.main-4.1.4.jar
  -rw-r--r-- 1 sb sb  475256 Dec 15 20:14 org.osgi.core-6.0.0.jar

jna-lib is currently 4.2.2 in stable, 4.5.1 in testing, and 4.5.1 in
sid.

If I pick something other than 4.5.0, it's no longer karaf 4.1.4 but
something slightly different.

And that's just one of the 84 jars of the 4.1.4 tarball...:-)

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881297#20
for more detail.

Is it possible to have multiple versions of a java-lib installed?

[Steinar Bang]

Is it possible to have multiple versions of a java library, like eg.
 https://packages.debian.org/stretch/libjna-java
installed simultanously?

I guess the non-versioned files would collide...?
(ie. the unversioned jar in /usr/share/java/ and the maven-repo with
version "debian" in /usrshare/maven-repo
 https://packages.debian.org/stretch/all/libjna-java/filelist
)

Re: apache-karaf in Debian

[Steinar Bang]

>>>>> Steinar Bang :
[snip!]
> Karaf has a concept of "local maven repository" that would fit in nicely
> with debian's maven layout under /usr/share/maven-repo/

> Modifying the setting org.ops4j.pax.url.mvn.localRepository in
> /etc/karaf/org.ops4j.pax.url.mvn.cfg, like this:
>  org.ops4j.pax.url.mvn.localRepository = /usr/share/maven-repo

Please disregard! This was bad advice from me.

The local repository needs to be writable.  The default, if not set, is
~/.m2/repository/ and should be left that way.

However, the debian maven layout could be added to the lists
org.ops4j.pax.url.mvn.defaultRepositories or
org.ops4j.pax.url.mvn.repositories (I don't know which one would be most
appropriate.

Both of these settings are in the /etc/karaf/org.ops4j.pax.url.mvn.cfg
file.

Their current values are:
 # A repository url can be appended with zero or more of the following flags:
 #@snapshots  : the repository contains snaphots
 #@noreleases : the repository does not contain any released artifacts
 #
 # The following property value will add the system folder as a repo.
 #
 org.ops4j.pax.url.mvn.defaultRepositories=\
 
file:${karaf.home}/${karaf.default.repository}@id=system.repository@snapshots, \
 file:${karaf.data}/kar@id=kar.repository@multi@snapshots, \
 
file:${karaf.base}/${karaf.default.repository}@id=child.system.repository@snapshots

 org.ops4j.pax.url.mvn.repositories= \
 http://repo1.maven.org/maven2@id=central, \
 
http://repository.apache.org/content/groups/snapshots-group@id=apache@snapshots@noreleases,
 \
 
https://oss.sonatype.org/content/repositories/ops4j-snapshots@id=ops4j.sonatype.snapshots.deploy@snapshots@noreleases

Adding the debian maven-repo would look something like this:
 org.ops4j.pax.url.mvn.defaultRepositories=\
 file:/usr/share/maven-repo@id=debian.repository, \
 
file:${karaf.home}/${karaf.default.repository}@id=system.repository@snapshots, \
 file:${karaf.data}/kar@id=kar.repository@multi@snapshots, \
 
file:${karaf.base}/${karaf.default.repository}@id=child.system.repository@snapshots

Re: apache-karaf in Debian

[Steinar Bang]

Picking up on an old thread.

It would be very nice to get a native debian package of karaf, so I've
opened this RFP:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881297

Karaf is a small OSGi container/applcation server, that has an SSH
daemon, and is provisioned using maven.

Basically, you start the karaf as a daemon, SSH in and meet a command
line that lets you issue commands to pull in applications and their
dependencies using maven.

People familiar with OSGi and the common problems associated with
resolving runtime dependecies will be pleasantly surprised by karaf
features and their resolution mechanism.

Karaf boots from a CLASSPATH containing this set of jars (this is from
karaf 4.1.4) and the rest is pulled in using maven:
  /tmp/apache-karaf-4.1.4/lib/boot:
  total used in directory 4352 available 8069236
  drwxr-xr-x 2 sb sb 180 Dec 15 20:14 .
  drwxr-xr-x 5 sb sb 160 Dec 15 20:14 ..
  -rw-r--r-- 1 sb sb1134 Dec 15 20:14 README
  -rw-r--r-- 1 sb sb 1440500 Dec 15 20:14 jna-4.5.0.jar
  -rw-r--r-- 1 sb sb 2324986 Dec 15 20:14 jna-platform-4.5.0.jar
  -rw-r--r-- 1 sb sb   31235 Dec 15 20:14 
org.apache.karaf.diagnostic.boot-4.1.4.jar
  -rw-r--r-- 1 sb sb   18181 Dec 15 20:14 org.apache.karaf.jaas.boot-4.1.4.jar
  -rw-r--r-- 1 sb sb  150582 Dec 15 20:14 org.apache.karaf.main-4.1.4.jar
  -rw-r--r-- 1 sb sb  475256 Dec 15 20:14 org.osgi.core-6.0.0.jar

Karaf has a concept of "local maven repository" that would fit in nicely
with debian's maven layout under /usr/share/maven-repo/

Modifying the setting org.ops4j.pax.url.mvn.localRepository in
/etc/karaf/org.ops4j.pax.url.mvn.cfg, like this:
 org.ops4j.pax.url.mvn.localRepository = /usr/share/maven-repo

Jaxe in debian?

[Steinar Bang]

http://jaxe.sourceforge.net/

Are anyone planning to package this GPL'd XML Editor?

Thanx!


- Steinar


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Ajp13 connector doesn't start listening on port 8009

[Steinar Bang]

Platform: Intel PIII, debian testing/unstable (sarge)
  Blackdown JDK 1.3.1 (j2sdk 1.3.1.0b-2),
  tomcat4 4.1.16-1,
  apache 1.3.26-1.1, apache-ssl 1.3.26+1.48-2

My problem is that when I do
/etc/init.d/tomcat4 start
there is nothing listening on port 8009.

Or rather: there is _sometimes_ nothing listening on port 8009.

When I have started and stopped tomcat and apache and apache-ssl, I
have sometimes been able to find something listening on port 8009.  I
haven't changed anything in the configuration for this to happen.
Just started and stopped services.  But the listening to port 8009
has gone away as mysteriously as it appeared.

I haven't found anything conclusive in the logs about this.  There
seems to be stuff in /var/log/tomcat4/catalina.out related to Ajp13,
but I can't make sense of it (see log fragments below).

Has anyone else seen this, or similar behaviour?

I have used the commands
lsof | grep 8009
and
telnet localhost 8009
to determine if something is listening to port 8009.

Right now the first return no matches, and the latter prints out:
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused


I have tried both the Coyote Ajp13 connector, with the following in
server.xml:



And the old Ajp13 connector with the following config:



But the behaviour is the same.

I have wondered if there is a problem with both apache and apache-ssl
accessing the same Ajp13 connector in tomcat.  But I've stopped
apache-ssl a while back, and I still haven't seen any change in the
behaviour. 

Thanx!


- Steinar

Log fragments.  

The last things that mention "Ajp" in /var/log/tomcat4/catalina.out:
[...]
2371 [main] INFO common.ChannelSocket  - JK2: ajp13 listening on tcp port 8009
2483 [main] INFO server.JkMain  - Jk running ID=0 time=46/168  
config=/usr/share/tomcat4/conf/jk2.properties
[ Closing connection to 172.21.206.140:2809 ]
[ Closing connection to 127.0.0.1:2809 ]
[ Closing connection to 172.21.206.140:1221 ]
350125 [Thread-4] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
350306 [Thread-12] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
356237 [Thread-12] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
356266 [Thread-4] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
362458 [Thread-4] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
362490 [Thread-12] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
364300 [Thread-6] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
368480 [Thread-11] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
368768 [Thread-4] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
374591 [Thread-12] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
374679 [Thread-11] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
415008 [Thread-5] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
[...]
Call 
org.apache.struts.action.ActionServlet.addServletMapping(action/java.lang.String,*.do/java.lang.String)
3257 [main] INFO common.ChannelSocket  - JK2: ajp13 listening on 
localhost/127.0.0.1:8009
3430 [main] INFO server.JkMain  - Jk running ID=0 time=11/227  
config=/usr/share/tomcat4/conf/jk2.properties
WebappClassLoader:   Resource 
'/WEB-INF/classes/com/tandbergtv/idl/TPS/PortalServiceOperations.class' was 
modified; Date is now: Wed Jan 08 12:49:51 CET 2003 Was: Tue Jan 07 12:39:32 
CET 2003
[...]
2614852 [Thread-8] ERROR common.MsgAjp  - BAD packet signature 65524
ff f4 ff fd 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00

Ajp13 connector doesn't start listening on port 8009

[Steinar Bang]

Platform: Intel PIII, debian testing/unstable (sarge)
  Blackdown JDK 1.3.1 (j2sdk 1.3.1.0b-2),
  tomcat4 4.1.16-1,
  apache 1.3.26-1.1, apache-ssl 1.3.26+1.48-2

My problem is that when I do
/etc/init.d/tomcat4 start
there is nothing listening on port 8009.

Or rather: there is _sometimes_ nothing listening on port 8009.

When I have started and stopped tomcat and apache and apache-ssl, I
have sometimes been able to find something listening on port 8009.  I
haven't changed anything in the configuration for this to happen.
Just started and stopped services.  But the listening to port 8009
has gone away as mysteriously as it appeared.

I haven't found anything conclusive in the logs about this.  There
seems to be stuff in /var/log/tomcat4/catalina.out related to Ajp13,
but I can't make sense of it (see log fragments below).

Has anyone else seen this, or similar behaviour?

I have used the commands
lsof | grep 8009
and
telnet localhost 8009
to determine if something is listening to port 8009.

Right now the first return no matches, and the latter prints out:
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused


I have tried both the Coyote Ajp13 connector, with the following in
server.xml:



And the old Ajp13 connector with the following config:



But the behaviour is the same.

I have wondered if there is a problem with both apache and apache-ssl
accessing the same Ajp13 connector in tomcat.  But I've stopped
apache-ssl a while back, and I still haven't seen any change in the
behaviour. 

Thanx!


- Steinar

Log fragments.  

The last things that mention "Ajp" in /var/log/tomcat4/catalina.out:
[...]
2371 [main] INFO common.ChannelSocket  - JK2: ajp13 listening on tcp port 8009
2483 [main] INFO server.JkMain  - Jk running ID=0 time=46/168  
config=/usr/share/tomcat4/conf/jk2.properties
[ Closing connection to 172.21.206.140:2809 ]
[ Closing connection to 127.0.0.1:2809 ]
[ Closing connection to 172.21.206.140:1221 ]
350125 [Thread-4] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
350306 [Thread-12] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
356237 [Thread-12] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
356266 [Thread-4] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
362458 [Thread-4] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
362490 [Thread-12] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
364300 [Thread-6] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
368480 [Thread-11] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
368768 [Thread-4] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
374591 [Thread-12] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
374679 [Thread-11] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
415008 [Thread-5] WARN common.ChannelSocket  - server has closed the current 
connection (-1)
[...]
Call 
org.apache.struts.action.ActionServlet.addServletMapping(action/java.lang.String,*.do/java.lang.String)
3257 [main] INFO common.ChannelSocket  - JK2: ajp13 listening on 
localhost/127.0.0.1:8009
3430 [main] INFO server.JkMain  - Jk running ID=0 time=11/227  
config=/usr/share/tomcat4/conf/jk2.properties
WebappClassLoader:   Resource 
'/WEB-INF/classes/com/tandbergtv/idl/TPS/PortalServiceOperations.class' was modified; 
Date is now: Wed Jan 08 12:49:51 CET 2003 Was: Tue Jan 07 12:39:32 CET 2003
[...]
2614852 [Thread-8] ERROR common.MsgAjp  - BAD packet signature 65524
ff f4 ff fd 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  | 
00 

Re: Something pushed out my Blackdown j2re1.3

[Steinar Bang]

> Steinar Bang <[EMAIL PROTECTED]> wrote:

>> When looking at the Blackdown site with ncftp, I find the
>> directories expected by apt, but the directories are empty, ie. no
>> .deb files.

>>>>> klaus sperner <[EMAIL PROTECTED]>:

> my /etc/apt/sources.list says:

> #java 1.3.1 for debian from blackdown.org; we get it from gwdg-mirror
> deb ftp://ftp.gwdg.de/pub/languages/java/linux/debian unstable non-free

> i just had a look at this ftp-server and the .debs are there.
> maybe you want to try that.


>>>>> Arnaud Vandyck <[EMAIL PROTECTED]>:

> Well, maybe you can cross the sea :))

> deb ftp://ftp.easynet.be/blackdown/debian/ woody main non-free

Thanx for the pointers.  I picked a mirror close to me network-wise,
and my apt line now reads:

deb ftp://sunsite.dk/mirrors/java-linux/debian/ woody main non-free

Upgrade from there worked.

Thanx again!

Re: Something pushed out my Blackdown j2re1.3

[Steinar Bang]

>>>>> Arnaud Vandyck <[EMAIL PROTECTED]>:

> Steinar Bang <[EMAIL PROTECTED]> wrote:

>> I tried
>>  apt-get update
>>  apt-get dist-upgrade
>> on my Intel PIII testing system yesterday, and something seems to
>> have pushed out Blackdown j2re1.3, and tries to install jre1.1
>> instead.

> Replace this line in your sources.list:

> # Unofficial Java2 for woody
> deb ftp://ftp.uk.linux.org/pub/linux/java/debian/ woody main non-free

Thanx!  Adding a "main" section to the apt line removed the
confusion.  After doing an update I tried 
apt-get --dry-run dist-upgrade
and it listed the following new packages it would like to install:
  j2re1.3 j2se-common jre1.1

However the actual dist-upgrade fails because it can't find the .deb
files.

When looking at the Blackdown site with ncftp, I find the directories
expected by apt, but the directories are empty, ie. no .deb files.

Re: Something pushed out my Blackdown j2re1.3

[Steinar Bang]

> Steinar Bang <[EMAIL PROTECTED]> wrote:

>> When looking at the Blackdown site with ncftp, I find the
>> directories expected by apt, but the directories are empty, ie. no
>> .deb files.

>>>>> klaus sperner <[EMAIL PROTECTED]>:

> my /etc/apt/sources.list says:

> #java 1.3.1 for debian from blackdown.org; we get it from gwdg-mirror
> deb ftp://ftp.gwdg.de/pub/languages/java/linux/debian unstable non-free

> i just had a look at this ftp-server and the .debs are there.
> maybe you want to try that.


>>>>> Arnaud Vandyck <[EMAIL PROTECTED]>:

> Well, maybe you can cross the sea :))

> deb ftp://ftp.easynet.be/blackdown/debian/ woody main non-free

Thanx for the pointers.  I picked a mirror close to me network-wise,
and my apt line now reads:

deb ftp://sunsite.dk/mirrors/java-linux/debian/ woody main non-free

Upgrade from there worked.

Thanx again!



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Something pushed out my Blackdown j2re1.3

[Steinar Bang]

I tried
apt-get update
apt-get dist-upgrade
on my Intel PIII testing system yesterday, and something seems to have
pushed out Blackdown j2re1.3, and tries to install jre1.1 instead.

A strange thing, is that it tries installing jre1.1 from the Blackdown
server where it doesn't find it.

When I try
apt-get install j2re1.3
I'm told 
  j2re1.3: Depends: j2se-common (> 1) but it is not installable
 E: Sorry, broken packages

Any clues as to what package upgrade may have caused this, are
highly appreciated!

Output from my apt-get commandos, and my sources.list, are attached. 

Thanx!


- Steinar

# See sources.list(5) for more information, especialy
# Remember that you can only use http, ftp or file URIs
# CDROMs are managed through the apt-cdrom tool.
#deb http://http.us.debian.org/debian testing main contrib non-free
#deb http://non-us.debian.org/debian-non-US testing/non-US main contrib non-free
#deb http://security.debian.org testing/updates main contrib non-free

# Uncomment if you want the apt-get source function to work
#deb-src http://http.us.debian.org/debian testing main contrib non-free
#deb-src http://non-us.debian.org/debian-non-US testing non-US

deb http://ftp.sunet.se/pub/os/Linux/distributions/debian/ testing main non-free contrib
deb-src http://ftp.sunet.se/pub/os/Linux/distributions/debian/ testing main non-free contrib
deb http://non-us.debian.org/debian-non-US testing/non-US main contrib non-free
deb-src http://non-us.debian.org/debian-non-US testing/non-US main contrib non-free
#deb http://http.us.debian.org/debian testing main contrib non-free

# Unofficial Java2 for woody
deb ftp://ftp.uk.linux.org/pub/linux/java/debian/ woody non-free

# Packages neccessary for the getox XML editor (eg. libunicode0)
#deb http://red-carpet.ximian.com/debian potato main

# Get access to woody packages
deb http://ftp.sunet.se/pub/os/Linux/distributions/debian/ stable main non-free contrib
no-video2:/home/sba# apt-get --dry-run dist-upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
Calculating Upgrade... Done
The following NEW packages will be installed:
  jre1.1 libfile-which-perl libio-string-perl
The following packages have been kept back
  j2sdk1.3
12 packages upgraded, 3 newly installed, 0 to remove and 1  not upgraded.
Inst console-common (0.7.16 Debian:testing)
Inst console-data (1999.08.29-25 Debian:testing)
Inst base-config (1.44 Debian:testing)
Inst cvs (1.11.2-5 Debian:testing)
Inst debian-policy (3.5.7.1 Debian:testing)
Inst jdk1.1 (1.1.8v3-1 Blackdown Java-Linux:1.3/woody) []
Inst jre1.1 (1.1.8v3-1 Blackdown Java-Linux:1.3/woody)
Inst libfile-which-perl (0.05-1 Debian:testing)
Inst libio-string-perl (1.01-2 Debian:testing, Debian:3.0/stable)
Inst libi18n-charset-perl (1.23-1 Debian:testing)
Inst libxerces-java (1.4.4-2 Debian:testing)
Inst mule-ucs (0.84-12 Debian:testing)
Inst wdg-html-reference (3.0-2 Debian:testing)
Inst xfonts-thai-manop (20001108-4 Debian:testing)
Inst libapache-mod-jk (3.3a-5 Debian:testing)
Conf console-common (0.7.16 Debian:testing)
Conf console-data (1999.08.29-25 Debian:testing)
Conf base-config (1.44 Debian:testing)
Conf cvs (1.11.2-5 Debian:testing)
Conf debian-policy (3.5.7.1 Debian:testing)
Conf jre1.1 (1.1.8v3-1 Blackdown Java-Linux:1.3/woody)
Conf jdk1.1 (1.1.8v3-1 Blackdown Java-Linux:1.3/woody)
Conf libfile-which-perl (0.05-1 Debian:testing)
Conf libio-string-perl (1.01-2 Debian:testing, Debian:3.0/stable)
Conf libi18n-charset-perl (1.23-1 Debian:testing)
Conf libxerces-java (1.4.4-2 Debian:testing)
Conf mule-ucs (0.84-12 Debian:testing)
Conf wdg-html-reference (3.0-2 Debian:testing)
Conf xfonts-thai-manop (20001108-4 Debian:testing)
Conf libapache-mod-jk (3.3a-5 Debian:testing)
no-video2:/home/sba# apt-get dist-upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
Calculating Upgrade... Done
The following NEW packages will be installed:
  jre1.1 libfile-which-perl libio-string-perl
The following packages have been kept back
  j2sdk1.3
12 packages upgraded, 3 newly installed, 0 to remove and 1  not upgraded.
Need to get 17.2MB of archives. After unpacking 14.4MB will be used.
Do you want to continue? [Y/n]
Get:1 ftp://ftp.uk.linux.org woody/non-free jdk1.1 1.1.8v3-1 [6549kB]
Err ftp://ftp.uk.linux.org woody/non-free jdk1.1 1.1.8v3-1
  Unable to fetch file, server said 'Failed to open file.  '
Get:2 ftp://ftp.uk.linux.org woody/non-free jre1.1 1.1.8v3-1 [5793kB]
Err ftp://ftp.uk.linux.org woody/non-free jre1.1 1.1.8v3-1
  Unable to fetch file, server said 'Failed to open file.  '
Get:3 http://ftp.sunet.se testing/main console-common 0.7.16 [30.4kB]
Get:4 http://ftp.sunet.se testing/main console-data 1999.08.29-25 [886kB]
Get:5 http://ftp.sunet.se testing/main base-config 1.44 [110kB]
Get:6 http://ftp.sunet.se testing/main cvs 1.11.2-5 [1135kB]
Get:7 http://ftp.sunet.se testing/main debian-policy 3.5.7.1 [595kB]
Get:8 http://ftp.sunet.se testing/main libfile-which-perl 0.05-1 [11.5kB]
Get:9 http://ft

Re: Something pushed out my Blackdown j2re1.3

[Steinar Bang]

>>>>> Arnaud Vandyck <[EMAIL PROTECTED]>:

> Steinar Bang <[EMAIL PROTECTED]> wrote:

>> I tried
>>  apt-get update
>>  apt-get dist-upgrade
>> on my Intel PIII testing system yesterday, and something seems to
>> have pushed out Blackdown j2re1.3, and tries to install jre1.1
>> instead.

> Replace this line in your sources.list:

> # Unofficial Java2 for woody
> deb ftp://ftp.uk.linux.org/pub/linux/java/debian/ woody main non-free

Thanx!  Adding a "main" section to the apt line removed the
confusion.  After doing an update I tried 
apt-get --dry-run dist-upgrade
and it listed the following new packages it would like to install:
  j2re1.3 j2se-common jre1.1

However the actual dist-upgrade fails because it can't find the .deb
files.

When looking at the Blackdown site with ncftp, I find the directories
expected by apt, but the directories are empty, ie. no .deb files.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Something pushed out my Blackdown j2re1.3

[Steinar Bang]

I tried
apt-get update
apt-get dist-upgrade
on my Intel PIII testing system yesterday, and something seems to have
pushed out Blackdown j2re1.3, and tries to install jre1.1 instead.

A strange thing, is that it tries installing jre1.1 from the Blackdown
server where it doesn't find it.

When I try
apt-get install j2re1.3
I'm told 
  j2re1.3: Depends: j2se-common (> 1) but it is not installable
 E: Sorry, broken packages

Any clues as to what package upgrade may have caused this, are
highly appreciated!

Output from my apt-get commandos, and my sources.list, are attached. 

Thanx!


- Steinar


# See sources.list(5) for more information, especialy
# Remember that you can only use http, ftp or file URIs
# CDROMs are managed through the apt-cdrom tool.
#deb http://http.us.debian.org/debian testing main contrib non-free
#deb http://non-us.debian.org/debian-non-US testing/non-US main contrib non-free
#deb http://security.debian.org testing/updates main contrib non-free

# Uncomment if you want the apt-get source function to work
#deb-src http://http.us.debian.org/debian testing main contrib non-free
#deb-src http://non-us.debian.org/debian-non-US testing non-US

deb http://ftp.sunet.se/pub/os/Linux/distributions/debian/ testing main non-free contrib
deb-src http://ftp.sunet.se/pub/os/Linux/distributions/debian/ testing main non-free contrib
deb http://non-us.debian.org/debian-non-US testing/non-US main contrib non-free
deb-src http://non-us.debian.org/debian-non-US testing/non-US main contrib non-free
#deb http://http.us.debian.org/debian testing main contrib non-free

# Unofficial Java2 for woody
deb ftp://ftp.uk.linux.org/pub/linux/java/debian/ woody non-free

# Packages neccessary for the getox XML editor (eg. libunicode0)
#deb http://red-carpet.ximian.com/debian potato main

# Get access to woody packages
deb http://ftp.sunet.se/pub/os/Linux/distributions/debian/ stable main non-free contrib

no-video2:/home/sba# apt-get --dry-run dist-upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
Calculating Upgrade... Done
The following NEW packages will be installed:
  jre1.1 libfile-which-perl libio-string-perl
The following packages have been kept back
  j2sdk1.3
12 packages upgraded, 3 newly installed, 0 to remove and 1  not upgraded.
Inst console-common (0.7.16 Debian:testing)
Inst console-data (1999.08.29-25 Debian:testing)
Inst base-config (1.44 Debian:testing)
Inst cvs (1.11.2-5 Debian:testing)
Inst debian-policy (3.5.7.1 Debian:testing)
Inst jdk1.1 (1.1.8v3-1 Blackdown Java-Linux:1.3/woody) []
Inst jre1.1 (1.1.8v3-1 Blackdown Java-Linux:1.3/woody)
Inst libfile-which-perl (0.05-1 Debian:testing)
Inst libio-string-perl (1.01-2 Debian:testing, Debian:3.0/stable)
Inst libi18n-charset-perl (1.23-1 Debian:testing)
Inst libxerces-java (1.4.4-2 Debian:testing)
Inst mule-ucs (0.84-12 Debian:testing)
Inst wdg-html-reference (3.0-2 Debian:testing)
Inst xfonts-thai-manop (20001108-4 Debian:testing)
Inst libapache-mod-jk (3.3a-5 Debian:testing)
Conf console-common (0.7.16 Debian:testing)
Conf console-data (1999.08.29-25 Debian:testing)
Conf base-config (1.44 Debian:testing)
Conf cvs (1.11.2-5 Debian:testing)
Conf debian-policy (3.5.7.1 Debian:testing)
Conf jre1.1 (1.1.8v3-1 Blackdown Java-Linux:1.3/woody)
Conf jdk1.1 (1.1.8v3-1 Blackdown Java-Linux:1.3/woody)
Conf libfile-which-perl (0.05-1 Debian:testing)
Conf libio-string-perl (1.01-2 Debian:testing, Debian:3.0/stable)
Conf libi18n-charset-perl (1.23-1 Debian:testing)
Conf libxerces-java (1.4.4-2 Debian:testing)
Conf mule-ucs (0.84-12 Debian:testing)
Conf wdg-html-reference (3.0-2 Debian:testing)
Conf xfonts-thai-manop (20001108-4 Debian:testing)
Conf libapache-mod-jk (3.3a-5 Debian:testing)
no-video2:/home/sba# apt-get dist-upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
Calculating Upgrade... Done
The following NEW packages will be installed:
  jre1.1 libfile-which-perl libio-string-perl
The following packages have been kept back
  j2sdk1.3
12 packages upgraded, 3 newly installed, 0 to remove and 1  not upgraded.
Need to get 17.2MB of archives. After unpacking 14.4MB will be used.
Do you want to continue? [Y/n]
Get:1 ftp://ftp.uk.linux.org woody/non-free jdk1.1 1.1.8v3-1 [6549kB]
Err ftp://ftp.uk.linux.org woody/non-free jdk1.1 1.1.8v3-1
  Unable to fetch file, server said 'Failed to open file.  '
Get:2 ftp://ftp.uk.linux.org woody/non-free jre1.1 1.1.8v3-1 [5793kB]
Err ftp://ftp.uk.linux.org woody/non-free jre1.1 1.1.8v3-1
  Unable to fetch file, server said 'Failed to open file.  '
Get:3 http://ftp.sunet.se testing/main console-common 0.7.16 [30.4kB]
Get:4 http://ftp.sunet.se testing/main console-data 1999.08.29-25 [886kB]
Get:5 http://ftp.sunet.se testing/main base-config 1.44 [110kB]
Get:6 http://ftp.sunet.se testing/main cvs 1.11.2-5 [1135kB]
Get:7 http://ftp.sunet.se testing/main debian-policy 3.5.7.1 [595kB]
Get:8 http://ftp.sunet.se testing/main libfile-which-perl 0.05-1 [11.5kB]
Get:9 http://