Bug#742503: [Pkg-octave-devel] Bug#742503: Bug#742503: octave 3.8.1 requires java
* Mike Miller mtmil...@debian.org [2015-08-29 18:55]: On Thu, Jul 16, 2015 at 09:59:17 +0200, Alois Schloegl wrote: I changed the control file in the debian package (see attachments). default-jre-headless is now not in Depends but in Build-Depends and Recommends. The resulting octave-debian packages does the job. [snip] I have the attached patch ready to push, tested locally, any objections from fellow maintainers or bystanders with this change to src:octave? None from me, go ahead. Rafael
Bug#742503: [Pkg-octave-devel] Bug#742503: octave 3.8.1 requires java
On Thu, Jul 16, 2015 at 09:59:17 +0200, Alois Schloegl wrote:
I changed the control file in the debian package (see attachments).
default-jre-headless is now not in Depends but in Build-Depends and
Recommends. The resulting octave-debian packages does the job.
In case somebody wants to use the java-interface, the above error
message seems good enough.
Please consider repackaging Octave with the modified control file.
I think the error message is less than ideal, but I agree that this
would help those users who might want to keep clear of Java for whatever
reasons.
I have the attached patch ready to push, tested locally, any objections
from fellow maintainers or bystanders with this change to src:octave?
--
mike
From 9bab6df007570d206f1f55b7388bbb232a311faa Mon Sep 17 00:00:00 2001
From: Mike Miller mtmil...@debian.org
Date: Sat, 29 Aug 2015 17:17:25 -0400
Subject: [PATCH] Downgrade default-jre-headless from Depends to Recommends.
Closes: #742503
Thanks: Alois Schloegl for the suggestion
---
debian/control | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/debian/control b/debian/control
index 610f613..4419835 100644
--- a/debian/control
+++ b/debian/control
@@ -63,10 +63,10 @@ Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-octave/octave.git
Package: octave
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, texinfo, octave-common (= ${source:Version}),
- liboctave3 (= ${binary:Version}),
- default-jre-headless [!armhf !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !mips !mipsel !sparc]
+ liboctave3 (= ${binary:Version})
Recommends: gnuplot-x11 | gnuplot-qt, libopenblas-base | libatlas3-base,
- pstoedit
+ pstoedit,
+ default-jre-headless [!armhf !hurd-i386 !kfreebsd-amd64 !kfreebsd-i386 !mips !mipsel !sparc]
Suggests: octave-info,
octave-doc,
octave-htmldoc,
--
2.5.0
Bug#742503: [Pkg-octave-devel] Bug#742503: octave 3.8.1 requires java
On 2015-07-16 07:00, Mike Miller wrote: On Wed, Jul 15, 2015 at 08:59:32 -0400, Mike Miller wrote: On Wed, Jul 15, 2015 at 10:00:33 +0200, Alois Schloegl wrote: Octave should not have a strong dependency on openjdk. Any of the following solutions would do: 1) the dependency should be changed to recommended, and/or 2) it should allow for some alternative java engine (e.g. gcj or whatever). (see also [4] ), 3) keeping the java dependency in a octave package octave-java as it was before 3.8.x Before #1 or #3 are feasible, some upstream work will need to be done to allow Octave to detect the (presence of / version of / path to) JRE at runtime. Please see upstream bug #40111. Minor clarification: currently, when Octave is compiled with Java support but the JRE is not actually present, the error is handled and reported: octave:1 javaMethod (getRuntime, java.lang.Runtime) error: javaMethod: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so: failed to load: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so: cannot open shared object file: No such file or directory octave:2 So Octave does handle this to some degree. The error reporting is not ideal and could be improved as part of #40111. But it does look feasible to be able to run Octave without a JRE. Users who opt out of installing default-jre-headless will see errors like the above if they try to use java functions, or functions that rely on java such as those in the octave-io package. Thoughts? I changed the control file in the debian package (see attachments). default-jre-headless is now not in Depends but in Build-Depends and Recommends. The resulting octave-debian packages does the job. In case somebody wants to use the java-interface, the above error message seems good enough. Please consider repackaging Octave with the modified control file. Alois --- octave-3.8.4.deb/DEBIAN/control.orig 2015-07-16 09:11:00.860280895 +0200 +++ octave-3.8.4/DEBIAN/control 2015-07-16 09:38:50.716915697 +0200 @@ -1,10 +1,11 @@ Package: octave Version: 3.8.2-4 -Architecture: arm64 +Architecture: amd64 Maintainer: Debian Octave Group pkg-octave-de...@lists.alioth.debian.org -Installed-Size: 3327 -Depends: libamd2.3.1, libarpack2 (= 2.1), libblas3 | libblas.so.3, libc6 (= 2.17), libcamd2.3.1, libccolamd2.8.0, libcholmod2.1.2, libcolamd2.8.0, libcxsparse3.1.2, libfftw3-double3, libfftw3-single3, libfltk-gl1.3 (= 1.3.0), libfltk1.3 (= 1.3.1), libfontconfig1 (= 2.11), libfreetype6 (= 2.2.1), libgcc1 (= 1:4.7), libgl1-mesa-glx | libgl1, libglpk36 (= 4.51), libglu1-mesa | libglu1, libgomp1 (= 4.2.1), libgraphicsmagick++3, libgraphicsmagick3 (= 1.3.5), liblapack3 | liblapack.so.3, liboctave2 (= 3.8.2-4), libqhull6 (= 2012.1), libqrupdate1 (= 1.0), libqscintilla2-11, libqt4-network (= 4:4.5.3), libqtcore4 (= 4:4.7.0~beta1), libqtgui4 (= 4:4.8.0), libstdc++6 (= 4.9), libumfpack5.6.2, libx11-6, texinfo, octave-common (= 3.8.2-4), default-jre-headless -Recommends: gnuplot-x11 | gnuplot-qt, libopenblas-base | libatlas3-base, pstoedit +Installed-Size: 3497 +Build-Depends: default-jre-headless +Depends: libamd2.3.1, libarpack2 (= 2.1), libblas3 | libblas.so.3, libc6 (= 2.14), libcamd2.3.1, libccolamd2.8.0, libcholmod2.1.2, libcolamd2.8.0, libcxsparse3.1.2, libfftw3-double3, libfftw3-single3, libfltk-gl1.3 (= 1.3.0), libfltk1.3 (= 1.3.1), libfontconfig1 (= 2.11), libfreetype6 (= 2.2.1), libgcc1 (= 1:4.1.1), libgl1-mesa-glx | libgl1, libglpk36 (= 4.51), libglu1-mesa | libglu1, libgomp1 (= 4.2.1), libgraphicsmagick++3, libgraphicsmagick3 (= 1.3.5), liblapack3 | liblapack.so.3, liboctave2 (= 3.8.2-4), libqhull6 (= 2012.1), libqrupdate1 (= 1.0), libqscintilla2-11, libqt4-network (= 4:4.5.3), libqtcore4 (= 4:4.7.0~beta1), libqtgui4 (= 4:4.8.0), libstdc++6 (= 4.9), libumfpack5.6.2, libx11-6, texinfo, octave-common (= 3.8.2-4) +Recommends: gnuplot-x11 | gnuplot-qt, libopenblas-base | libatlas3-base, pstoedit, default-jre-headless Suggests: octave-info, octave-doc, octave-htmldoc Conflicts: octave-java, octave3.2 Breaks: dynare (= 4.4.1-1), libsbml5-octave (= 5.8.0-2), octave-audio (= 1.1.4-4), octave-biosig (= 1.3.0-2+b1), octave-communications (= 1.2.0-1), octave-control (= 2.6.2-1), octave-econometrics (= 1:1.1.1-2), octave-fixed (= 0.7.10-5+b1), octave-gdf (= 0.1.2-2+b1), octave-general (= 1.3.2-2), octave-geometry (= 1.7.0-1), octave-gmt (= 4.5.11-1), octave-gsl (= 1.0.8-5), octave-image (= 2.0.0-3), octave-io ( 1.3), octave-java (= 1.2.9-2), octave-lhapdf (= 5.9.1-3), octave-linear-algebra (= 2.2.0-1), octave-miscellaneous (= 1.2.0-2), octave-mpi (= 1.1.1-1), octave-nan (= 2.5.9-1), octave-nlopt (= 2.4.1+dfsg-1), octave-nurbs (= 1.3.7-1), octave-ocs (= 0.1.3-1), octave-octcdf (= 1.1.6-1), octave-octgpr (= 1.2.0-3), octave-odepkg (= 0.8.4-1), octave-openmpi-ext (= 1.1.0-2), octave-optim (= 1.2.2-2), octave-optiminterp (= 0.3.4-1), octave-parallel (= 2.2.0-1), octave-pfstools (=
Bug#742503: [Pkg-octave-devel] Bug#742503: octave 3.8.1 requires java
On Wed, Jul 15, 2015 at 08:59:32 -0400, Mike Miller wrote: On Wed, Jul 15, 2015 at 10:00:33 +0200, Alois Schloegl wrote: Octave should not have a strong dependency on openjdk. Any of the following solutions would do: 1) the dependency should be changed to recommended, and/or 2) it should allow for some alternative java engine (e.g. gcj or whatever). (see also [4] ), 3) keeping the java dependency in a octave package octave-java as it was before 3.8.x Before #1 or #3 are feasible, some upstream work will need to be done to allow Octave to detect the (presence of / version of / path to) JRE at runtime. Please see upstream bug #40111. Minor clarification: currently, when Octave is compiled with Java support but the JRE is not actually present, the error is handled and reported: octave:1 javaMethod (getRuntime, java.lang.Runtime) error: javaMethod: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so: failed to load: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so: cannot open shared object file: No such file or directory octave:2 So Octave does handle this to some degree. The error reporting is not ideal and could be improved as part of #40111. But it does look feasible to be able to run Octave without a JRE. Users who opt out of installing default-jre-headless will see errors like the above if they try to use java functions, or functions that rely on java such as those in the octave-io package. Thoughts? -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742503: [Pkg-octave-devel] Bug#742503: octave 3.8.1 requires java
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Recently, I tried to remove openjdk-[6-8] from a number of machines because of the large number of open security issues with openjdk (currently there are 23, 21 and 20 open security issues on openjdk-6, openjdk-7, and openjdk-8, resp.). I learned that due to some package dependencies, octave gets removed too. That's not desired. Octave should not have a strong dependency on openjdk. Any of the following solutions would do: 1) the dependency should be changed to recommended, and/or 2) it should allow for some alternative java engine (e.g. gcj or whatever). (see also [4] ), 3) keeping the java dependency in a octave package octave-java as it was before 3.8.x Alois [1] https://security-tracker.debian.org/tracker/source-package/openjdk-6 [2] https://security-tracker.debian.org/tracker/source-package/openjdk-7 [3] https://security-tracker.debian.org/tracker/source-package/openjdk-8 [4] https://lists.alioth.debian.org/pipermail/pkg-octave-devel/2013-December /010469.html -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVphMhAAoJEBdbD2J3nb+MIMsH/2oevdIY3lJsIrLpna49mKcj zQo1Mc3zunsEZWLG8R+FyezLUrhnS0zeAIsjVSFbk3UznqaBuAgic+PjOE5uJDoU DvkC8pi81VDIHvycIsNiHhaKXdxtmTZIVf24b3lIWB+N/18STqP9SzjByu4klLXR pwG2Uq32cbbyWPm/xwSnQMew/5dWd8tEdsDaGGn1yD2pneiv2g4DbVSiVtGgEoBA b7b66vLVwFH9jHXbzxRhaLU3Gbntk8KX2/F2YHjtGGjaM/GUQ7aEC1R0UTSfXfnM /fpNkWhFmZW+CPFN2gmo7sU0xJqSTkU0tDLTE9FlO2KEuIAQjarFITVb0Fl7+mQ= =ApCl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742503: [Pkg-octave-devel] Bug#742503: octave 3.8.1 requires java
On Wed, 2015-07-15 at 10:00 +0200, Alois Schloegl wrote: 3) keeping the java dependency in a octave package octave-java as it was before 3.8.x This is impossible because that package does not exist anymore for Octave 3.8 or higher. The current dependency is default-jre-headless. This should be a build-dep (because the current Octave build system has an outstanding issue about requiring a Java implementation at build time) but downgraded to a Recommends. I don't know how feasible this is. It may require patches on Octave itself to not require Java at compile time. - Jordi G. H. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742503: [Pkg-octave-devel] Bug#742503: octave 3.8.1 requires java
On Wed, Jul 15, 2015 at 10:00:33 +0200, Alois Schloegl wrote: Octave should not have a strong dependency on openjdk. Any of the following solutions would do: 1) the dependency should be changed to recommended, and/or 2) it should allow for some alternative java engine (e.g. gcj or whatever). (see also [4] ), 3) keeping the java dependency in a octave package octave-java as it was before 3.8.x Before #1 or #3 are feasible, some upstream work will need to be done to allow Octave to detect the (presence of / version of / path to) JRE at runtime. Please see upstream bug #40111. For #2 to work, someone needs to figure out why Octave crashes when built with gcj. Please see upstream bug #41652 [2] and gcc bug #60309 [3]. [1]: https://savannah.gnu.org/bugs/?40111 [2]: https://savannah.gnu.org/bugs/?41652 [3]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60309 -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742503: [Pkg-octave-devel] Bug#742503: octave 3.8.1 requires java
On Mon, 2014-03-24 at 17:08 +, Leo Butler wrote: Matlab compatibility is an ephemera and JWE himself has written against it being a goal that drives Octave development. He never wrote against it. He just said that in the beginning it wasn't a goal. Being compatible with Matlab is now Octave's sole goal. Whenever we can be less stupid, we are, but that doesn't happen frequently. We have to do most of the stupid things that Matlab does. It is impossible to maintain that compatibility anymore without Java. Finally, I really dislike java for a whole bunch of reasons, but mainly because of its bloat, lack of usefulness and slowness. You may soon dislike Octave, then, because you are describing Matlab, and Octave seeks to emulate it. Have you tried Julia, R, or Scipy? - Jordi G. H. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742503: octave 3.8.1 requires java
Package: octave Version: 3.6.4-4+b2 Severity: important Dear Maintainer, Since Octave introduced its java-dependent gui (congrats) in v3.8.1, I have been unable/unwilling to upgrade. I believe that these graphical dependencies should be downgraded to *recommended* and/or a separate octave-nox package--which installs only a terminal version of octave--be provided. Although I cannot find a section in the DPM which deals with this situation, a number of related packages (e.g. emacs, gnuplot) follow the practice of providing a terminal-only version of the package. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.12-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages octave depends on: ii libamd2.3.1 1:4.2.1-3 ii libarpack2 3.1.5-2 ii libatlas3-base [liblapack.so.3] 3.10.1-4 ii libblas3 [libblas.so.3] 1.2.20110419-7 ii libc62.18-4 ii libcamd2.3.1 1:4.2.1-3 ii libccolamd2.8.0 1:4.2.1-3 ii libcholmod2.1.2 1:4.2.1-3 ii libcolamd2.8.0 1:4.2.1-3 ii libcurl3-gnutls 7.35.0-1 ii libcxsparse3.1.2 1:4.2.1-3 ii libfftw3-double3 3.3.3-7 ii libfftw3-single3 3.3.3-7 ii libfltk-gl1.31.3.2-4 ii libfltk1.3 1.3.2-4 ii libfreetype6 2.5.2-1 ii libgcc1 1:4.8.2-16 ii libgl1-mesa-glx [libgl1] 9.2.2-1 ii libglpk364.53-1 ii libgomp1 4.8.2-16 ii libgraphicsmagick++3 1.3.18-1 ii libgraphicsmagick3 1.3.18-1 ii liblapack3 [liblapack.so.3] 3.5.0-2 ii liboctave1 3.6.4-4+b2 ii libpcre3 1:8.31-2 ii libqhull62012.1-4 ii libqrupdate1 1.1.2-1 ii libstdc++6 4.8.2-16 ii libumfpack5.6.2 1:4.2.1-3 ii libx11-6 2:1.6.2-1 ii octave-common3.6.4-4 ii texinfo 5.2.0.dfsg.1-2 Versions of packages octave recommends: ii gnuplot-x11 4.6.5-1 ii libatlas3-base 3.10.1-4 ii pstoedit3.62-1 Versions of packages octave suggests: pn octave-htmldoc none ii octave-info 3.8.0-5 ii octave3.2-doc [octave-doc] 3.2.4-12 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742503: octave 3.8.1 requires java
Control: found -1 3.8.1-1 Control: notfound -1 3.6.4-4+b2 Control: severity -1 wishlist Control: tags -1 + moreinfo On Mon, Mar 24, 2014 at 14:30:30 +, Leo Butler wrote: Since Octave introduced its java-dependent gui (congrats) in v3.8.1, I have been unable/unwilling to upgrade. I believe that these graphical dependencies should be downgraded to *recommended* and/or a separate octave-nox package--which installs only a terminal version of octave--be provided. Thanks for your bug report and feedback on octave packaging. The request for an octave-nox package is already reported as #741097, you might want to read the discussion and comment there. But actually the addition of a dependency on java has nothing to do with the GUI. The java dependency is to allow the Octave interpreter to run an embedded JVM and interface with java libraries from the interpreter. This essentially merges the functionality of the former octave-java add-on package into octave itself. This is a feature which makes the Octave runtime environment more compatible with Matlab. A hypothetical octave-nox terminal-mode package would likely still be dependent on java. Can you clarify whether your primary concern is having an Octave package that does not have the libraries needed for a GUI which you find unnecessary, or is it the inclusion of java for whatever reason? -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742503: octave 3.8.1 requires java
Control: found -1 3.8.1-1 Control: notfound -1 3.6.4-4+b2 Control: severity -1 wishlist Control: tags -1 + moreinfo On Mon, Mar 24, 2014 at 14:30:30 +, Leo Butler wrote: Since Octave introduced its java-dependent gui (congrats) in v3.8.1, I have been unable/unwilling to upgrade. I believe that these graphical dependencies should be downgraded to *recommended* and/or a separate octave-nox package--which installs only a terminal version of octave--be provided. Thanks for your bug report and feedback on octave packaging. The request for an octave-nox package is already reported as #741097, you might want to read the discussion and comment there. But actually the addition of a dependency on java has nothing to do with the GUI. Thank you, and my apologies, I did not see this bug report. Please merge this report with that, as I feel the issues and concerns are the same. The java dependency is to allow the Octave interpreter to run an embedded JVM and interface with java libraries from the interpreter. This essentially merges the functionality of the former octave-java add-on package into octave itself. This is a feature which makes the Octave runtime environment more compatible with Matlab. A hypothetical octave-nox terminal-mode package would likely still be dependent on java. I see. I would like to see the gui dependencies repackaged as separate recommended packages and the java dependency repackaged as an optional package (i.e. restore the status quo ante vis-a-vis java). I do not see why the ability to run a jvm from inside Octave should be considered a core feature of Octave. Certainly, I use Octave in my work (teaching+research) and have never felt the need to run a jvm from within octave. Matlab compatibility is an ephemera and JWE himself has written against it being a goal that drives Octave development. Finally, I really dislike java for a whole bunch of reasons, but mainly because of its bloat, lack of usefulness and slowness. I generally run Octave on resource-limited hardware. Can you clarify whether your primary concern is having an Octave package that does not have the libraries needed for a GUI which you find unnecessary, or is it the inclusion of java for whatever reason? Both. Leo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
