Re: Possible workaround (was: Re: Help: r-cran-treescape does not build on i386, armel and armhf any more)
severity 845753 important thanks Hi Christian, On Wed, Dec 14, 2016 at 03:37:27PM +0100, Christian Seiler wrote: > > Anyway, to work around this for now, you can replace your > dh_auto_install line (that is passed to the xvfb call) > with the following command: > > /bin/sh -c "ulimit -S -s 20 ; exec dh_auto_install" > > Just tried it, sbuild built the package successfully on > i386. I haven't tried armhf, but I suspect the result will > be the same. Since I was lacking any better idea I used this workaround and at least downgrade the severity of the bug hereby from serious to important. I can confirm that all affected architectures are building now. It might be important to mention that after a first upload also mips64el failed which was not affected by the problem before. Thus in addition to the unclear failure it seems that some randomness is involved. :-( I have implemented the workaround only for this version. It needs to be explicitly restored for any new upstream version thus we will notice if the problem persists for any later upstream versions. In any case thanks a lot for Christian to spent this effort on the problem Andreas. -- http://fam-tille.de
Re: Possible workaround (was: Re: Help: r-cran-treescape does not build on i386, armel and armhf any more)
On 14 December 2016 at 15:59, Andreas Tille wrote: | Hi Christian, | | thanks a lot for your extensive analysis about of the stack problem. I | admit I have no idea why this large stack is needed on those | architectures with stable kernel. I also have no idea why everything | went fine with treescape version 1.10.17. Since I personally fell | totally clueless I'm forwarding this upstream and also CC Dirk | Eddelbuettel who is known for his insight and good contact to the R | community. May be somebody has a better clue rather than drastically | increasing the stack size on those failed architectures. One quick thought: does it die in _compilation_ which we have seen with other (C++-heavy) packages? I know that this helps at times: export CXX=g++ --param ggc-min-expand=20 -g0 Otherwise if it fails _after_ compilation we may be able to get by turning some default aspects of R CMD INSTALL off: --no-byte-compile do not byte-compile R code --no-test-loadskip test of loading installed package But that is just guessing on my part and we'd have to test the package. Dirk (at work) | Thanks again | | Andreas. | | On Wed, Dec 14, 2016 at 03:37:27PM +0100, Christian Seiler wrote: | > Hi again, | > | > On 12/14/2016 03:00 PM, Christian Seiler wrote: | > > If I had to guess what was going on in the backtrace, I'd suspect | > > an infinite recursion in R code, which translates to infinite | > > recursion of the underlying C code. But I'm really not sure here. | > | > Interestingly enough, my initial guess was wrong. | > | > It's not an infinite recursion, it's just a very, very deep | > recursion, using a LOT of stack. If I increase the stack size | > limit by to 200 MB, then the package builds successfully, | > I tried that in a loop 25 times. | > | > However, with an earlier attempt at 160 MB stack size limit, | > it worked most of the time, but not always, I did get the | > same error once, so the amount of stack space required does | > not appear to be the same when calling the program multiple | > times. (With 160 MB I tried around 15 times, and once the | > 160 MB limit was insufficient.) | > | > It might even be in rare cases that the 200 MB limit is not | > enough and a build could fail spuriously even with that. | > | > > Why that only appears to occur on 32bit LE architectures with | > > stable kernels (and works fine with unstable kernels on the same | > > architecture, and even with the stable kernel on 64bit both LE | > > and BE, as well as on 32bit BE) I also have no clue. | > | > And this is still beyond me, because the default stack size | > limit of 8 MB is more than sufficient on e.g. amd64, where | > pointers are twice as large, so the amount of stack frames | > that fit in that limit there is actually smaller. | > | > So it appears you can work around this bug by manually | > setting an artificially high stack size limit during the | > build, but there is still an underlying problem there that | > causes the stack usage to be drastically higher on | > 32bit LE platforms with kernel 3.16, that doesn't appear | > on the same platforms with a newer kernel. | > | > Anyway, to work around this for now, you can replace your | > dh_auto_install line (that is passed to the xvfb call) | > with the following command: | > | > /bin/sh -c "ulimit -S -s 20 ; exec dh_auto_install" | > | > Just tried it, sbuild built the package successfully on | > i386. I haven't tried armhf, but I suspect the result will | > be the same. | > | > But the underlying problem should also be fixed: a stack | > size that is 25 times higher than usual is worrisome, | > especially with the standard limit being plenty sufficient | > on platforms with larger pointer sizes. You might have to | > ask upstream and/or the R community for advice though. (Maybe | > see what R function specifically does this deep recursion, | > and fix that function to be a lot shallower. I don't know | > how to get that information from a gdb backtrace though, as | > I don't know the internals of R.) | > | > Hope that helps. | > | > Regards, | > Christian | > | | -- | http://fam-tille.de -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Possible workaround (was: Re: Help: r-cran-treescape does not build on i386, armel and armhf any more)
Hi Christian, thanks a lot for your extensive analysis about of the stack problem. I admit I have no idea why this large stack is needed on those architectures with stable kernel. I also have no idea why everything went fine with treescape version 1.10.17. Since I personally fell totally clueless I'm forwarding this upstream and also CC Dirk Eddelbuettel who is known for his insight and good contact to the R community. May be somebody has a better clue rather than drastically increasing the stack size on those failed architectures. Thanks again Andreas. On Wed, Dec 14, 2016 at 03:37:27PM +0100, Christian Seiler wrote: > Hi again, > > On 12/14/2016 03:00 PM, Christian Seiler wrote: > > If I had to guess what was going on in the backtrace, I'd suspect > > an infinite recursion in R code, which translates to infinite > > recursion of the underlying C code. But I'm really not sure here. > > Interestingly enough, my initial guess was wrong. > > It's not an infinite recursion, it's just a very, very deep > recursion, using a LOT of stack. If I increase the stack size > limit by to 200 MB, then the package builds successfully, > I tried that in a loop 25 times. > > However, with an earlier attempt at 160 MB stack size limit, > it worked most of the time, but not always, I did get the > same error once, so the amount of stack space required does > not appear to be the same when calling the program multiple > times. (With 160 MB I tried around 15 times, and once the > 160 MB limit was insufficient.) > > It might even be in rare cases that the 200 MB limit is not > enough and a build could fail spuriously even with that. > > > Why that only appears to occur on 32bit LE architectures with > > stable kernels (and works fine with unstable kernels on the same > > architecture, and even with the stable kernel on 64bit both LE > > and BE, as well as on 32bit BE) I also have no clue. > > And this is still beyond me, because the default stack size > limit of 8 MB is more than sufficient on e.g. amd64, where > pointers are twice as large, so the amount of stack frames > that fit in that limit there is actually smaller. > > So it appears you can work around this bug by manually > setting an artificially high stack size limit during the > build, but there is still an underlying problem there that > causes the stack usage to be drastically higher on > 32bit LE platforms with kernel 3.16, that doesn't appear > on the same platforms with a newer kernel. > > Anyway, to work around this for now, you can replace your > dh_auto_install line (that is passed to the xvfb call) > with the following command: > > /bin/sh -c "ulimit -S -s 20 ; exec dh_auto_install" > > Just tried it, sbuild built the package successfully on > i386. I haven't tried armhf, but I suspect the result will > be the same. > > But the underlying problem should also be fixed: a stack > size that is 25 times higher than usual is worrisome, > especially with the standard limit being plenty sufficient > on platforms with larger pointer sizes. You might have to > ask upstream and/or the R community for advice though. (Maybe > see what R function specifically does this deep recursion, > and fix that function to be a lot shallower. I don't know > how to get that information from a gdb backtrace though, as > I don't know the internals of R.) > > Hope that helps. > > Regards, > Christian > -- http://fam-tille.de
Possible workaround (was: Re: Help: r-cran-treescape does not build on i386, armel and armhf any more)
Hi again, On 12/14/2016 03:00 PM, Christian Seiler wrote: > If I had to guess what was going on in the backtrace, I'd suspect > an infinite recursion in R code, which translates to infinite > recursion of the underlying C code. But I'm really not sure here. Interestingly enough, my initial guess was wrong. It's not an infinite recursion, it's just a very, very deep recursion, using a LOT of stack. If I increase the stack size limit by to 200 MB, then the package builds successfully, I tried that in a loop 25 times. However, with an earlier attempt at 160 MB stack size limit, it worked most of the time, but not always, I did get the same error once, so the amount of stack space required does not appear to be the same when calling the program multiple times. (With 160 MB I tried around 15 times, and once the 160 MB limit was insufficient.) It might even be in rare cases that the 200 MB limit is not enough and a build could fail spuriously even with that. > Why that only appears to occur on 32bit LE architectures with > stable kernels (and works fine with unstable kernels on the same > architecture, and even with the stable kernel on 64bit both LE > and BE, as well as on 32bit BE) I also have no clue. And this is still beyond me, because the default stack size limit of 8 MB is more than sufficient on e.g. amd64, where pointers are twice as large, so the amount of stack frames that fit in that limit there is actually smaller. So it appears you can work around this bug by manually setting an artificially high stack size limit during the build, but there is still an underlying problem there that causes the stack usage to be drastically higher on 32bit LE platforms with kernel 3.16, that doesn't appear on the same platforms with a newer kernel. Anyway, to work around this for now, you can replace your dh_auto_install line (that is passed to the xvfb call) with the following command: /bin/sh -c "ulimit -S -s 20 ; exec dh_auto_install" Just tried it, sbuild built the package successfully on i386. I haven't tried armhf, but I suspect the result will be the same. But the underlying problem should also be fixed: a stack size that is 25 times higher than usual is worrisome, especially with the standard limit being plenty sufficient on platforms with larger pointer sizes. You might have to ask upstream and/or the R community for advice though. (Maybe see what R function specifically does this deep recursion, and fix that function to be a lot shallower. I don't know how to get that information from a gdb backtrace though, as I don't know the internals of R.) Hope that helps. Regards, Christian
Re: Help: r-cran-treescape does not build on i386, armel and armhf any more
Hi Andreas,
On 12/14/2016 11:47 AM, Christian Seiler wrote:
> On 12/14/2016 08:50 AM, Christian Seiler wrote:
>> I'm going to try an i386 build in a VM running a stable kernel
>> and see if that does indeed change things and if I can reproduce
>> the problem. Should that not be the issue though then I really
>> can't reproduce the problem - and hence won't be able to debug
>> it... Let's see...
>
> Indeed: in a VM with Jessie + sbuild from jessie-backports the
> build fails with a segfault:
>
> ** preparing package for lazy loading
> Creating a generic function for 'toJSON' from package 'jsonlite' in package
> 'googleVis'
> Error: segfault from C stack overflow
> * removing
> '/<>/debian/r-cran-treescape/usr/lib/R/site-library/treescape'
> dh_auto_install: R CMD INSTALL -l
> /<>/debian/r-cran-treescape/usr/lib/R/site-library --clean .
> --built-timestamp='Wed, 14 Dec 2016 06:45:37 +0100' returned exit code 1
>
> Now that I can reporduce this, I'll investigate more later.
Well, the stack overflow appears to be an endless loop.
I've attached a stack backtrace I obtained via gdb.
If I had to guess what was going on in the backtrace, I'd suspect
an infinite recursion in R code, which translates to infinite
recursion of the underlying C code. But I'm really not sure here.
Why that only appears to occur on 32bit LE architectures with
stable kernels (and works fine with unstable kernels on the same
architecture, and even with the stable kernel on 64bit both LE
and BE, as well as on 32bit BE) I also have no clue.
Fun fact: if you call R -d gdb, type in "run" at the gdb prompt and
then type in the following at the R prompt:
install.packages(repos=NULL,
lib=".../r-cran-treescape-1.10.18/debian/r-cran-treescape/usr/lib/R/site-library",
clean=TRUE,
pkgs=".",
configure.args=("--built-timestamp='Wed, 14 Dec 2016 06:45:37 +0100'")
)
instead of running the command directly as
R CMD INSTALL \
-l
.../r-cran-treescape-1.10.18/debian/r-cran-treescape/usr/lib/R/site-library \
--clean \
. \
"--built-timestamp='Wed, 14 Dec 2016 06:45:37 +0100'"
this will cause the build go through successfully. However, running
the R CMD INSTALL directly (in a fresh source package directory)
will still trigger the error - and you can attach with gdb from
another console.
Also, if the source directory is not completely clean, then
sometimes stuff is left lying around in there, after which all
calls to the R CMD INSTALL will succeed.
Unfortunately I know next to nothing about R's internals so I have
no idea what to do with it. If anyone has a pointer on how to read
the backtrace or someone with more R experience can tell me what to
look out for and how to extract useful information from that, I'd be
willing to revisit this, but otherwise I'm forced to let this go,
sorry.
Regards,
Christian
#0 bcEval (body=body@entry=0xf88c4674, rho=rho@entry=0xfe83f6d4,
useCache=useCache@entry=TRUE) at eval.c:5172
#1 0xf74353c6 in Rf_eval (e=0xf88c4674, rho=0xfe83f6d4) at eval.c:616
#2 0xf7435c6f in forcePromise (e=e@entry=0xfe83f6f0) at eval.c:515
#3 0xf7436177 in FORCE_PROMISE (keepmiss=FALSE, rho=0xfe83f7ec,
symbol=0xf8822b38, value=0xfe83f6f0) at eval.c:4258
#4 getvar (symbol=0xf8822b38, rho=rho@entry=0xfe83f7ec, dd=dd@entry=FALSE,
keepmiss=FALSE, vcache=0xf4def33c, sidx=2) at eval.c:4300
#5 0xf742e377 in bcEval (body=body@entry=0xf88b81ec, rho=rho@entry=0xfe83f7ec,
useCache=useCache@entry=TRUE) at eval.c:5425
#6 0xf74353c6 in Rf_eval (e=0xf88b81ec, rho=0xfe83f7ec) at eval.c:616
#7 0xf7437201 in Rf_applyClosure (call=, op=,
arglist=, rho=, suppliedvars=) at
eval.c:1135
#8 0xf742fdfc in bcEval (body=body@entry=0xf88c30d0, rho=rho@entry=0xfe83f6d4,
useCache=useCache@entry=TRUE) at eval.c:5630
#9 0xf74353c6 in Rf_eval (e=0xf88c30d0, rho=0xfe83f6d4) at eval.c:616
#10 0xf7437201 in Rf_applyClosure (call=, op=,
arglist=, rho=, suppliedvars=) at
eval.c:1135
#11 0xf742fdfc in bcEval (body=body@entry=0xfe8802a8, rho=rho@entry=0xfe83f5f4,
useCache=useCache@entry=TRUE) at eval.c:5630
#12 0xf74353c6 in Rf_eval (e=0xfe8802a8, rho=0xfe83f5f4) at eval.c:616
#13 0xf7437201 in Rf_applyClosure (call=, op=,
arglist=, rho=, suppliedvars=) at
eval.c:1135
#14 0xf743989e in R_forceAndCall (e=, n=1, rho=)
at eval.c:1302
#15 0xf73a1ebc in do_lapply (call=0xf889559c, op=0xf87e4500, args=0xf8895580,
rho=0xfe8405cc) at apply.c:70
#16 0xf746883a in do_internal (call=, op=,
args=0xf8895580, env=) at names.c:1353
#17 0xf7429a69 in bcEval (body=body@entry=0xf88931d4, rho=rho@entry=0xfe8405cc,
useCache=useCache@entry=TRUE) at eval.c:5678
#18 0xf74353c6 in Rf_eval (e=0xf88931d4, rho=0xfe8405cc) at eval.c:616
#19 0xf7437201 in Rf_applyClosure (call=, op=,
arglist=, rho=, suppliedvars=) at
eval.c:1135
#20 0xf742fdfc in bcEval (body=body@entry=0xfe881280, rho=rho@entry=0xfe8402bc,
useCache=useCache@entry=TRUE) at eval.c:5630
#21 0xf74353c6 in Rf_eval (e=0xfe881280, rho=0xfe8402bc) at eval.c:616
Re: Help: r-cran-treescape does not build on i386, armel and armhf any more
Hi Andreas, On 12/14/2016 08:50 AM, Christian Seiler wrote: > I'm going to try an i386 build in a VM running a stable kernel > and see if that does indeed change things and if I can reproduce > the problem. Should that not be the issue though then I really > can't reproduce the problem - and hence won't be able to debug > it... Let's see... Indeed: in a VM with Jessie + sbuild from jessie-backports the build fails with a segfault: ** preparing package for lazy loading Creating a generic function for 'toJSON' from package 'jsonlite' in package 'googleVis' Error: segfault from C stack overflow * removing '/<>/debian/r-cran-treescape/usr/lib/R/site-library/treescape' dh_auto_install: R CMD INSTALL -l /<>/debian/r-cran-treescape/usr/lib/R/site-library --clean . --built-timestamp='Wed, 14 Dec 2016 06:45:37 +0100' returned exit code 1 Now that I can reporduce this, I'll investigate more later. Regards, Christian
Re: Help: r-cran-treescape does not build on i386, armel and armhf any more
Hi Andreas, On 12/14/2016 08:10 AM, Andreas Tille wrote: > On Wed, Dec 14, 2016 at 12:32:24AM +0100, Christian Seiler wrote: >> On 11/02/2016 05:20 PM, Andreas Tille wrote: >> >> Hmm, was going to take a shot at debugging your segfault, but I >> simply can't reproduce this: >> ... >> architectures. > > Unfortunately autobuilders keep on reproducing it. :-( :-( > I have uploaded a package where I fixed the xvfb issue and did a source > only upload to make sure also amd64 will be autobuilt. While amd64 is > fine (also regarding the xserver issue - thanks to Gregor for the hints) > the i386 build log[1] shows the > > ** inst > ** preparing package for lazy loading > Creating a generic function for 'toJSON' from package 'jsonlite' in package > 'googleVis' > Error: segfault from C stack overflow > * removing > '/«PKGBUILDDIR»/debian/r-cran-treescape/usr/lib/R/site-library/treescape' > > again even if the log also has gcc-6-base i386 6.2.1-6 and binutils > i386 2.27.51.20161212-1 - so the toolchain on autobuilder is the same as > it worked for you. Yeah. Hmmm. :( > There might be a difference between a qemu emulation > and real hardware, thought. But emulation is only for armhf, i386 is native on my architecture (amd64 can run i386 directly, and the autobuilders are also amd64 machines running i386 chroots, my setup should be identical). Funnily enough mipsel now also failed at the same point, which it previously didn't. The only other key difference I can see is that the failed builds all run a stable kernel - and the working builds (also the build previously working on powerpc) run a backports kernel (and I'm running testing here). OTOH, the amd64 and arm64 builds are also running on the stable kernel - but those are 64bit platforms. Then OTOH in the ports section of the buildd logs you have 32bit powerpc - and that is also on stable, but powerpc is big endian, in contrast to i386, armhf and mipsel. I'm really not sure what's going on there, but maybe there's a failure case for 32bit little endian architectures when running a 3.16 kernel? But that may be a complete red herring and coincidence... I'm going to try an i386 build in a VM running a stable kernel and see if that does indeed change things and if I can reproduce the problem. Should that not be the issue though then I really can't reproduce the problem - and hence won't be able to debug it... Let's see... Regards, Christian
Re: Help: r-cran-treescape does not build on i386, armel and armhf any more
Hi Christian, On Wed, Dec 14, 2016 at 12:32:24AM +0100, Christian Seiler wrote: > On 11/02/2016 05:20 PM, Andreas Tille wrote: > > Hmm, was going to take a shot at debugging your segfault, but I > simply can't reproduce this: > ... > architectures. Unfortunately autobuilders keep on reproducing it. :-( > I can provide full build logs if you need them. > > Maybe ask for a give-back at debian-wb-t...@lists.debian.org to > have the i386 and armhf buildds try the build again? As far as > I can tell the build should succeed... > > Notable differences between buildd chroot and my freshly created > one (in the i386 case): > > buildd:gcc 6.2.1-5, binutils 2.27.51.20161201-1 > my system: gcc 6.2.1-6, binutils 2.27.51.20161212-1 > > Maybe this was a toolchain bug that was fixed recently? If so, > maybe wait a couple of days (buildd chroots are updated twice > a week IIRC) and then ask for a give-back. I have uploaded a package where I fixed the xvfb issue and did a source only upload to make sure also amd64 will be autobuilt. While amd64 is fine (also regarding the xserver issue - thanks to Gregor for the hints) the i386 build log[1] shows the ** inst ** preparing package for lazy loading Creating a generic function for 'toJSON' from package 'jsonlite' in package 'googleVis' Error: segfault from C stack overflow * removing '/«PKGBUILDDIR»/debian/r-cran-treescape/usr/lib/R/site-library/treescape' again even if the log also has gcc-6-base i386 6.2.1-6 and binutils i386 2.27.51.20161212-1 - so the toolchain on autobuilder is the same as it worked for you. There might be a difference between a qemu emulation and real hardware, thought. Kind regards and thanks for checking anyway Andreas. [1] https://buildd.debian.org/status/fetch.php?pkg=r-cran-treescape&arch=i386&ver=1.10.18-2&stamp=1481697760 -- http://fam-tille.de
Re: Help: r-cran-treescape does not build on i386, armel and armhf any more
On Tue, Dec 13, 2016 at 06:18:56PM +0100, gregor herrmann wrote: > > This reminds me of my remark in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847397#25 > from last Friday :) +1 May be this workshop can be joined with "gdb for harmless Debian Med packagers". ;-) Kind regards Andreas. -- http://fam-tille.de
Re: Help: r-cran-treescape does not build on i386, armel and armhf any more
On 11/02/2016 05:20 PM, Andreas Tille wrote: > Warning in rgl.init(initValue, onlyNULL) : > RGL: unable to open X11 display > Warning: 'rgl_init' failed, running with rgl.useNULL = TRUE > Error: segfault from C stack overflow Hmm, was going to take a shot at debugging your segfault, but I simply can't reproduce this: apt-get source --download-only r-cran-treescape sbuild --arch=i386 -d unstable r-cran-treescape_1.10.18-1.dsc [...] Build Architecture: i386 Build-Space: 11748 Build-Time: 24 Distribution: unstable Host Architecture: i386 Install-Time: 76 Job: .../r-cran-treescape_1.10.18-1.dsc Machine Architecture: amd64 Package: r-cran-treescape Package-Time: 107 Source-Version: 1.10.18-1 Space: 11748 Status: successful Version: 1.10.18-1 sbuild --arch=armhf -d unstable r-cran-treescape_1.10.18-1.dsc [ ... wait a long time due to qemu-user emulation ... ] Build Architecture: armhf Build-Space: 11748 Build-Time: 322 Distribution: unstable Host Architecture: armhf Install-Time: 331 Job: .../r-cran-treescape_1.10.18-1.dsc Machine Architecture: amd64 Package: r-cran-treescape Package-Time: 681 Source-Version: 1.10.18-1 Space: 11748 Status: successful Version: 1.10.18-1 While my machine is amd64, sbuild does set a 32bit personality (so uname -m returns i686) - same as the buildd that failed in your case. The armhf chroot contains the qemu-arm-static binary in /usr/bin for emulation purposes, but is otherwise pristine. (But obviously using emulation is different than a buildd on native hardware.) The resulting packages contain binaries for the respective architectures. I can provide full build logs if you need them. Maybe ask for a give-back at debian-wb-t...@lists.debian.org to have the i386 and armhf buildds try the build again? As far as I can tell the build should succeed... Notable differences between buildd chroot and my freshly created one (in the i386 case): buildd:gcc 6.2.1-5, binutils 2.27.51.20161201-1 my system: gcc 6.2.1-6, binutils 2.27.51.20161212-1 Maybe this was a toolchain bug that was fixed recently? If so, maybe wait a couple of days (buildd chroots are updated twice a week IIRC) and then ask for a give-back. Regards, Christian
Re: Help: r-cran-treescape does not build on i386, armel and armhf any more
On Tue, 13 Dec 2016 13:23:50 +0100, Andreas Tille wrote: > > I guess pabs meant that you're not actually using it in debian/rules. > Urgs, thanks for opening my eyes. ;-) :) > Index: rules > === > --- rules (Revision 23284) > +++ rules (Arbeitskopie) > @@ -2,3 +2,7 @@ > > %: > dh $@ --buildsystem R > + > +override_dh_auto_install: > + xvfb-run --auto-servernum --server-num=20 -s "-screen 0 1024x768x24 > -ac +extension GLX +render -noreset" \ > + dh_auto_install > > > which results in the following diff in the build log: > > > ** preparing package for lazy loading > Creating a generic function for 'toJSON' from package 'jsonlite' in package > 'googleVis' > Warning in rgl.init(initValue, onlyNULL) : > - RGL: unable to open X11 display > + RGL: GLX extension missing on server > Warning: 'rgl_init' failed, running with rgl.useNULL = TRUE > ** help > *** installing help indices Adding libgl1-mesa-dri as a build dependency gets rid of the warning for me (amd64 cowbuilder sid chroot). ** preparing package for lazy loading Creating a generic function for 'toJSON' from package 'jsonlite' in package 'googleVis' ** help *** installing help indices Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: David Bowie: China Girl (Single Version) signature.asc Description: Digital Signature
Re: Help: r-cran-treescape does not build on i386, armel and armhf any more
On Tue, 13 Dec 2016 08:47:37 +0100, Andreas Tille wrote: > So I did not yet considered this last resort and hope for some help from > people who are more confident with gdb debugging than I am (Ive read > here frequently some phrases like "10 minutes of gdb debugging" but I'm > afraid it would take me 10 hours - I'd happily join a "Gdb for Debian > maintainers" workshop at Debconf, thought. This reminds me of my remark in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847397#25 from last Friday :) Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Tracy Chapman: Across the Lines signature.asc Description: Digital Signature
Re: Help: r-cran-treescape does not build on i386, armel and armhf any more
On Tue, Dec 13, 2016 at 11:47:43AM +0100, gregor herrmann wrote: > [..] > > So what exactly do you mean by "didn't add it yet" ? > > I guess pabs meant that you're not actually using it in debian/rules. Urgs, thanks for opening my eyes. ;-) So I tried: Index: rules === --- rules (Revision 23284) +++ rules (Arbeitskopie) @@ -2,3 +2,7 @@ %: dh $@ --buildsystem R + +override_dh_auto_install: + xvfb-run --auto-servernum --server-num=20 -s "-screen 0 1024x768x24 -ac +extension GLX +render -noreset" \ + dh_auto_install which results in the following diff in the build log: ** preparing package for lazy loading Creating a generic function for 'toJSON' from package 'jsonlite' in package 'googleVis' Warning in rgl.init(initValue, onlyNULL) : - RGL: unable to open X11 display + RGL: GLX extension missing on server Warning: 'rgl_init' failed, running with rgl.useNULL = TRUE ** help *** installing help indices Seems the "+extension GLX" is not sufficient to get it fully working. Do you have any better idea. Since I do not have one for the moment I'd like to fix this first and try what happens on the failing architectures (despite I agree with Paul that most probably this is not the cause for the build failure since it only results in a warning). Kind regards Andreas. -- http://fam-tille.de
Re: Help: r-cran-treescape does not build on i386, armel and armhf any more
On Tue, 13 Dec 2016 11:30:41 +0100, Andreas Tille wrote: > > > Well, adding xvfb was the usual trick to cope with "unable to open X11 > > > display" messages and thus I added it ... > > To me it looks like you didn't add it yet, at least not to the version > > in Debian. > Hmmm, > $ apt-get source r-cran-treescape > $ grep xvfb r-cran-treescape-1.10.18/debian/control >xvfb [..] > So what exactly do you mean by "didn't add it yet" ? I guess pabs meant that you're not actually using it in debian/rules. Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- BOFH excuse #9: doppler effect
Re: Help: r-cran-treescape does not build on i386, armel and armhf any more
On Tue, Dec 13, 2016 at 03:50:32PM +0800, Paul Wise wrote: > On Tue, Dec 13, 2016 at 3:47 PM, Andreas Tille wrote: > > > Well, adding xvfb was the usual trick to cope with "unable to open X11 > > display" messages and thus I added it ... > > To me it looks like you didn't add it yet, at least not to the version > in Debian. Hmmm, $ apt-get source r-cran-treescape $ grep xvfb r-cran-treescape-1.10.18/debian/control xvfb May be I should do some source only upload but at least arm64 log[1] contains Get:298 http://ftp.us.debian.org/debian unstable/main arm64 xvfb arm64 2:1.19.0-2 [2656 kB] So what exactly do you mean by "didn't add it yet" ? Kind regards Andreas. [1] https://buildd.debian.org/status/fetch.php?pkg=r-cran-treescape&arch=arm64&ver=1.10.18-1&stamp=1481535210 -- http://fam-tille.de
Re: Help: r-cran-treescape does not build on i386, armel and armhf any more
On Tue, Dec 13, 2016 at 3:47 PM, Andreas Tille wrote: > Well, adding xvfb was the usual trick to cope with "unable to open X11 > display" messages and thus I added it ... To me it looks like you didn't add it yet, at least not to the version in Debian. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Help: r-cran-treescape does not build on i386, armel and armhf any more
Hi Paul, On Tue, Dec 13, 2016 at 09:07:11AM +0800, Paul Wise wrote: > > Any help would be really appreciated. > > Looking at the build logs, even the architectures that succeeded are > getting the warning about X11. So that is completely unrelated and the > issue is the segfault not the xvfb stuff. Someone need to run the > crashing program under gdb and debug the crash. > > https://buildd.debian.org/status/fetch.php?pkg=r-cran-treescape&arch=arm64&ver=1.10.18-1&stamp=1481535210 Ahhh, you are right. > If you can't find someone to help out, the only option to solve the RC > bug is removal from those architectures: > > https://wiki.debian.org/ftpmaster_Removals While amd64 is most probably the main target architecture it would be a shame to loose i386 and there might be some hidden problem which in the end also affects amd64. So I did not yet considered this last resort and hope for some help from people who are more confident with gdb debugging than I am (Ive read here frequently some phrases like "10 minutes of gdb debugging" but I'm afraid it would take me 10 hours - I'd happily join a "Gdb for Debian maintainers" workshop at Debconf, thought. > Also, you build-depend on xvfb but I can't see it being used at all in > the build log nor the packaging: > > https://codesearch.debian.net/search?q=package%3Ar-cran-treescape+xvfb Well, adding xvfb was the usual trick to cope with "unable to open X11 display" messages and thus I added it ... Kind regards Andreas. -- http://fam-tille.de
Re: Help: r-cran-treescape does not build on i386, armel and armhf any more
On Mon, Dec 12, 2016 at 5:46 PM, Andreas Tille wrote: > I admit I do not only lack the hardware I'm also lacking experience to > track down this kind of problems. I discussed the issue with upstream > and they also do not have any clue. > > Any help would be really appreciated. Looking at the build logs, even the architectures that succeeded are getting the warning about X11. So that is completely unrelated and the issue is the segfault not the xvfb stuff. Someone need to run the crashing program under gdb and debug the crash. https://buildd.debian.org/status/fetch.php?pkg=r-cran-treescape&arch=arm64&ver=1.10.18-1&stamp=1481535210 If you can't find someone to help out, the only option to solve the RC bug is removal from those architectures: https://wiki.debian.org/ftpmaster_Removals Also, you build-depend on xvfb but I can't see it being used at all in the build log nor the packaging: https://codesearch.debian.net/search?q=package%3Ar-cran-treescape+xvfb -- bye, pabs https://wiki.debian.org/PaulWise
Re: Help: r-cran-treescape does not build on i386, armel and armhf any more
Hi Paul, On Thu, Nov 03, 2016 at 11:40:04AM +0800, Paul Wise wrote: > On Thu, Nov 3, 2016 at 12:20 AM, Andreas Tille wrote: > > > I used xauth and xvfb as Build-Depends successfully which works on most > > architectures - but failed on these ones. Any hint how to solve this? > > If you don't have hardware for these arches, login to one of the > porterboxen and install the build-deps in a chroot and then run the > relevant commands under a debugger like gdb. > > https://dsa.debian.org/doc/schroot/ > https://db.debian.org/machines.cgi I admit I do not only lack the hardware I'm also lacking experience to track down this kind of problems. I discussed the issue with upstream and they also do not have any clue. Any help would be really appreciated. Kind regards Andreas. -- http://fam-tille.de
Re: Help: r-cran-treescape does not build on i386, armel and armhf any more
On Thu, Nov 3, 2016 at 12:20 AM, Andreas Tille wrote: > I used xauth and xvfb as Build-Depends successfully which works on most > architectures - but failed on these ones. Any hint how to solve this? If you don't have hardware for these arches, login to one of the porterboxen and install the build-deps in a chroot and then run the relevant commands under a debugger like gdb. https://dsa.debian.org/doc/schroot/ https://db.debian.org/machines.cgi -- bye, pabs https://wiki.debian.org/PaulWise
Help: r-cran-treescape does not build on i386, armel and armhf any more
Hi, the build logs[1] of these thre architeture says: ... Warning in rgl.init(initValue, onlyNULL) : RGL: unable to open X11 display Warning: 'rgl_init' failed, running with rgl.useNULL = TRUE Error: segfault from C stack overflow ... I used xauth and xvfb as Build-Depends successfully which works on most architectures - but failed on these ones. Any hint how to solve this? Kind regards Andreas. [1] https://buildd.debian.org/status/package.php?p=r-cran-treescape -- http://fam-tille.de
