Bug#874153: FTBFS with Java 9: jre/bin/java

2017-11-24 Thread Emmanuel Bourg 
Le 24/11/2017 à 23:37, Dirk Eddelbuettel a écrit :

> I (very respectfully) decline.
> 
> I have had enough "fun" keeping this working, and I don't even use Java.  If
> *you* want to experiment, by all means do.  Change debian/{rules,control} for
> r-base, then try building r-cran-rjava.  I _seriously_ doubt we will get by
> with JRE because this setup is for _building_ R and Java interface, not just
> running one.

Sorry I don't understand, I thought you were looking for a way to test
building/running with OpenJDK 9, in this case pulling
default-jre/default-jdk from experimental is the best approach (you can
also play with update-java-alternatives or set the JAVA_HOME variable
but that's not strictly equivalent).

If you manage to drop the direct dependency on the openjdk-* packages
you won't have to update the R packages twice a year, I thought you
would appreciate a suggestion intended to lower your workload.

Emmanuel Bourg

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-11-24 Thread Dirk Eddelbuettel 

On 24 November 2017 at 23:15, Emmanuel Bourg wrote:
| Le 24/11/2017 à 20:10, Dirk Eddelbuettel a écrit :
| 
| > I may do another RC build before R 3.4.3 is out later next week.  Not
| > entirely sure how to test it because actual Depends: result from this.  So 
if
| > I start with java 9 it may be be java 9 and nothing else.
| 
| Ideally the package should depend on default-jre only, and not on
| openjdk-{8,9}-jre. This will avoid updating the R packages for new Java
| releases (they will now come every 6 months now, Java 10 is targeted for
| March 2018).
| 
| If you want to test with OpenJDK 9 as the default JRE you can install
| the default-jre package from experimental.


I (very respectfully) decline.

I have had enough "fun" keeping this working, and I don't even use Java.  If
*you* want to experiment, by all means do.  Change debian/{rules,control} for
r-base, then try building r-cran-rjava.  I _seriously_ doubt we will get by
with JRE because this setup is for _building_ R and Java interface, not just
running one.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-11-24 Thread Emmanuel Bourg 
Le 24/11/2017 à 20:10, Dirk Eddelbuettel a écrit :

> I may do another RC build before R 3.4.3 is out later next week.  Not
> entirely sure how to test it because actual Depends: result from this.  So if
> I start with java 9 it may be be java 9 and nothing else.

Ideally the package should depend on default-jre only, and not on
openjdk-{8,9}-jre. This will avoid updating the R packages for new Java
releases (they will now come every 6 months now, Java 10 is targeted for
March 2018).

If you want to test with OpenJDK 9 as the default JRE you can install
the default-jre package from experimental.

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-11-24 Thread Dirk Eddelbuettel 

Simon,

On 24 November 2017 at 13:56, Simon Urbanek wrote:
| Emmanuel,
| 
| 
| > On Nov 24, 2017, at 11:02 AM, Emmanuel Bourg  
wrote:
| > 
| > Le 24/11/2017 à 16:30, Simon Urbanek a écrit :
| >> Absolutely - mixing jre and non-jre paths doesn't sound like a good idea. 
It was somewhat odd idiosyncrasy of the Debian configuration - I have not seen 
it on any other system.
| > 
| > Actually there is nothing Debian specific here, the jre/bin/ and bin/
| > directories have been there for ~20 years in all Java distributions. It
| > just changed two months ago with the release of Java 9.
| > 
| > If you are referring to the fact that Debian installs both the JRE and
| > the JDK in the same directory (/usr/lib/jvm/default-java) that's also
| > true for Fedora and Arch Linux.
| > 
| 
| Ah, sorry for the confusion, I was referring to JAVA being set to jre/bin 
while JAVAC was set to bin since most commonly bin did include tools in 
jre/bin. 
| 
| I think in your case you may possibly want to use
| JAVA=/usr/lib/jvm/default-java/bin/java JAVA_HOME=/usr/lib/jvm/default-java
| when configuring R to make sure it uses default-java that works both for Java 
1.8 and 1.9 (please double-check, though).

So we should do this when configuring R itself, correct?

I may do another RC build before R 3.4.3 is out later next week.  Not
entirely sure how to test it because actual Depends: result from this.  So if
I start with java 9 it may be be java 9 and nothing else.

Dirk

| 
| R doesn't actually care as long as the paths for JAVA and JAVAC actually 
exist and I see now that the issue was that jvm/default-java is pointing 
directly inside the Java installation, so if they change how Java ship things 
it breaks. 
| 
| One way around it is to point both JAVA and JAVAC to the symlinks managed by 
the distribution so it's not susceptible so changes in the Java distribution.
| 
| Cheers,
| Simon
| 

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-11-24 Thread Simon Urbanek 
Emmanuel,


> On Nov 24, 2017, at 11:02 AM, Emmanuel Bourg  wrote:
> 
> Le 24/11/2017 à 16:30, Simon Urbanek a écrit :
>> Absolutely - mixing jre and non-jre paths doesn't sound like a good idea. It 
>> was somewhat odd idiosyncrasy of the Debian configuration - I have not seen 
>> it on any other system.
> 
> Actually there is nothing Debian specific here, the jre/bin/ and bin/
> directories have been there for ~20 years in all Java distributions. It
> just changed two months ago with the release of Java 9.
> 
> If you are referring to the fact that Debian installs both the JRE and
> the JDK in the same directory (/usr/lib/jvm/default-java) that's also
> true for Fedora and Arch Linux.
> 

Ah, sorry for the confusion, I was referring to JAVA being set to jre/bin while 
JAVAC was set to bin since most commonly bin did include tools in jre/bin. 

I think in your case you may possibly want to use
JAVA=/usr/lib/jvm/default-java/bin/java JAVA_HOME=/usr/lib/jvm/default-java
when configuring R to make sure it uses default-java that works both for Java 
1.8 and 1.9 (please double-check, though).

R doesn't actually care as long as the paths for JAVA and JAVAC actually exist 
and I see now that the issue was that jvm/default-java is pointing directly 
inside the Java installation, so if they change how Java ship things it breaks. 

One way around it is to point both JAVA and JAVAC to the symlinks managed by 
the distribution so it's not susceptible so changes in the Java distribution.

Cheers,
Simon

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-11-24 Thread Emmanuel Bourg 
Le 24/11/2017 à 16:54, Dirk Eddelbuettel a écrit :

>configuring Java ...
>*** JAVA_HOME is not a valid path, ignoring

> Any concrete tips as to what we should try instead?

What about setting JAVA_HOME to /usr/lib/jvm/default-java?

Emmanuel Bourg

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-11-24 Thread Emmanuel Bourg 
Le 24/11/2017 à 16:30, Simon Urbanek a écrit :
> Absolutely - mixing jre and non-jre paths doesn't sound like a good idea. It 
> was somewhat odd idiosyncrasy of the Debian configuration - I have not seen 
> it on any other system.

Actually there is nothing Debian specific here, the jre/bin/ and bin/
directories have been there for ~20 years in all Java distributions. It
just changed two months ago with the release of Java 9.

If you are referring to the fact that Debian installs both the JRE and
the JDK in the same directory (/usr/lib/jvm/default-java) that's also
true for Fedora and Arch Linux.

Emmanuel Bourg

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-11-24 Thread Dirk Eddelbuettel 

On 24 November 2017 at 10:30, Simon Urbanek wrote:
| Absolutely - mixing jre and non-jre paths doesn't sound like a good idea. It 
was somewhat odd idiosyncrasy of the Debian configuration - I have not seen it 
on any other system.

Ok. So currently we do

   openjdk-9-jdk | default-jdk [!arm !hppa !kfreebsd-i386 !kfreebsd-amd64 
!hurd-i386]

and nothing else.  Per yesterday's build this seems to result in

   Selecting previously unselected package openjdk-9-jre-headless:amd64.

   Preparing to unpack .../073-openjdk-9-jre-headless_9.0.1+11-1_amd64.deb ...

   Unpacking openjdk-9-jre-headless:amd64 (9.0.1+11-1) ...

   Selecting previously unselected package ca-certificates-java.


   [...]

   Setting up openjdk-9-jre-headless:amd64 (9.0.1+11-1) ...

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/rmid to 
provide /usr/bin/rmid (rmid) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/java to 
provide /usr/bin/java (java) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/keytool to 
provide /usr/bin/keytool (keytool) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/jjs to 
provide /usr/bin/jjs (jjs) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/pack200 to 
provide /usr/bin/pack200 (pack200) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/rmiregistry 
to provide /usr/bin/rmiregistry (rmiregistry) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/unpack200 
to provide /usr/bin/unpack200 (unpack200) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/orbd to 
provide /usr/bin/orbd (orbd) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/servertool 
to provide /usr/bin/servertool (servertool) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/tnameserv 
to provide /usr/bin/tnameserv (tnameserv) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/lib/jexec to 
provide /usr/bin/jexec (jexec) in auto mode


   [...]

   Setting up openjdk-9-jdk-headless:amd64 (9.0.1+11-1) ...

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/idlj to 
provide /usr/bin/idlj (idlj) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/jdeps to 
provide /usr/bin/jdeps (jdeps) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/wsimport to 
provide /usr/bin/wsimport (wsimport) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/jinfo to 
provide /usr/bin/jinfo (jinfo) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/jstat to 
provide /usr/bin/jstat (jstat) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/jlink to 
provide /usr/bin/jlink (jlink) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/javah to 
provide /usr/bin/javah (javah) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/jhsdb to 
provide /usr/bin/jhsdb (jhsdb) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/jps to 
provide /usr/bin/jps (jps) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/jstack to 
provide /usr/bin/jstack (jstack) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/jrunscript 
to provide /usr/bin/jrunscript (jrunscript) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/javac to 
provide /usr/bin/javac (javac) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/jmod to 
provide /usr/bin/jmod (jmod) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/javap to 
provide /usr/bin/javap (javap) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/jar to 
provide /usr/bin/jar (jar) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/jaotc to 
provide /usr/bin/jaotc (jaotc) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/policytool 
to provide /usr/bin/policytool (policytool) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/javadoc to 
provide /usr/bin/javadoc (javadoc) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/schemagen 
to provide /usr/bin/schemagen (schemagen) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/jshell to 
provide /usr/bin/jshell (jshell) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/xjc to 
provide /usr/bin/xjc (xjc) in auto mode

   update-alternatives: using /usr/lib/jvm/java-9-openjdk-amd64/bin/rmic to 
provide /usr/bin/rmic (rmic) in auto mode

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-11-24 Thread Simon Urbanek 
Absolutely - mixing jre and non-jre paths doesn't sound like a good idea. It 
was somewhat odd idiosyncrasy of the Debian configuration - I have not seen it 
on any other system.

Cheers,
Simon



> On Nov 24, 2017, at 9:03 AM, Dirk Eddelbuettel  wrote:
> 
> 
> Hi Emmanuel,
> 
> On 24 November 2017 at 14:40, Emmanuel Bourg wrote:
> | Hi Dirk,
> | 
> | Is it possible to simply use the /usr/lib/jvm/default-java/bin/java path
> | instead of /usr/lib/jvm/default-java/jre/bin/java? Historically jre/bin/
> | contained only the JRE executables, and bin/ contained the JDK tools
> | (javac, jar, etc). With Java 9 the layout has been simplified and the
> | executables are all in the bin/ directory. If you only use the java
> | interpreter you can point to bin/java since it exists in both OpenJDK 8
> | and OpenJDK 9 packages.
> 
> I think that is a question for Simon (CC'ed) who controls both the rJava (aka
> r-cran-rjava) side as well as how r-base provides.  Might be a question of
> path ordering.  I am not sure. I don't my side of things sets anything.
> 
> Dirk
> 
> | 
> | Emmanuel Bourg
> | 
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-11-24 Thread Dirk Eddelbuettel 

Hi Emmanuel,

On 24 November 2017 at 14:40, Emmanuel Bourg wrote:
| Hi Dirk,
| 
| Is it possible to simply use the /usr/lib/jvm/default-java/bin/java path
| instead of /usr/lib/jvm/default-java/jre/bin/java? Historically jre/bin/
| contained only the JRE executables, and bin/ contained the JDK tools
| (javac, jar, etc). With Java 9 the layout has been simplified and the
| executables are all in the bin/ directory. If you only use the java
| interpreter you can point to bin/java since it exists in both OpenJDK 8
| and OpenJDK 9 packages.

I think that is a question for Simon (CC'ed) who controls both the rJava (aka
r-cran-rjava) side as well as how r-base provides.  Might be a question of
path ordering.  I am not sure. I don't my side of things sets anything.

Dirk

| 
| Emmanuel Bourg
| 

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-11-24 Thread Emmanuel Bourg 
Hi Dirk,

Is it possible to simply use the /usr/lib/jvm/default-java/bin/java path
instead of /usr/lib/jvm/default-java/jre/bin/java? Historically jre/bin/
contained only the JRE executables, and bin/ contained the JDK tools
(javac, jar, etc). With Java 9 the layout has been simplified and the
executables are all in the bin/ directory. If you only use the java
interpreter you can point to bin/java since it exists in both OpenJDK 8
and OpenJDK 9 packages.

Emmanuel Bourg

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-10-20 Thread Dirk Eddelbuettel 

Simon,

On 20 October 2017 at 10:14, Simon Urbanek wrote:
| oh, no, rJava does not run javareconf - it only tells the user to do so if 
the configuration is broken. The R CMD javareconf occurrences in configure are 
always in the text section printed to the user. As you correctly said, it would 
be very bad if a package tried to change the system configuration. So please 
check who's calling what after the build - it's not rJava calling javareconf.

Fair enough and good to know.

That said, we are still at an impasse.  It fails to build, I have no idea
why, don't know how to fix a (rather complicated) package so unless you can
aid me here I fear the worst case of a "fails to build from source package"
being auto-removed will kick in.

(Partial) log is below.

Dirk

| 
| Thanks,
| Simon
| 
| 
| 
| 
| 
| > On Oct 19, 2017, at 9:34 PM, Dirk Eddelbuettel  wrote:
| > 
| > 
| > Simon,
| > 
| > On 19 October 2017 at 17:49, Simon Urbanek wrote:
| > | Dirk,
| > | 
| > | to clarify - this is about *R* configuration, not about rJava at all. 
rJava has nothing to do with those settings - it just uses what R was 
configured with. The only part rJava plays here is that it needs those R 
settings to be valid - just like other R packages that use Java.
| > | 
| > | As you reported the R configuration is broken, because the JAVA entry 
points to a non-existent file. I don't know why or how that happens. At least 
that's what I saw in the log:
| > | 
| > | checking Java support in R... present:
| > | interpreter : '/usr/lib/jvm/default-java/jre/bin/java'
| > | [...]
| > | checking whether Java run-time works... ./configure: line 3736: 
/usr/lib/jvm/default-java/jre/bin/java: No such file or directory
| > | no
| > | configure: error: Java interpreter 
'/usr/lib/jvm/default-java/jre/bin/java' does not work
| > | 
| > | I presume that setting should have been 
/usr/lib/jvm/default-java/bin/java -- or JRE is required and missing (again, I 
don't know what package is providing that 
/usr/lib/jvm/default-java/jre/bin/java file used in the configuration).
| > 
| > I am confused.   Once I added the call to 'R CMD javareconf' to be done
| > before 'R CMD INSTALL ...your tarball...' happens, it _builds_ but then 
failed
| > on a subsequent command that is not from me.  I could patch that.
| > 
| > Allow me to copy and paste again:
| > 
| > 
-
| > make[1]: Entering directory '/build/rjava-0.9-9'
| > CDBS WARNING:simple-patchsys.mk is deprecated since 0.4.85 - please use 
source format 3.0 (quilt) instead
| > set -e;   mv ./jri/tools/config.guess ./jri/tools/config.guess.cdbs-orig; 
cp --remove-destination /usr/share/misc/config.guess ./jri/tools/config.guess;
| > set -e;   mv ./jri/tools/config.sub ./jri/tools/config.sub.cdbs-orig; cp 
--remove-destination /usr/share/misc/config.sub ./jri/tools/config.sub;
| > make[1]: Leaving directory '/build/rjava-0.9-9'
| > set -e;   
| > set -e;   
| > R CMD javareconf
| > *** JAVA_HOME is not a valid path, ignoring
| > Java interpreter : /usr/bin/java
| > Java version : 9-Debian
| > Java home path   : /usr/lib/jvm/java-9-openjdk-amd64
| > Java compiler: /usr/bin/javac
| > Java headers gen.: /usr/bin/javah
| > Java archive tool: /usr/bin/jar
| > 
| > trying to compile and link a JNI program 
| > detected JNI cpp flags: -I$(JAVA_HOME)/include 
-I$(JAVA_HOME)/include/linux
| > detected JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm
| > make[1]: Entering directory '/tmp/Rjavareconf.e0Jzrq'
| > gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG 
-I/usr/lib/jvm/java-9-openjdk-amd64/include 
-I/usr/lib/jvm/java-9-openjdk-amd64/include/linux -fpic  -g -O2 
-fdebug-prefix-map=/build/r-base-3.4.2=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c conftest.c -o 
conftest.o
| > gcc -std=gnu99 -shared -L/usr/lib/R/lib -Wl,-z,relro -o conftest.so 
conftest.o -L/usr/lib/jvm/java-9-openjdk-amd64/lib/server -ljvm 
-L/usr/lib/R/lib -lR
| > make[1]: Leaving directory '/tmp/Rjavareconf.e0Jzrq'
| > 
| > 
| > JAVA_HOME: /usr/lib/jvm/java-9-openjdk-amd64
| > Java library path: $(JAVA_HOME)/lib/server
| > JNI cpp flags: -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/linux
| > JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm
| > Updating Java configuration in /usr/lib/R
| > /usr/lib/R/bin/javareconf: 406: /usr/lib/R/bin/javareconf: cannot create 
/usr/lib/R/etc/Makeconf.new: Permission denied
| > *** cannot create /usr/lib/R/etc/Makeconf.new
| > *** Please run as root if required.
| > 
| > debian/rules:9: recipe for target 'build/r-cran-rjava' failed
| > make: *** [build/r-cran-rjava] Error 1
| > dpkg-buildpackage: error: debian/rules build gave error exit status 2
| > 
-
| > 
| > So conftest.so is built.  Can we skip the subsequent javareconf?  If so,
| > where?  When I

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-10-20 Thread Simon Urbanek 
Dirk,

oh, no, rJava does not run javareconf - it only tells the user to do so if the 
configuration is broken. The R CMD javareconf occurrences in configure are 
always in the text section printed to the user. As you correctly said, it would 
be very bad if a package tried to change the system configuration. So please 
check who's calling what after the build - it's not rJava calling javareconf.

Thanks,
Simon





> On Oct 19, 2017, at 9:34 PM, Dirk Eddelbuettel  wrote:
> 
> 
> Simon,
> 
> On 19 October 2017 at 17:49, Simon Urbanek wrote:
> | Dirk,
> | 
> | to clarify - this is about *R* configuration, not about rJava at all. rJava 
> has nothing to do with those settings - it just uses what R was configured 
> with. The only part rJava plays here is that it needs those R settings to be 
> valid - just like other R packages that use Java.
> | 
> | As you reported the R configuration is broken, because the JAVA entry 
> points to a non-existent file. I don't know why or how that happens. At least 
> that's what I saw in the log:
> | 
> | checking Java support in R... present:
> | interpreter : '/usr/lib/jvm/default-java/jre/bin/java'
> | [...]
> | checking whether Java run-time works... ./configure: line 3736: 
> /usr/lib/jvm/default-java/jre/bin/java: No such file or directory
> | no
> | configure: error: Java interpreter '/usr/lib/jvm/default-java/jre/bin/java' 
> does not work
> | 
> | I presume that setting should have been /usr/lib/jvm/default-java/bin/java 
> -- or JRE is required and missing (again, I don't know what package is 
> providing that /usr/lib/jvm/default-java/jre/bin/java file used in the 
> configuration).
> 
> I am confused.   Once I added the call to 'R CMD javareconf' to be done
> before 'R CMD INSTALL ...your tarball...' happens, it _builds_ but then failed
> on a subsequent command that is not from me.  I could patch that.
> 
> Allow me to copy and paste again:
> 
> -
> make[1]: Entering directory '/build/rjava-0.9-9'
> CDBS WARNING:simple-patchsys.mk is deprecated since 0.4.85 - please use 
> source format 3.0 (quilt) instead
> set -e;   mv ./jri/tools/config.guess ./jri/tools/config.guess.cdbs-orig; cp 
> --remove-destination /usr/share/misc/config.guess ./jri/tools/config.guess;
> set -e;   mv ./jri/tools/config.sub ./jri/tools/config.sub.cdbs-orig; cp 
> --remove-destination /usr/share/misc/config.sub ./jri/tools/config.sub;
> make[1]: Leaving directory '/build/rjava-0.9-9'
> set -e;   
> set -e;   
> R CMD javareconf
> *** JAVA_HOME is not a valid path, ignoring
> Java interpreter : /usr/bin/java
> Java version : 9-Debian
> Java home path   : /usr/lib/jvm/java-9-openjdk-amd64
> Java compiler: /usr/bin/javac
> Java headers gen.: /usr/bin/javah
> Java archive tool: /usr/bin/jar
> 
> trying to compile and link a JNI program 
> detected JNI cpp flags: -I$(JAVA_HOME)/include 
> -I$(JAVA_HOME)/include/linux
> detected JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm
> make[1]: Entering directory '/tmp/Rjavareconf.e0Jzrq'
> gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG 
> -I/usr/lib/jvm/java-9-openjdk-amd64/include 
> -I/usr/lib/jvm/java-9-openjdk-amd64/include/linux -fpic  -g -O2 
> -fdebug-prefix-map=/build/r-base-3.4.2=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c conftest.c -o 
> conftest.o
> gcc -std=gnu99 -shared -L/usr/lib/R/lib -Wl,-z,relro -o conftest.so 
> conftest.o -L/usr/lib/jvm/java-9-openjdk-amd64/lib/server -ljvm 
> -L/usr/lib/R/lib -lR
> make[1]: Leaving directory '/tmp/Rjavareconf.e0Jzrq'
> 
> 
> JAVA_HOME: /usr/lib/jvm/java-9-openjdk-amd64
> Java library path: $(JAVA_HOME)/lib/server
> JNI cpp flags: -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/linux
> JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm
> Updating Java configuration in /usr/lib/R
> /usr/lib/R/bin/javareconf: 406: /usr/lib/R/bin/javareconf: cannot create 
> /usr/lib/R/etc/Makeconf.new: Permission denied
> *** cannot create /usr/lib/R/etc/Makeconf.new
> *** Please run as root if required.
> 
> debian/rules:9: recipe for target 'build/r-cran-rjava' failed
> make: *** [build/r-cran-rjava] Error 1
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> -
> 
> So conftest.so is built.  Can we skip the subsequent javareconf?  If so,
> where?  When I glance at your configure.ac I see several ...  And the
> Makefile structure is not exactly trivial or standard either.
> 
> Dirk
> 
> 
> | Cheers,
> | Simon
> | 
> | 
> | > On Oct 19, 2017, at 4:56 PM, Dirk Eddelbuettel  wrote:
> | > 
> | > 
> | > On 19 October 2017 at 16:31, Simon Urbanek wrote:
> | > | 
> | > | > On Oct 19, 2017, at 4:12 PM, Dirk Eddelbuettel  
> wrote:
> | > | > 
> | > | > 
> | > | > On 19 October 2017 at 15:47, Simon Urbanek wrote:

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-10-19 Thread Dirk Eddelbuettel 

Simon,

On 19 October 2017 at 17:49, Simon Urbanek wrote:
| Dirk,
| 
| to clarify - this is about *R* configuration, not about rJava at all. rJava 
has nothing to do with those settings - it just uses what R was configured 
with. The only part rJava plays here is that it needs those R settings to be 
valid - just like other R packages that use Java.
| 
| As you reported the R configuration is broken, because the JAVA entry points 
to a non-existent file. I don't know why or how that happens. At least that's 
what I saw in the log:
| 
| checking Java support in R... present:
| interpreter : '/usr/lib/jvm/default-java/jre/bin/java'
| [...]
| checking whether Java run-time works... ./configure: line 3736: 
/usr/lib/jvm/default-java/jre/bin/java: No such file or directory
| no
| configure: error: Java interpreter '/usr/lib/jvm/default-java/jre/bin/java' 
does not work
| 
| I presume that setting should have been /usr/lib/jvm/default-java/bin/java -- 
or JRE is required and missing (again, I don't know what package is providing 
that /usr/lib/jvm/default-java/jre/bin/java file used in the configuration).

I am confused.   Once I added the call to 'R CMD javareconf' to be done
before 'R CMD INSTALL ...your tarball...' happens, it _builds_ but then failed
on a subsequent command that is not from me.  I could patch that.

Allow me to copy and paste again:

-
make[1]: Entering directory '/build/rjava-0.9-9'
CDBS WARNING:simple-patchsys.mk is deprecated since 0.4.85 - please use 
source format 3.0 (quilt) instead
set -e;   mv ./jri/tools/config.guess ./jri/tools/config.guess.cdbs-orig; cp 
--remove-destination /usr/share/misc/config.guess ./jri/tools/config.guess;
set -e;   mv ./jri/tools/config.sub ./jri/tools/config.sub.cdbs-orig; cp 
--remove-destination /usr/share/misc/config.sub ./jri/tools/config.sub;
make[1]: Leaving directory '/build/rjava-0.9-9'
set -e;   
set -e;   
R CMD javareconf
*** JAVA_HOME is not a valid path, ignoring
Java interpreter : /usr/bin/java
Java version : 9-Debian
Java home path   : /usr/lib/jvm/java-9-openjdk-amd64
Java compiler: /usr/bin/javac
Java headers gen.: /usr/bin/javah
Java archive tool: /usr/bin/jar

trying to compile and link a JNI program 
detected JNI cpp flags: -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/linux
detected JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm
make[1]: Entering directory '/tmp/Rjavareconf.e0Jzrq'
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG 
-I/usr/lib/jvm/java-9-openjdk-amd64/include 
-I/usr/lib/jvm/java-9-openjdk-amd64/include/linux -fpic  -g -O2 
-fdebug-prefix-map=/build/r-base-3.4.2=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c conftest.c -o 
conftest.o
gcc -std=gnu99 -shared -L/usr/lib/R/lib -Wl,-z,relro -o conftest.so conftest.o 
-L/usr/lib/jvm/java-9-openjdk-amd64/lib/server -ljvm -L/usr/lib/R/lib -lR
make[1]: Leaving directory '/tmp/Rjavareconf.e0Jzrq'


JAVA_HOME: /usr/lib/jvm/java-9-openjdk-amd64
Java library path: $(JAVA_HOME)/lib/server
JNI cpp flags: -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/linux
JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm
Updating Java configuration in /usr/lib/R
/usr/lib/R/bin/javareconf: 406: /usr/lib/R/bin/javareconf: cannot create 
/usr/lib/R/etc/Makeconf.new: Permission denied
*** cannot create /usr/lib/R/etc/Makeconf.new
*** Please run as root if required.

debian/rules:9: recipe for target 'build/r-cran-rjava' failed
make: *** [build/r-cran-rjava] Error 1
dpkg-buildpackage: error: debian/rules build gave error exit status 2
-

So conftest.so is built.  Can we skip the subsequent javareconf?  If so,
where?  When I glance at your configure.ac I see several ...  And the
Makefile structure is not exactly trivial or standard either.

Dirk


| Cheers,
| Simon
| 
| 
| > On Oct 19, 2017, at 4:56 PM, Dirk Eddelbuettel  wrote:
| > 
| > 
| > On 19 October 2017 at 16:31, Simon Urbanek wrote:
| > | 
| > | > On Oct 19, 2017, at 4:12 PM, Dirk Eddelbuettel  wrote:
| > | > 
| > | > 
| > | > On 19 October 2017 at 15:47, Simon Urbanek wrote:
| > | > | R CMD javareconf is always needed to register Java support with R (on 
all unix platforms).
| > | > 
| > | > s/always/sometimes/
| > | > 
| > | > The values get encoded when I build R binaries.  For many years now, 
that was
| > | > good enough. 
| > | > 
| > | > | Like I said, I don't know what deb packages do here -
| > | > 
| > | > 'R CMD INSTALL sourceTarball_1.2-3.tar.gz  -- what else do you think I 
do?
| > | > 
| > | > | I presume you must do something in your R binary and all I can 
presume is that whatever the setup is then doesn't match what's there now.
| > | > 
| > | > 500+ CRAN packages packaged _exactly_ this.  rJava is a little 
different (for
| > | > an understandable reason;

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-10-19 Thread Simon Urbanek 
Dirk,

to clarify - this is about *R* configuration, not about rJava at all. rJava has 
nothing to do with those settings - it just uses what R was configured with. 
The only part rJava plays here is that it needs those R settings to be valid - 
just like other R packages that use Java.

As you reported the R configuration is broken, because the JAVA entry points to 
a non-existent file. I don't know why or how that happens. At least that's what 
I saw in the log:

checking Java support in R... present:
interpreter : '/usr/lib/jvm/default-java/jre/bin/java'
[...]
checking whether Java run-time works... ./configure: line 3736: 
/usr/lib/jvm/default-java/jre/bin/java: No such file or directory
no
configure: error: Java interpreter '/usr/lib/jvm/default-java/jre/bin/java' 
does not work

I presume that setting should have been /usr/lib/jvm/default-java/bin/java -- 
or JRE is required and missing (again, I don't know what package is providing 
that /usr/lib/jvm/default-java/jre/bin/java file used in the configuration).

Cheers,
Simon


> On Oct 19, 2017, at 4:56 PM, Dirk Eddelbuettel  wrote:
> 
> 
> On 19 October 2017 at 16:31, Simon Urbanek wrote:
> | 
> | > On Oct 19, 2017, at 4:12 PM, Dirk Eddelbuettel  wrote:
> | > 
> | > 
> | > On 19 October 2017 at 15:47, Simon Urbanek wrote:
> | > | R CMD javareconf is always needed to register Java support with R (on 
> all unix platforms).
> | > 
> | > s/always/sometimes/
> | > 
> | > The values get encoded when I build R binaries.  For many years now, that 
> was
> | > good enough. 
> | > 
> | > | Like I said, I don't know what deb packages do here -
> | > 
> | > 'R CMD INSTALL sourceTarball_1.2-3.tar.gz  -- what else do you think I do?
> | > 
> | > | I presume you must do something in your R binary and all I can presume 
> is that whatever the setup is then doesn't match what's there now.
> | > 
> | > 500+ CRAN packages packaged _exactly_ this.  rJava is a little different 
> (for
> | > an understandable reason; RInside is different too).
> | > 
> | > So ... tried that, still no luck:
> | > 
> | > ---
> | > [...]
> | > R CMD javareconf
> | > *** JAVA_HOME is not a valid path, ignoring
> | > Java interpreter : /usr/bin/java
> | > Java version : 9-Debian
> | > Java home path   : /usr/lib/jvm/java-9-openjdk-amd64
> | > Java compiler: /usr/bin/javac
> | > Java headers gen.: /usr/bin/javah
> | > Java archive tool: /usr/bin/jar
> | > 
> | > trying to compile and link a JNI program
> | > detected JNI cpp flags: -I$(JAVA_HOME)/include 
> -I$(JAVA_HOME)/include/linux
> | > detected JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm
> | > make[1]: Entering directory '/tmp/Rjavareconf.e0Jzrq'
> | > gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG 
> -I/usr/lib/jvm/java-9-openjdk-amd64/include 
> -I/usr/lib/jvm/java-9-openjdk-amd64/include/linux -fpic  -g -O2 
> -fdebug-prefix-map=/build/r-base-3.4.2=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c conftest.c -o 
> conftest.o
> | > gcc -std=gnu99 -shared -L/usr/lib/R/lib -Wl,-z,relro -o conftest.so 
> conftest.o -L/usr/lib/jvm/java-9-openjdk-amd64/lib/server -ljvm 
> -L/usr/lib/R/lib -lR
> | > make[1]: Leaving directory '/tmp/Rjavareconf.e0Jzrq'
> | > 
> | > 
> | > JAVA_HOME: /usr/lib/jvm/java-9-openjdk-amd64
> | > Java library path: $(JAVA_HOME)/lib/server
> | > JNI cpp flags: -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/linux
> | > JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm
> | > Updating Java configuration in /usr/lib/R
> | > /usr/lib/R/bin/javareconf: 406: /usr/lib/R/bin/javareconf: cannot create 
> /usr/lib/R/etc/Makeconf.new: Permission denied
> | > *** cannot create /usr/lib/R/etc/Makeconf.new
> | > *** Please run as root if required.
> | > [...]
> | > ---
> | > 
> | > All this is running as root.  But /usr may be mounted read-only.
> | > 
> | 
> | Right, you have to have write-access is /usr/lib/R/etc/ so it can update 
> the configuration to record your Java settings.
> 
> Well, in general we do _not_ have that and _cannot_ assume it, just like CRAN
> packages do _not_ get to write to $RHOME/bin.
> 
> _For Debian systems_ I offer (us, mostly) /etc/R/ with softlinks.
> 
> But if your package assumes /usr/lib for write only, we may be done here and
> it will get removed.
> 
> | I was asking because the above it obviously non-portable - i.e. if I
> | install Oracle Java the path will be different and also it will be different
> | for Java 1.8 etc. Hence you'd need to re-run javareconf any time the Java
> | configuration changes (thanks to Sun/Oracle for that wonderful design) -
> | unless you have canonical place you can use. From your original settings it
> | looked like you have some default-java symlink which would help here -
> 
> Not mine. That is the Debian Java folks.
> 
> | except that it has the broken path to java which is where the trouble 
> started in the first place. I suspect that

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-10-19 Thread Dirk Eddelbuettel 

On 19 October 2017 at 16:31, Simon Urbanek wrote:
| 
| > On Oct 19, 2017, at 4:12 PM, Dirk Eddelbuettel  wrote:
| > 
| > 
| > On 19 October 2017 at 15:47, Simon Urbanek wrote:
| > | R CMD javareconf is always needed to register Java support with R (on all 
unix platforms).
| > 
| > s/always/sometimes/
| > 
| > The values get encoded when I build R binaries.  For many years now, that 
was
| > good enough. 
| > 
| > | Like I said, I don't know what deb packages do here -
| > 
| > 'R CMD INSTALL sourceTarball_1.2-3.tar.gz  -- what else do you think I do?
| > 
| > | I presume you must do something in your R binary and all I can presume is 
that whatever the setup is then doesn't match what's there now.
| > 
| > 500+ CRAN packages packaged _exactly_ this.  rJava is a little different 
(for
| > an understandable reason; RInside is different too).
| > 
| > So ... tried that, still no luck:
| > 
| > ---
| > [...]
| > R CMD javareconf
| > *** JAVA_HOME is not a valid path, ignoring
| > Java interpreter : /usr/bin/java
| > Java version : 9-Debian
| > Java home path   : /usr/lib/jvm/java-9-openjdk-amd64
| > Java compiler: /usr/bin/javac
| > Java headers gen.: /usr/bin/javah
| > Java archive tool: /usr/bin/jar
| > 
| > trying to compile and link a JNI program
| > detected JNI cpp flags: -I$(JAVA_HOME)/include 
-I$(JAVA_HOME)/include/linux
| > detected JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm
| > make[1]: Entering directory '/tmp/Rjavareconf.e0Jzrq'
| > gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG 
-I/usr/lib/jvm/java-9-openjdk-amd64/include 
-I/usr/lib/jvm/java-9-openjdk-amd64/include/linux -fpic  -g -O2 
-fdebug-prefix-map=/build/r-base-3.4.2=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c conftest.c -o 
conftest.o
| > gcc -std=gnu99 -shared -L/usr/lib/R/lib -Wl,-z,relro -o conftest.so 
conftest.o -L/usr/lib/jvm/java-9-openjdk-amd64/lib/server -ljvm 
-L/usr/lib/R/lib -lR
| > make[1]: Leaving directory '/tmp/Rjavareconf.e0Jzrq'
| > 
| > 
| > JAVA_HOME: /usr/lib/jvm/java-9-openjdk-amd64
| > Java library path: $(JAVA_HOME)/lib/server
| > JNI cpp flags: -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/linux
| > JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm
| > Updating Java configuration in /usr/lib/R
| > /usr/lib/R/bin/javareconf: 406: /usr/lib/R/bin/javareconf: cannot create 
/usr/lib/R/etc/Makeconf.new: Permission denied
| > *** cannot create /usr/lib/R/etc/Makeconf.new
| > *** Please run as root if required.
| > [...]
| > ---
| > 
| > All this is running as root.  But /usr may be mounted read-only.
| > 
| 
| Right, you have to have write-access is /usr/lib/R/etc/ so it can update the 
configuration to record your Java settings.

Well, in general we do _not_ have that and _cannot_ assume it, just like CRAN
packages do _not_ get to write to $RHOME/bin.

_For Debian systems_ I offer (us, mostly) /etc/R/ with softlinks.

But if your package assumes /usr/lib for write only, we may be done here and
it will get removed.
 
| I was asking because the above it obviously non-portable - i.e. if I
| install Oracle Java the path will be different and also it will be different
| for Java 1.8 etc. Hence you'd need to re-run javareconf any time the Java
| configuration changes (thanks to Sun/Oracle for that wonderful design) -
| unless you have canonical place you can use. From your original settings it
| looked like you have some default-java symlink which would help here -

Not mine. That is the Debian Java folks.

| except that it has the broken path to java which is where the trouble started 
in the first place. I suspect that fixing your default config to have a valid 
path to java should be enough as long as that default setting is maintained at 
the system level.

No trouble _once I run R CMD javareconf_ earlier it built.  But we died in in
your post-processing, it seems.

Dirk

| Cheers,
| Simon
| 
| 
| 
| > Dirk
| > | 
| > | Cheers,
| > | Simon
| > | 
| > | 
| > | > On Oct 18, 2017, at 9:50 PM, Dirk Eddelbuettel  wrote:
| > | > 
| > | > 
| > | > Simon,
| > | > 
| > | > On 18 October 2017 at 21:34, Simon Urbanek wrote:
| > | > | Dirk,
| > | > | 
| > | > | I don't have the details but this looks like as incorrect Java 
configuration in R - the Java home is obviously incomplete as it's missing 
bin/java and/or that path is wrong. Also I'm surprised to the the odd paths 
"/usr/lib/jvm/default-java/" since at least in my installations I see the 
actual JVM being used - but then I don't know how your package (or Debian?) 
abstracts the Java version mess.
| > | > 
| > | > This was vanilla 'openjdk-9-jdk' and nothing else.
| > | > 
| > | > Could I / should invoke 'R CMD javareconf' ?
| > | > 
| > | > Dirk
| > | > 
| > | > | Cheers,
| > | > | Simon
| > | > | 
| > | > | 
| > | > | > On Oct 17, 2017, at 10:24 PM, Dirk Eddelbuettel  
wrote:
| > | > | > 
| > | > | > 
| > | > | > Simon,
| > | >

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-10-19 Thread Simon Urbanek 

> On Oct 19, 2017, at 4:12 PM, Dirk Eddelbuettel  wrote:
> 
> 
> On 19 October 2017 at 15:47, Simon Urbanek wrote:
> | R CMD javareconf is always needed to register Java support with R (on all 
> unix platforms).
> 
> s/always/sometimes/
> 
> The values get encoded when I build R binaries.  For many years now, that was
> good enough. 
> 
> | Like I said, I don't know what deb packages do here -
> 
> 'R CMD INSTALL sourceTarball_1.2-3.tar.gz  -- what else do you think I do?
> 
> | I presume you must do something in your R binary and all I can presume is 
> that whatever the setup is then doesn't match what's there now.
> 
> 500+ CRAN packages packaged _exactly_ this.  rJava is a little different (for
> an understandable reason; RInside is different too).
> 
> So ... tried that, still no luck:
> 
> ---
> [...]
> R CMD javareconf
> *** JAVA_HOME is not a valid path, ignoring
> Java interpreter : /usr/bin/java
> Java version : 9-Debian
> Java home path   : /usr/lib/jvm/java-9-openjdk-amd64
> Java compiler: /usr/bin/javac
> Java headers gen.: /usr/bin/javah
> Java archive tool: /usr/bin/jar
> 
> trying to compile and link a JNI program
> detected JNI cpp flags: -I$(JAVA_HOME)/include 
> -I$(JAVA_HOME)/include/linux
> detected JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm
> make[1]: Entering directory '/tmp/Rjavareconf.e0Jzrq'
> gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG 
> -I/usr/lib/jvm/java-9-openjdk-amd64/include 
> -I/usr/lib/jvm/java-9-openjdk-amd64/include/linux -fpic  -g -O2 
> -fdebug-prefix-map=/build/r-base-3.4.2=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c conftest.c -o 
> conftest.o
> gcc -std=gnu99 -shared -L/usr/lib/R/lib -Wl,-z,relro -o conftest.so 
> conftest.o -L/usr/lib/jvm/java-9-openjdk-amd64/lib/server -ljvm 
> -L/usr/lib/R/lib -lR
> make[1]: Leaving directory '/tmp/Rjavareconf.e0Jzrq'
> 
> 
> JAVA_HOME: /usr/lib/jvm/java-9-openjdk-amd64
> Java library path: $(JAVA_HOME)/lib/server
> JNI cpp flags: -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/linux
> JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm
> Updating Java configuration in /usr/lib/R
> /usr/lib/R/bin/javareconf: 406: /usr/lib/R/bin/javareconf: cannot create 
> /usr/lib/R/etc/Makeconf.new: Permission denied
> *** cannot create /usr/lib/R/etc/Makeconf.new
> *** Please run as root if required.
> [...]
> ---
> 
> All this is running as root.  But /usr may be mounted read-only.
> 

Right, you have to have write-access is /usr/lib/R/etc/ so it can update the 
configuration to record your Java settings.

I was asking because the above it obviously non-portable - i.e. if I install 
Oracle Java the path will be different and also it will be different for Java 
1.8 etc. Hence you'd need to re-run javareconf any time the Java configuration 
changes (thanks to Sun/Oracle for that wonderful design) - unless you have 
canonical place you can use. From your original settings it looked like you 
have some default-java symlink which would help here - except that it has the 
broken path to java which is where the trouble started in the first place. I 
suspect that fixing your default config to have a valid path to java should be 
enough as long as that default setting is maintained at the system level.

Cheers,
Simon



> Dirk
> | 
> | Cheers,
> | Simon
> | 
> | 
> | > On Oct 18, 2017, at 9:50 PM, Dirk Eddelbuettel  wrote:
> | > 
> | > 
> | > Simon,
> | > 
> | > On 18 October 2017 at 21:34, Simon Urbanek wrote:
> | > | Dirk,
> | > | 
> | > | I don't have the details but this looks like as incorrect Java 
> configuration in R - the Java home is obviously incomplete as it's missing 
> bin/java and/or that path is wrong. Also I'm surprised to the the odd paths 
> "/usr/lib/jvm/default-java/" since at least in my installations I see the 
> actual JVM being used - but then I don't know how your package (or Debian?) 
> abstracts the Java version mess.
> | > 
> | > This was vanilla 'openjdk-9-jdk' and nothing else.
> | > 
> | > Could I / should invoke 'R CMD javareconf' ?
> | > 
> | > Dirk
> | > 
> | > | Cheers,
> | > | Simon
> | > | 
> | > | 
> | > | > On Oct 17, 2017, at 10:24 PM, Dirk Eddelbuettel  
> wrote:
> | > | > 
> | > | > 
> | > | > Simon,
> | > | > 
> | > | > With your new rJava_0.9-9 I tried this against Debian's openjdk-9-jdk 
> -- but
> | > | > with R 3.4.2 as built against openjdk-7 -- and it still fails:
> | > | > 
> | > | > checking whether setjmp.h is POSIX.1 compatible... yes
> | > | > checking whether sigsetjmp is declared... yes
> | > | > checking whether siglongjmp is declared... yes
> | > | > checking Java support in R... present:
> | > | > interpreter : '/usr/lib/jvm/default-java/jre/bin/java'
> | > | > archiver: '/usr/lib/jvm/default-java/bin/jar'
> | > | > compiler: '/usr/lib/jvm/default-java/bin/javac'
> | > | > header prep.: '/usr/lib/jvm/default-java/bin/javah'
> | > | >

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-10-19 Thread Dirk Eddelbuettel 

On 19 October 2017 at 15:47, Simon Urbanek wrote:
| R CMD javareconf is always needed to register Java support with R (on all 
unix platforms).

s/always/sometimes/

The values get encoded when I build R binaries.  For many years now, that was
good enough. 

| Like I said, I don't know what deb packages do here -

'R CMD INSTALL sourceTarball_1.2-3.tar.gz  -- what else do you think I do?

| I presume you must do something in your R binary and all I can presume is 
that whatever the setup is then doesn't match what's there now.

500+ CRAN packages packaged _exactly_ this.  rJava is a little different (for
an understandable reason; RInside is different too).

So ... tried that, still no luck:

---
[...]
R CMD javareconf
*** JAVA_HOME is not a valid path, ignoring
Java interpreter : /usr/bin/java
Java version : 9-Debian
Java home path   : /usr/lib/jvm/java-9-openjdk-amd64
Java compiler: /usr/bin/javac
Java headers gen.: /usr/bin/javah
Java archive tool: /usr/bin/jar

trying to compile and link a JNI program
detected JNI cpp flags: -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/linux
detected JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm
make[1]: Entering directory '/tmp/Rjavareconf.e0Jzrq'
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG 
-I/usr/lib/jvm/java-9-openjdk-amd64/include 
-I/usr/lib/jvm/java-9-openjdk-amd64/include/linux -fpic  -g -O2 
-fdebug-prefix-map=/build/r-base-3.4.2=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c conftest.c -o 
conftest.o
gcc -std=gnu99 -shared -L/usr/lib/R/lib -Wl,-z,relro -o conftest.so conftest.o 
-L/usr/lib/jvm/java-9-openjdk-amd64/lib/server -ljvm -L/usr/lib/R/lib -lR
make[1]: Leaving directory '/tmp/Rjavareconf.e0Jzrq'


JAVA_HOME: /usr/lib/jvm/java-9-openjdk-amd64
Java library path: $(JAVA_HOME)/lib/server
JNI cpp flags: -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/linux
JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm
Updating Java configuration in /usr/lib/R
/usr/lib/R/bin/javareconf: 406: /usr/lib/R/bin/javareconf: cannot create 
/usr/lib/R/etc/Makeconf.new: Permission denied
*** cannot create /usr/lib/R/etc/Makeconf.new
*** Please run as root if required.
[...]
---

All this is running as root.  But /usr may be mounted read-only.

Dirk
| 
| Cheers,
| Simon
| 
| 
| > On Oct 18, 2017, at 9:50 PM, Dirk Eddelbuettel  wrote:
| > 
| > 
| > Simon,
| > 
| > On 18 October 2017 at 21:34, Simon Urbanek wrote:
| > | Dirk,
| > | 
| > | I don't have the details but this looks like as incorrect Java 
configuration in R - the Java home is obviously incomplete as it's missing 
bin/java and/or that path is wrong. Also I'm surprised to the the odd paths 
"/usr/lib/jvm/default-java/" since at least in my installations I see the 
actual JVM being used - but then I don't know how your package (or Debian?) 
abstracts the Java version mess.
| > 
| > This was vanilla 'openjdk-9-jdk' and nothing else.
| > 
| > Could I / should invoke 'R CMD javareconf' ?
| > 
| > Dirk
| > 
| > | Cheers,
| > | Simon
| > | 
| > | 
| > | > On Oct 17, 2017, at 10:24 PM, Dirk Eddelbuettel  wrote:
| > | > 
| > | > 
| > | > Simon,
| > | > 
| > | > With your new rJava_0.9-9 I tried this against Debian's openjdk-9-jdk 
-- but
| > | > with R 3.4.2 as built against openjdk-7 -- and it still fails:
| > | > 
| > | > checking whether setjmp.h is POSIX.1 compatible... yes
| > | > checking whether sigsetjmp is declared... yes
| > | > checking whether siglongjmp is declared... yes
| > | > checking Java support in R... present:
| > | > interpreter : '/usr/lib/jvm/default-java/jre/bin/java'
| > | > archiver: '/usr/lib/jvm/default-java/bin/jar'
| > | > compiler: '/usr/lib/jvm/default-java/bin/javac'
| > | > header prep.: '/usr/lib/jvm/default-java/bin/javah'
| > | > cpp flags   : '-I/usr/lib/jvm/default-java/include 
-I/usr/lib/jvm/default-java/include/linux'
| > | > java libs   : '-L/usr/lib/jvm/default-java/jre/lib/amd64/server -ljvm'
| > | > checking whether Java run-time works... ./configure: line 3736: 
/usr/lib/jvm/default-java/jre/bin/java: No such file or directory
| > | > no
| > | > configure: error: Java interpreter 
'/usr/lib/jvm/default-java/jre/bin/java' does not work
| > | > ERROR: configuration failed for package 'rJava'
| > | > * removing 
'/build/rjava-0.9-9/debian/r-cran-rjava/usr/lib/R/site-library/rJava'
| > | > /usr/share/R/debian/r-cran.mk:101: recipe for target 'R_any_arch' failed
| > | > make: *** [R_any_arch] Error 1
| > | > dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit 
status 2
| > | > 
| > | > 
| > | > Any ideas?  I saw that r-devel got some changes related to javareconf.  
Do we
| > | > need to port that to r-patched?  Can you advise?
| > | > 
| > | > Many thanks,  Dirk
| > | > 
| > | > -- 
| > | > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| > | > 
| > | 
| > 
| > -- 
| > http://dirk.eddelbuettel.com | @eddelbuettel |

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-10-19 Thread Simon Urbanek 
R CMD javareconf is always needed to register Java support with R (on all unix 
platforms). Like I said, I don't know what deb packages do here - I presume you 
must do something in your R binary and all I can presume is that whatever the 
setup is then doesn't match what's there now.

Cheers,
Simon


> On Oct 18, 2017, at 9:50 PM, Dirk Eddelbuettel  wrote:
> 
> 
> Simon,
> 
> On 18 October 2017 at 21:34, Simon Urbanek wrote:
> | Dirk,
> | 
> | I don't have the details but this looks like as incorrect Java 
> configuration in R - the Java home is obviously incomplete as it's missing 
> bin/java and/or that path is wrong. Also I'm surprised to the the odd paths 
> "/usr/lib/jvm/default-java/" since at least in my installations I see the 
> actual JVM being used - but then I don't know how your package (or Debian?) 
> abstracts the Java version mess.
> 
> This was vanilla 'openjdk-9-jdk' and nothing else.
> 
> Could I / should invoke 'R CMD javareconf' ?
> 
> Dirk
> 
> | Cheers,
> | Simon
> | 
> | 
> | > On Oct 17, 2017, at 10:24 PM, Dirk Eddelbuettel  wrote:
> | > 
> | > 
> | > Simon,
> | > 
> | > With your new rJava_0.9-9 I tried this against Debian's openjdk-9-jdk -- 
> but
> | > with R 3.4.2 as built against openjdk-7 -- and it still fails:
> | > 
> | > checking whether setjmp.h is POSIX.1 compatible... yes
> | > checking whether sigsetjmp is declared... yes
> | > checking whether siglongjmp is declared... yes
> | > checking Java support in R... present:
> | > interpreter : '/usr/lib/jvm/default-java/jre/bin/java'
> | > archiver: '/usr/lib/jvm/default-java/bin/jar'
> | > compiler: '/usr/lib/jvm/default-java/bin/javac'
> | > header prep.: '/usr/lib/jvm/default-java/bin/javah'
> | > cpp flags   : '-I/usr/lib/jvm/default-java/include 
> -I/usr/lib/jvm/default-java/include/linux'
> | > java libs   : '-L/usr/lib/jvm/default-java/jre/lib/amd64/server -ljvm'
> | > checking whether Java run-time works... ./configure: line 3736: 
> /usr/lib/jvm/default-java/jre/bin/java: No such file or directory
> | > no
> | > configure: error: Java interpreter 
> '/usr/lib/jvm/default-java/jre/bin/java' does not work
> | > ERROR: configuration failed for package 'rJava'
> | > * removing 
> '/build/rjava-0.9-9/debian/r-cran-rjava/usr/lib/R/site-library/rJava'
> | > /usr/share/R/debian/r-cran.mk:101: recipe for target 'R_any_arch' failed
> | > make: *** [R_any_arch] Error 1
> | > dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit 
> status 2
> | > 
> | > 
> | > Any ideas?  I saw that r-devel got some changes related to javareconf.  
> Do we
> | > need to port that to r-patched?  Can you advise?
> | > 
> | > Many thanks,  Dirk
> | > 
> | > -- 
> | > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> | > 
> | 
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-10-18 Thread Dirk Eddelbuettel 

Simon,

On 18 October 2017 at 21:34, Simon Urbanek wrote:
| Dirk,
| 
| I don't have the details but this looks like as incorrect Java configuration 
in R - the Java home is obviously incomplete as it's missing bin/java and/or 
that path is wrong. Also I'm surprised to the the odd paths 
"/usr/lib/jvm/default-java/" since at least in my installations I see the 
actual JVM being used - but then I don't know how your package (or Debian?) 
abstracts the Java version mess.

This was vanilla 'openjdk-9-jdk' and nothing else.

Could I / should invoke 'R CMD javareconf' ?

Dirk
 
| Cheers,
| Simon
| 
| 
| > On Oct 17, 2017, at 10:24 PM, Dirk Eddelbuettel  wrote:
| > 
| > 
| > Simon,
| > 
| > With your new rJava_0.9-9 I tried this against Debian's openjdk-9-jdk -- but
| > with R 3.4.2 as built against openjdk-7 -- and it still fails:
| > 
| > checking whether setjmp.h is POSIX.1 compatible... yes
| > checking whether sigsetjmp is declared... yes
| > checking whether siglongjmp is declared... yes
| > checking Java support in R... present:
| > interpreter : '/usr/lib/jvm/default-java/jre/bin/java'
| > archiver: '/usr/lib/jvm/default-java/bin/jar'
| > compiler: '/usr/lib/jvm/default-java/bin/javac'
| > header prep.: '/usr/lib/jvm/default-java/bin/javah'
| > cpp flags   : '-I/usr/lib/jvm/default-java/include 
-I/usr/lib/jvm/default-java/include/linux'
| > java libs   : '-L/usr/lib/jvm/default-java/jre/lib/amd64/server -ljvm'
| > checking whether Java run-time works... ./configure: line 3736: 
/usr/lib/jvm/default-java/jre/bin/java: No such file or directory
| > no
| > configure: error: Java interpreter '/usr/lib/jvm/default-java/jre/bin/java' 
does not work
| > ERROR: configuration failed for package 'rJava'
| > * removing 
'/build/rjava-0.9-9/debian/r-cran-rjava/usr/lib/R/site-library/rJava'
| > /usr/share/R/debian/r-cran.mk:101: recipe for target 'R_any_arch' failed
| > make: *** [R_any_arch] Error 1
| > dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit 
status 2
| > 
| > 
| > Any ideas?  I saw that r-devel got some changes related to javareconf.  Do 
we
| > need to port that to r-patched?  Can you advise?
| > 
| > Many thanks,  Dirk
| > 
| > -- 
| > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| > 
| 

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-10-18 Thread Simon Urbanek 
Dirk,

I don't have the details but this looks like as incorrect Java configuration in 
R - the Java home is obviously incomplete as it's missing bin/java and/or that 
path is wrong. Also I'm surprised to the the odd paths 
"/usr/lib/jvm/default-java/" since at least in my installations I see the 
actual JVM being used - but then I don't know how your package (or Debian?) 
abstracts the Java version mess.

Cheers,
Simon


> On Oct 17, 2017, at 10:24 PM, Dirk Eddelbuettel  wrote:
> 
> 
> Simon,
> 
> With your new rJava_0.9-9 I tried this against Debian's openjdk-9-jdk -- but
> with R 3.4.2 as built against openjdk-7 -- and it still fails:
> 
> checking whether setjmp.h is POSIX.1 compatible... yes
> checking whether sigsetjmp is declared... yes
> checking whether siglongjmp is declared... yes
> checking Java support in R... present:
> interpreter : '/usr/lib/jvm/default-java/jre/bin/java'
> archiver: '/usr/lib/jvm/default-java/bin/jar'
> compiler: '/usr/lib/jvm/default-java/bin/javac'
> header prep.: '/usr/lib/jvm/default-java/bin/javah'
> cpp flags   : '-I/usr/lib/jvm/default-java/include 
> -I/usr/lib/jvm/default-java/include/linux'
> java libs   : '-L/usr/lib/jvm/default-java/jre/lib/amd64/server -ljvm'
> checking whether Java run-time works... ./configure: line 3736: 
> /usr/lib/jvm/default-java/jre/bin/java: No such file or directory
> no
> configure: error: Java interpreter '/usr/lib/jvm/default-java/jre/bin/java' 
> does not work
> ERROR: configuration failed for package 'rJava'
> * removing 
> '/build/rjava-0.9-9/debian/r-cran-rjava/usr/lib/R/site-library/rJava'
> /usr/share/R/debian/r-cran.mk:101: recipe for target 'R_any_arch' failed
> make: *** [R_any_arch] Error 1
> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 
> 2
> 
> 
> Any ideas?  I saw that r-devel got some changes related to javareconf.  Do we
> need to port that to r-patched?  Can you advise?
> 
> Many thanks,  Dirk
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-10-17 Thread Dirk Eddelbuettel 

Simon,

With your new rJava_0.9-9 I tried this against Debian's openjdk-9-jdk -- but
with R 3.4.2 as built against openjdk-7 -- and it still fails:

checking whether setjmp.h is POSIX.1 compatible... yes
checking whether sigsetjmp is declared... yes
checking whether siglongjmp is declared... yes
checking Java support in R... present:
interpreter : '/usr/lib/jvm/default-java/jre/bin/java'
archiver: '/usr/lib/jvm/default-java/bin/jar'
compiler: '/usr/lib/jvm/default-java/bin/javac'
header prep.: '/usr/lib/jvm/default-java/bin/javah'
cpp flags   : '-I/usr/lib/jvm/default-java/include 
-I/usr/lib/jvm/default-java/include/linux'
java libs   : '-L/usr/lib/jvm/default-java/jre/lib/amd64/server -ljvm'
checking whether Java run-time works... ./configure: line 3736: 
/usr/lib/jvm/default-java/jre/bin/java: No such file or directory
no
configure: error: Java interpreter '/usr/lib/jvm/default-java/jre/bin/java' 
does not work
ERROR: configuration failed for package 'rJava'
* removing '/build/rjava-0.9-9/debian/r-cran-rjava/usr/lib/R/site-library/rJava'
/usr/share/R/debian/r-cran.mk:101: recipe for target 'R_any_arch' failed
make: *** [R_any_arch] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2


Any ideas?  I saw that r-devel got some changes related to javareconf.  Do we
need to port that to r-patched?  Can you advise?

Many thanks,  Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#874153: FTBFS with Java 9: jre/bin/java

2017-09-03 Thread Chris West 
Source: rjava
Version: 0.9-8
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

The /jre/ has vanished from paths inside /usr/lib/jvm. You probably
shouldn't be relying on these anyway, just use "java" from path?

Build log:

java libs   : '-L/usr/lib/jvm/default-java/jre/lib/amd64/server -ljvm'
checking whether Java run-time works... ./configure: line 3736: 
/usr/lib/jvm/default-java/jre/bin/java: No such file or directory
no
configure: error: Java interpreter '/usr/lib/jvm/default-java/jre/bin/java' 
does not work
ERROR: configuration failed for package 'rJava'
* removing '/build/rjava-0.9-8/debian/r-cran-rjava/usr/lib/R/site-library/rJava'
/usr/share/R/debian/r-cran.mk:101: recipe for target 'R_any_arch' failed




Cheers,
Chris.