similar to: R 4.0.0 build error with sysdata.rda on ppc64el architecture

Hum, at least it is not Apple, so maybe you can attach a debugger to the running process? (gdb -p process_id or something like that --- haven't actually done it for a decade). Then at least we can get a stack trace and a clue about where it is looping. Diddling optimization options can also sometimes provide a clue. -pd > On 29 Apr 2020, at 01:17 , Dirk Eddelbuettel <edd at

On 30 April 2020 at 09:11, luke-tierney at uiowa.edu wrote: | On Thu, 30 Apr 2020, Dirk Eddelbuettel wrote: | Maybe I missed something. How is the 'compiler' package involved? See the other email thread; you replied (~ 26 hours ago) to my message adding that "sysdata.rda in 'tools' hanging was wrong". It gets to the next stage, which is 'compiler'. We know by

On 30 April 2020 at 09:42, I?aki Ucar wrote: | On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <edd at debian.org> wrote: | > And to keep the list abreast, this appears to be related to the long double | > issue on powerpc where needed an extra #define to ensure compilation. That [...] | Which reminds me that [1] was required for v3.6.2. Could be related? Yes, that is what I refered

On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <edd at debian.org> wrote: > > > On 29 April 2020 at 11:22, peter dalgaard wrote: > | Hum, at least it is not Apple, so maybe you can attach a debugger to the running process? (gdb -p process_id or something like that --- haven't actually done it for a decade). Then at least we can get a stack trace and a clue about where it is

On Thu, 30 Apr 2020, Dirk Eddelbuettel wrote: > > On 30 April 2020 at 09:42, I?aki Ucar wrote: > | On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <edd at debian.org> wrote: > | > And to keep the list abreast, this appears to be related to the long double > | > issue on powerpc where needed an extra #define to ensure compilation. That > [...] > | Which reminds me

On 29 April 2020 at 11:22, peter dalgaard wrote: | Hum, at least it is not Apple, so maybe you can attach a debugger to the running process? (gdb -p process_id or something like that --- haven't actually done it for a decade). Then at least we can get a stack trace and a clue about where it is looping. Diddling optimization options can also sometimes provide a clue. (Missed this earlier as

Hi, I have been trying to catch up my Debian packages to the current 1.27 branch of libguestfs (and uploaded those packages to experimental), but apparently the build was broken for architectures where no native OCaml compiler is available because make wanted to build .cmx files -- see <https://buildd.debian.org/status/package.php?p=libguestfs&suite=experimental>. So far mips[1],

https://bugzilla.mindrot.org/show_bug.cgi?id=3645 Bug ID: 3645 Summary: -fzero-call-used-regs=used detection seems to fail on Linux ppc64el Product: Portable OpenSSH Version: 9.6p1 Hardware: PPC64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: Build

Hi, On Fri, May 23, 2014 at 10:57:31AM -0300, Mauricio Faria de Oliveira wrote: > > The ppc64el port needs klibc's static binaries, like ppc64. This segfaulting is a bug in klibc that needs investigation. > This patch enables the ARCH=ppc64 make env var in debian/rules, in order > for 'debian/patches/ppc64-static.patch' to take effect on ppp64el too. I have no problem

--- src/kernel.ml | 2 ++ src/utils.ml | 2 ++ 2 files changed, 4 insertions(+) diff --git a/src/kernel.ml b/src/kernel.ml index 356ac4b..9b0e8a2 100644 --- a/src/kernel.ml +++ b/src/kernel.ml @@ -30,6 +30,8 @@ let patt_of_cpu host_cpu = | "ppc" | "powerpc" | "powerpc64" -> ["ppc"; "powerpc"; "powerpc64"] |

Hi, peter green wrote: > On 18/05/16 04:50, Tim Northover wrote: > If you don't need/want the various Sanitizer runtimes (e.g. you don't > support sanitizers or already have versions provided with GCC) then > it's as easy as not downloading compiler-rt or removing it from the > projects/ directory before running CMake. The build should carry on > quite happily

Package: src:xen Version: 4.8.1~pre.2017.01.23-1 Severity: normal Tags: sid buster User: debian-gcc at lists.debian.org Usertags: ftbfs-gcc-7 Please keep this issue open in the bug tracker for the package it was filed for. If a fix in another package is required, please file a bug for the other package (or clone), and add a block in this package. Please keep the issue open until the package can

Hi maks, Adding Anton in CC (who submitted klibc ppc64le support upstream [1]), in case he can help. >> The ppc64el port needs klibc's static binaries, like ppc64. > > This segfaulting is a bug in klibc that needs investigation. > >> This patch enables the ARCH=ppc64 make env var in debian/rules, in order >> for 'debian/patches/ppc64-static.patch' to take

Dear developeRs, my package FrF2.catlg128 holds large catalogues and is supposed to gain additional ones. All the catalogues are intended for the user. So far, the catalogues were stored in the data directory, and LazyData was "no". I understand that this is not considered wise any more (if it ever was), so that I want to change to LazyData "yes" with the next release

Hi all, I'm struggling with accessing a package dataset (munsell.map, stored in sysdata.rda) when that package is imported, not required. A simple reproducible example is: install.packages("munsell") munsell::mnsl("10B 4/6") # Error in match(col, munsell.map$name) : object 'munsell.map' not found library(munsell) munsell::mnsl("10B 4/6") # Function

Hi, to speed up computations in our RobASt family of packages, we use interpolation on a grid of precomputed values which we save together with the interpolating functions (results of splinefun essentially) in sysdata.rda in the R folder of our pkg. After adding grids for some more models, this file has grown considerably, even after application of tools::resaveRdaFiles. At the moment we are at

Package: xen Version: 4.6.0-1+nmu2 Severity: serious This package fails to build in unstable: > sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on dl580gen9-02.hlinux ... > mkdir -p compat > grep -v 'DEFINE_XEN_GUEST_HANDLE(long)' public/grant_table.h | \ > python /<<PKGBUILDDIR>>/debian/build/build-hypervisor_amd64_amd64/xen/tools/compat-build-source.py

Can you provide a complete reproducible example? Sent from my iPhone > On May 1, 2016, at 6:51 AM, Peter Ruckdeschel <peter.ruckdeschel at web.de> wrote: > > Hi r-devels, > > we are seeing a new problem with our packages RobAStRDA (just new on CRAN, thanks > to Uwe and Kurt!) and RobExtremes (to be submitted). > > It must be something recent with the way you

Hi, I am getting a strange error with 15.0 which I've not seen with previous versions of R. If sysdata.rda is included in R directory of the package I am getting: R CMD build betfairly.roxygen/ * checking for file ?betfairly.roxygen/DESCRIPTION? ... OK * preparing ?betfairly?: * checking DESCRIPTION meta-information ... OK * excluding invalid files Subdirectory 'R' contains invalid

As you may know, I look after the R package for Debian. My fellow Debianers make me follow a specific protocol -- a so-called "transition" in which all dependent packages on an identified potential breakge are rebuilt under the new (potentially breaking) change. We started adding an r-api-3.4 tag last (major) release. Now it is r-api-3.5 and the transition got started with the green