Rene Engelhard wrote: > Steven Chamberlain wrote: > > the regenerated debian/control file in the package still had gcj > > in build-depends for kfreebsd. I think this is because of an > > No, it doesn't.
Oh. When I looked at mine, after building, it did. I can see in the log that dh_gencontrol was run near the *end* of the build, after dh_install and before dpkg-deb. I've attached the last 2000 lines of my build log. > > out-of-date java-common package, which defines $java_architectures in > > /usr/share/java/java_defaults.mk. > > Then you should generate control in a uptodate chroot (what I did) > I am not sure the definition of Build-Depends is also for stuff > not related to actually building the package (control isn't rebuilt unless > you change something in "normal" builds, it is basically static in > .debian.tar.gz) I agree with that, but I didn't ask to regenerate it. I only did `dpkg-buildpackage -nc -B`? I deliberately use an out-of-date chroot as I'm trying to find what caused a regression, trying to rule out some build-depends first. > debian/rules has > > JAVA_HOME=/usr/lib/jvm/default-java > > That will use openjdk given the build-dep on the newer default-jdk _is_ there. > java-common is just need for (re-)generating control. Okay, so my build probably didn't use gcj at all. That's good news, as it got through the test suite without hitting the issue seen on the buildds. Thanks, Regards, -- Steven Chamberlain ste...@pyro.eu.org
signature.asc
Description: Digital signature
