Bug#949492: r-cran-xml: FTBFS with libxml2 not shipping xml2-config

On 21 January 2020 at 15:47, Mattia Rizzolo wrote: | Source: r-cran-xml | Version: 3.98-1.20-2 | Severity: important | Tags: ftbfs | User: libx...@packages.debian.org | Usertags: xml2-config | | | Dear maintainer, | | your package is using `xml2-config` to detect and use libxml2. I'm "It

Bug#947001: r-base blocked by r-bioc-{iranges,s4vectors}

On 17 January 2020 at 15:20, Charles Plessy wrote: | fixed 947001 2.20.1-2 | fixed 947004 0.24.2-1 | thanks | | Hello everybody, | | following Gordon's email, I have source-uploaded r-bioc-iranges | 2.20.1-2, which contains a few additional changes that were pending in | the source package's

Bug#947001: [R-pkg-team] Bug#947001: r-base blocked by r-bioc-{iranges, s4vectors}

Just to follow-up here: As upstream for Rcpp, I just ran another reverse dependency check againt 1700+ packages on a machine I get to use for that, and had S4Vectors and IRanges issues pop up for three packages. It looks like an issue with S4Vectors. But still: Three. Out of 1700+. Holding

Bug#947001: [R-pkg-team] Bug#947001: r-base blocked by r-bioc-{iranges, s4vectors}

On 24 December 2019 at 09:34, Graham Inggs wrote: | Control: severity -1 serious | | On Mon, 23 Dec 2019 at 22:30, Dirk Eddelbuettel wrote: | > I would be very surprised if these were not self-inflicted by us. I know CRAN | > (much) better than BioC, but both of them are doing extensiv

Bug#947001: [R-pkg-team] Bug#947001: r-base blocked by r-bioc-{iranges, s4vectors}

On 23 December 2019 at 12:43, Graham Inggs wrote: | On Sun, 22 Dec 2019 at 17:04, Graham Inggs wrote: | > On Sun, 22 Dec 2019 at 16:10, Dirk Eddelbuettel wrote: | > > On the other hand the ppc64 is one of 'blocking compilation' so it can't | > > really segfaults at tests. | >

Bug#947001: r-base blocked by r-bioc-{iranges,s4vectors}

On 22 December 2019 at 16:55, Graham Inggs wrote: | On Sun, 22 Dec 2019 at 16:10, Dirk Eddelbuettel wrote: | > On the other hand the ppc64 is one of 'blocking compilation' so it can't | > really segfaults at tests. | | I don't know what that means, but both the r-bioc-iranges and |

Bug#947001: r-base blocked by r-bioc-{iranges,s4vectors}

On 22 December 2019 at 08:02, Dirk Eddelbuettel wrote: | | On 22 December 2019 at 14:09, Graham Inggs wrote: | | In Ubuntu, r-bioc-iranges and r-bioc-s4vectors autopkgtests failed | | with r-base/3.6.2-1. | | | | However, after the upload of r-base/3.6.2-2, both autopkgtests passed

Bug#947001: r-base blocked by r-bioc-{iranges,s4vectors}

On 22 December 2019 at 14:09, Graham Inggs wrote: | In Ubuntu, r-bioc-iranges and r-bioc-s4vectors autopkgtests failed | with r-base/3.6.2-1. | | However, after the upload of r-base/3.6.2-2, both autopkgtests passed | on ppc64el [1][2]. | | Could this be related to the change for ppc64 [3]?

Bug#946975: Re: Bug#946975: r-cran-rcpp: Won't load: ‘Rcpp’ was installed by an R version with different internals

On 18 December 2019 at 23:51, m...@tuta.io wrote: | i solved the problem. Purging the R packages didn't remove /usr/local/lib/R/site-packages where there was an older version of Rcpp. | I'm not sure how that ended up installed there. It can happen. When you do 'install.packages()' from inside

Bug#946975: r-cran-rcpp: Won't load: ‘Rcpp’ was installed by an R version with different internals

Also, ggplot2 loads just fine: edd@rob:~$ docker run --rm -ti debian:stable root@25c34c0d0488:/# apt-get update 2>&1 >/dev/null root@25c34c0d0488:/# apt-get install -y r-cran-ggplot2 2>&1 >/dev/null debconf: delaying package configuration, since apt-utils is not installed

Bug#946836: Build failure on powerpc architectures

On 16 December 2019 at 22:04, Martin Maechler wrote: | Oops, no! | Tomas the expert has explained me why that would not be good enough, | instead recommending a macro (which would be "constant folded" i.e., | computed at compile time were available); | If I conditionalize that .. in order to be

Bug#946836: Build failure on powerpc architectures

Hi Sebastian, On 16 December 2019 at 13:52, Sebastien Bacher wrote: | Package: r-base | Version: 3.6.2-1 | | The current upload failed to build on powerpc | https://buildd.debian.org/status/fetch.php?pkg=r-base=powerpc=3.6.2-1=1576151048=0 | | gcc -std=gnu99 -I../../src/extra -I.

Bug#946774: dieharder FTCBFS: uses AC_RUN_IFELSE

On 15 December 2019 at 17:43, Helmut Grohne wrote: | Source: dieharder | Version: 3.31.1-8 | Tags: patch upstream | User: debian-cr...@lists.debian.org | Usertags: ftcbfs | | dieharder fails to cross build from source, because its configure script | uses AC_RUN_IFELSE to discover the endianess.

Bug#942867: r-base: does not respect nocheck build profile in DEB_BUILD_OPTIONS

Hi Chris, On 22 October 2019 at 15:46, Chris Lamb wrote: | Source: r-base | Version: 3.6.1-6 | Severity: normal | Tags: patch | | Hi, | | src:r-base does not appear to respect the "nocheck" profile in | DEB_BUILD_OPTIONS. Whilst there appears to be code that intends to do | exactly this, ie.:

Bug#941152: r-doc-html: Format sections are invalid

On 25 September 2019 at 20:14, Davide Prina wrote: | Package: r-doc-html | Version: 3.6.1-5 | Severity: normal | | Dear Maintainer, | | upgrading to the last package version I got the following errors: Yes, I had received a private email about this (or rather the related issue concerning

Bug#939332: ftp.debian.org: RM: PKG -- removal triggered by the Python2 removal

Package: ftp.debian.org Severity: normal Tags: sid bullseye Usertags: py2removal Motivation: Remove r-cran-nws (version 2.0.0.3-4) so that package 'nwsserver' can be removed Contexct: r-cran-nws is

Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest

FWIW both packages are pristinely clean at CRAN with current versions: https://cran.r-project.org/web/checks/check_results_DoseFinding.html https://cloud.r-project.org/web/checks/check_results_multcomp.html These problems still seem self-imposed to me. We (maybe randomly ?) appear to be

Bug#927335: r-base breaks 9 autopkgtests

On 8 August 2019 at 20:38, Paul Gevers wrote: | Hi Graham, Dirk, | | On 08-08-2019 19:17, Graham Inggs wrote: | > I've prepared the attached list of Breaks to be added to the r-base-core | > binary package. | > | > I believe these will ease migration.  Paul, do you concur? | | Adding the

Bug#932972: r-base build-depends on cruft package.

On 25 July 2019 at 11:17, peter green wrote: | Package: r-base | Version: 3.5.2-1 The current package is 3.6.1-2. | Tags: bullseye, sid, patch | Severity: serious | | r-base build-depends on texlive-generic-reccomended which is no longer built by the texlive-base source package. Please

Bug#927335: r-base breaks 9 autopkgtests

On 23 July 2019 at 12:56, Graham Inggs wrote: | Hi Dirk | | On Tue, 23 Jul 2019 at 12:09, Dirk Eddelbuettel wrote: | > Can you expand that last sentence? I do not understand what you are trying to | > say here. What is "main"? What are "buildds"? Why would r-base no

Bug#927335: r-base breaks 9 autopkgtests

On 23 July 2019 at 11:18, Graham Inggs wrote: | Hi All | | I think we're nearing the end of the R 3.6 transition, so I had a | brief look at the remaining autopkgtest regressions. | | r-bioc-biocinstaller/1.32.1-1needs update | r-bioc-graph/1.60.0-11.62-0-1 in unstable |

Bug#931547: r-base: missing dependency on libpcre3-dev

On 7 July 2019 at 15:11, Gianfranco Costamagna wrote: | Source: r-base | Version: 3.6.1-1 | Severity: serious | | Hello, after libselinux has been uploaded in unstable, lots of reverse-dependencies of r-base | will start to FTBFS because of missing libpcre3-dev dependency (that was dragged in

Bug#929940: r-cran-rcmdr: Installation needs to install other packages manually

On 3 June 2019 at 13:21, Dirk Eddelbuettel wrote: | | On 3 June 2019 at 19:21, jpg wrote: | | Package: r-cran-rcmdr | | Version: 2.5-1-1 | | Severity: normal | | | | Dear Maintainer, | | | | I have already R and several packages installed. | | | | When I installed r-cran-rcmdr and loaded

Bug#928653: r-base: change R_LIBS_USER default location

On 8 May 2019 at 13:30, Matsievskiy S.V. wrote: | Source: r-base | Version: 3.6.0-1 | Severity: minor | | Dear Maintainer, | | By default R_LIBS_USER is set to $HOME/R. I think that it would be better to | conform with XDG Base Directory Specification |

Bug#927335: r-base breaks 9 autopkgtests

On 18 April 2019 at 13:27, Paul Gevers wrote: | That check is for a version of r-cran-permute not yet in Debian, for A bug in r-cran-permute. In Google-speak, 'CRAN lives at HEAD'. The top of its release repo (ie the CRAN mirrors) is what we would call a release and guaranteed to work across

Bug#927335: r-base breaks 9 autopkgtests

On 18 April 2019 at 09:28, Paul Gevers wrote: | Source: r-base | Severity: important | User: debian...@lists.debian.org | Usertags: breaks | Control: affects -1 r-cran-permute | Control: affects -1 r-cran-phangorn | Control: affects -1 r-cran-popepi | Control: affects -1 r-cran-recipes |

Bug#926568: gsl-doc: does this package need to be updated to match gsl 2.5?

severity 926568 wishlist thanks On 7 April 2019 at 06:23, Andreas Beckmann wrote: | Source: gsl-doc | Version: 2.3-1 | Severity: serious | | Hi, | | src:gsl is at version 2.5 while src:gsl-doc is at version 2.3. | Does the documentation need to be updated to match the library? | | Please

Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest

reassign 924514 r-cran-dosefinding thanks The relationship between 'multcomp' and 'DoseFinding' is, as seen on the upstream package for 'DoseFinding' at http://cloud.r-project.org/package=DoseFinding in its DESCRIPTION file: Suggests: numDeriv, Rsolnp, quadprog, parallel, multcomp so

Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest

On 15 March 2019 at 07:49, Andreas Tille wrote: | On Thu, Mar 14, 2019 at 06:27:35AM -0500, Dirk Eddelbuettel wrote: | > | > | > No issue at CRAN for multcomp: | > | > | > | >https://cloud.r-project.org/web/checks/check_results_multcomp.html | > | > | &

Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest

, | | On Wed, Mar 13, 2019 at 03:58:14PM -0500, Dirk Eddelbuettel wrote: | > | > On 13 March 2019 at 21:39, Paul Gevers wrote: | > | Source: multcomp, r-cran-dosefinding | > | Control: found -1 multcomp/1.4-10-1 | > | Control: found -1 r-cran-dosefinding/0.9-16-2 | > | Severity:

Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest

On 13 March 2019 at 21:39, Paul Gevers wrote: | Source: multcomp, r-cran-dosefinding | Control: found -1 multcomp/1.4-10-1 | Control: found -1 r-cran-dosefinding/0.9-16-2 | Severity: important | X-Debbugs-CC: debian...@lists.debian.org | User: debian...@lists.debian.org | Usertags: breaks

Bug#923043: ITP: r-cran-ellipsis -- GNU R package for working with ...

Package: wnpp Owner: Dirk Eddelbuettel Severity: wishlist * Package name: r-cran-ellipsis Version : 0.1.0 Upstream Author : Hadley Wickham * URL or Web page : https://cran.r-project.org/package=ellipsis * License : GPL-3 Description : GNU R package for working

Bug#919324: CVE-2018-20450 CVE-2018-20452

On 11 February 2019 at 15:12, Evan Miller wrote: | An official release of libxls 1.5.0 is here: | | https://github.com/libxls/libxls/releases/tag/v1.5.0 | | It fixes all known vulnerabilities. Thanks for your patience everyone. And Jenny

Bug#922198: lme4 breaks r-cran-lmertest and r-cran-mlmrev

On 13 February 2019 at 16:43, Graham Inggs wrote: | Hi Dirk | | On 2019/02/13 13:51, Dirk Eddelbuettel wrote: | > Ok -- done in 1.1-20-2 which I just uploaded. Thanks for the suggestion! | | Thanks for the quick fix! | | Unluckily, you put the Breaks in the Source: lme4 section of | deb

Bug#922198: lme4 breaks r-cran-lmertest and r-cran-mlmrev

On 13 February 2019 at 08:56, Graham Inggs wrote: | Control: tags -1 = patch | Control: notforwarded -1 | Control: reassign 921938 r-cran-lmertest 3.0-1-2 | | Hi Dirk | | On Wed, 13 Feb 2019 at 01:15, Dirk Eddelbuettel wrote: | > By now both these packages have been updated | >

Bug#921938: lme4 breaks r-cran-lmertest autopkgtest

Paul, It so happens that I know the R stack pretty well, and I happen to know how CRAN operates. Getting a new upstream package from CRAN almost always means that nothing is broken, or that (a rare case) a change affects a downstream package -- as all this is tested well at CRAN. I am pretty

Bug#921938: lme4 breaks r-cran-lmertest autopkgtest

On 10 February 2019 at 08:20, Dirk Eddelbuettel wrote: | | On 10 February 2019 at 13:35, Paul Gevers wrote: | | Source: lme4, r-cran-lmertest | | Control: found -1 lme4/1.1-20-1 | | Control: found -1 r-cran-lmertest/3.0-1-2 | | Severity: important | | X-Debbugs-CC: debian...@lists.debian.org

Bug#921938: lme4 breaks r-cran-lmertest autopkgtest

On 10 February 2019 at 13:35, Paul Gevers wrote: | Source: lme4, r-cran-lmertest | Control: found -1 lme4/1.1-20-1 | Control: found -1 r-cran-lmertest/3.0-1-2 | Severity: important | X-Debbugs-CC: debian...@lists.debian.org | User: debian...@lists.debian.org | Usertags: breaks needs-update | |

Bug#919324: CVE-2018-20450 CVE-2018-20452

And as one more piece of closure, the backported fix is now going into an update of Debian stable as well. Thanks everybody, and especially Evan. We're already in better shape now, and will be in even better shape with the upcoming libxls 1.5 release. Dirk -- http://dirk.eddelbuettel.com |

Bug#920804: release.debian.org: security upload for r-cran-readxl

On 30 January 2019 at 13:59, Adam D. Barratt wrote: | On 2019-01-30 13:39, Dirk Eddelbuettel wrote: | > On 30 January 2019 at 13:11, Adam D. Barratt wrote: | > | On 2019-01-29 11:53, Dirk Eddelbuettel wrote: | > ... | > | > Happy to upload once you give a green light. (Sys

Bug#920804: release.debian.org: security upload for r-cran-readxl

On 30 January 2019 at 13:11, Adam D. Barratt wrote: | On 2019-01-29 11:53, Dirk Eddelbuettel wrote: | > This is a follow-up to the discussion in #919324 and subsequent emails | > with | > Moritz and Salvatore. The two CVEs are genuine and fixed, the issue | > however | > is

Bug#920804: release.debian.org: security upload for r-cran-readxl

: #919324) + * libxls/xlstool.h: Idem + * ole.c: Idem + * xls.c: Idem + * xlstool.c: Idem + + * This addresses +CVE-2018-20450 +CVE-2018-20452 +with corresponding upstream patch in libxls and readxl + + -- Dirk Eddelbuettel Sun, 27 Jan 2019 09:29:50 -0600 + r-cran-readxl (0.1.1-1

Bug#919324: CVE-2018-20450 CVE-2018-20452

On 27 January 2019 at 09:25, Evan Miller wrote: | | > On Jan 26, 2019, at 23:09, Dirk Eddelbuettel wrote: | > | > | > On 26 January 2019 at 15:59, Jennifer Bryan wrote: | > | I'll still wait a bit to see if libxls can get to an official release soon. | > | | >

Bug#919324: CVE-2018-20450 CVE-2018-20452

fold that into an interim release to address the CVE? I can then follow-up with real release whenever you push to CRAN. Dirk | -- Jenny | | On Sat, Jan 26, 2019 at 7:23 AM Evan Miller wrote: | | > | > > On Jan 26, 2019, at 10:05, Dirk Eddelbuettel wrote: | > > | > > | &

Bug#919324: CVE-2018-20450 CVE-2018-20452

On 24 January 2019 at 19:54, Evan Miller wrote: | | > On Jan 24, 2019, at 19:10, Dirk Eddelbuettel wrote: | > | > | > On 24 January 2019 at 16:36, Evan Miller wrote: | > | | > | > On Jan 23, 2019, at 01:16, Evan Miller wrote: | > | > | > | > #34 an

Bug#919324: CVE-2018-20450 CVE-2018-20452

; On Tue, Jan 15, 2019 at 10:43:25AM -0600, Dirk Eddelbuettel wrote: | >>> | >>> Hi Evan, | >>> | >>> On 15 January 2019 at 11:18, Evan Miller wrote: | >>> | | >>> | > On Jan 15, 2019, at 03:06, Moritz Muehlenhoff mailto:j...@i

Bug#919324: CVE-2018-20450 CVE-2018-20452

Hi Evan, On 15 January 2019 at 11:18, Evan Miller wrote: | | > On Jan 15, 2019, at 03:06, Moritz Muehlenhoff wrote: | > | > On Mon, Jan 14, 2019 at 08:45:56PM -0500, Evan Miller wrote: | >> Oddly, all four issues (#34, #35, #36, #37) seem to have disappeared from GitHub. I don’t know if the

Bug#919324: CVE-2018-20450 CVE-2018-20452

. So without the cooperation of the reporter (Zhao Liang, Huawei Weiran Labs) my ability to research will be limited. Understood. Moritz: Any idea? Will the CVE end of things have copies? Dirk | Evan | | > On Jan 14, 2019, at 19:22, Dirk Eddelbuettel wrote: | > | > |

Bug#919324: CVE-2018-20450 CVE-2018-20452

ease keep us posted and abreast of any progress. Dirk | Evan | | > On Jan 14, 2019, at 17:56, Dirk Eddelbuettel wrote: | > | > | > Hi Evan, | > | > On 14 January 2019 at 23:32, Moritz Muehlenhoff wrote: | > | Package: r-cran-readxl | > | Severity: important | >

Bug#918525: r-base-core: library lapack.so shouldn't be linked to libopenblas.so.0

On 7 January 2019 at 12:29, Sébastien Villemot wrote: | Dear Dirk and Jörg-Volker, | | On Mon, 7 Jan 2019 08:54:22 +0100 Jörg-Volker Peetz wrote: | | > the problem I see, shows when inspecting /usr/lib/R/modules/lapack.so with | >  | > $ ldd /usr/lib/R/modules/lapack.so | grep blas | > 

Bug#918525: r-base-core: library lapack.so shouldn't be linked to libopenblas.so.0

Hallo Jörg-Volker, On 7 January 2019 at 00:09, Jörg-Volker Peetz wrote: | Package: r-base-core | Version: 3.5.2-1 | Severity: important | | Hi Dirk, | | the library /usr/lib/R/modules/lapack.so contained in this package is | linked to /usr/lib/x86_64-linux-gnu/libopenblas.so.0 of the package

Bug#917246: r-base suggests deprecated pacakge ess

On 24 December 2018 at 12:11, Boruch Baum wrote: | Package: r-base | Version: 3.5.2-1 | Severity: trivial | | Dear Maintainer, | | The package "suggests" package ess; however, that package has been | deprecated in favor of package elpa-ess. Excellent catch. I have updated that to elpa-ess in

Bug#916773: r-base: CRAN packages fail to install.

Emmanuel, We have not found anything genuinely reproducible. With that there is little we can do here. I don't doubt that you had an issue. It's just that sometimes repompilation _is_ necessary. Best, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#916773: Yet one more datapoint

On 19 December 2018 at 11:11, Emmanuel Charpentier wrote: | It seems that the package httpuv has the same problem as brms... C++. You may have had a change of C++ compiler, or a C/C++ library change, or ... Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#916773: One more datapoint.

On 19 December 2018 at 11:01, Emmanuel Charpentier wrote: | | On a 3.5.1 installation not yet updated, brms has three dependencies, | none of them having themselves dependencies : | | > installed.packages()["brms","Depends"] | [1] "R (>= 3.2.0), Rcpp (>= 0.12.0), ggplot2 (>= 2.0.0), methods" |

Bug#916773: r-base: CRAN packages fail to install.

(Removed Kurt now, no need to fill his inbox; this will get archived at the Debian BTS.) On 19 December 2018 at 08:22, Emmanuel Charpentier wrote: | Dear Dirk, | | the brute-force appears to be effective for R 3.5.1. | | Le mardi 18 décembre 2018 à 15:37 -0600, Dirk Eddelbuettel a écrit

Bug#916773: r-base: CRAN packages fail to install.

On 18 December 2018 at 22:13, Emmanuel Charpentier wrote: | Dear Dirk, | | Le mardi 18 décembre 2018 à 12:00 -0600, Dirk Eddelbuettel a écrit : | > Emmanuel, | > | > I ran this by Kurt Hornik (CC'ed) who is a Debian user too and one | > who | > updates frequently. He has hit th

Bug#916773: r-base: CRAN packages fail to install.

Emmanuel, I ran this by Kurt Hornik (CC'ed) who is a Debian user too and one who updates frequently. He has hit the issue as well as says that it seems to stem from rstan and that updating "everything" seems to fix it, just as I suggested to you as "qualified guess". We have no idea yet whose

Bug#916773: r-base: CRAN packages fail to install.

On 18 December 2018 at 15:17, Emmanuel Charpentier wrote: | Le mardi 18 décembre 2018 à 07:34 -0600, Dirk Eddelbuettel a écrit : | > On 18 December 2018 at 14:21, Emmanuel Charpentier wrote: | > > Package: r-base | > > Version: 3.5.1.20181215-1 | > > Severity: importa

Bug#916773: r-base: CRAN packages fail to install.

On 18 December 2018 at 14:21, Emmanuel Charpentier wrote: | Package: r-base | Version: 3.5.1.20181215-1 | Severity: important | | Dear Maintainer, | | Please note that I report this bug against r-base because this is where I got | the symptoms. However, I am almost certain that the problem is

Bug#913539: typo in gsl-randist(1)

On 12 November 2018 at 10:19, Dirk Eddelbuettel wrote: | | On 12 November 2018 at 01:40, Barak A. Pearlmutter wrote: | | Package: gsl-bin | | Version: 2.5+dfsg-5 | | | | Thanks for maintaining gsl; I use it all the time. | | My pleasure, and "anytime" -- I get a lot of use o

Bug#912341: libgsl23: operator delete clash when using gsl_filter.h

On 30 October 2018 at 19:47, Dirk Eddelbuettel wrote: | | Hi, | | On 31 October 2018 at 00:15, D Haley wrote: | | Hi, | | | | I've attached a patch that might suit - | | Thanks for that. | | | however I am a bit unsure about modifying a non-leaf package, such as GSL. | | &quo

Bug#914633: r-cran-readr breaks autopkgtests: librcon.so can't be found

Ok -- I just put a pretty rough "cowboy" patch in which - alters src/Makevars to not require the extra shared library - moves the dozen of so lines of actual C code from src/rcon/ into a file in src/ to have in the same C library See

Bug#914633: r-cran-readr breaks autopkgtests: librcon.so can't be found

On 25 November 2018 at 21:59, Paul Gevers wrote: | Hi Dirk, | | On 25-11-18 21:42, Dirk Eddelbuettel wrote: | > The new version of readr relies on rpath to encode a path. We are caught | > between a rock and hard place: as shipped (and built my yesterday), the | > package "bu

Bug#576914: Need help dealing with this l10n bug?

On 25 November 2018 at 18:19, Helge Kreutzmann wrote: | Hello Dirk, | On Sun, Nov 25, 2018 at 10:56:16AM -0600, Dirk Eddelbuettel wrote: | > On 25 November 2018 at 17:30, Helge Kreutzmann wrote: | > | Hello Dirk, | > | this German l10n bug is open for more than 8 years. Do you

Bug#911957: [src:rquantlib] FTBFS with boost1.67

On 28 October 2018 at 09:31, Dirk Eddelbuettel wrote: | | On 26 October 2018 at 17:13, Giovanni Mascellani wrote: | | Package: src:rquantlib | | Version: 0.4.5-1 | | Severity: wishlist | | Tags: patch | | User: team+bo...@tracker.debian.org | | Usertags: boost1.67 | | | | Dear Maintainer

Bug#576914: Need help dealing with this l10n bug?

On 25 November 2018 at 17:30, Helge Kreutzmann wrote: | Hello Dirk, | this German l10n bug is open for more than 8 years. Do you need help | dealing with it? I could provide a NMU, but of course a maintainer | upload is (much) preferred. In R land, it is _much_ preferred to give this to the

Bug#913982: r-base-core: R executable wrapper scripts hard-code the wrong path to sed.

Further and finer analysis by Kurt Hornik of the upstream R Core team suggests that only the 3.5.1-1+b2 seems to be affected. Re-reading I see that Pavel already said so -- my apologies for missing that the first time around. I think I'll just build and ship a fresh 3.5.1-2 which should take

Bug#913982: r-base-core: R executable wrapper scripts hard-code the wrong path to sed.

John, On 18 November 2018 at 09:51, John Scott wrote: | Package: r-base-core | Version: 3.5.1-1+b2 | Followup-For: Bug #913982 | | -BEGIN PGP SIGNED MESSAGE- | Hash: SHA512 | | > Not here (using the r-base Docker container I maintain which uses Debian testing) | | I've installed

Bug#913982: r-base-core: R executable wrapper scripts hard-code the wrong path to sed.

Hi Pavel, On 18 November 2018 at 21:30, Pavel N. Krivitsky wrote: | Hi, Dirk, | | Thanks for looking into this. It all makes sense, until this: | | > root@03c3abf866d1:/# which sed | > /usr/bin/sed | | As far as I can tell, the sed Debian package (all versions) puts the | executable in /bin/

Bug#913982: r-base-core: R executable wrapper scripts hard-code the wrong path to sed.

severity 913982 wishlist thanks Hi Pavel, Thanks for taking the time to write this up. On 18 November 2018 at 11:15, Pavel N. Krivitsky wrote: | Package: r-base-core | Version: 3.5.1-1+b2 | Severity: important | | Dear Maintainer, | | # To reproduce: | | Attempt to execute on the command

Bug#913539: typo in gsl-randist(1)

On 12 November 2018 at 01:40, Barak A. Pearlmutter wrote: | Package: gsl-bin | Version: 2.5+dfsg-5 | | Thanks for maintaining gsl; I use it all the time. My pleasure, and "anytime" -- I get a lot of use out of your packaging too :) | The gsl-randist(1) page suggest the sample command | |

Bug#913321: r-cran-zip: please fix short description

On 9 November 2018 at 15:52, s3v wrote: | Package: src:r-cran-zip | Severity: minor | | Dear maintainer, | | I was wondering if you could please fix the short description for | r-cran-zip package: | | GNU R package to read and write XLSX files | | This description is the same as

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

(You forgot to CC the Debian bug address. Added it back in.) On 3 November 2018 at 00:24, Marcelo Laia wrote: | On 02/11/18 at 09:00, Dirk Eddelbuettel wrote: | > Hi Marcelo, | > | ess-version: 17.11 [] (loaded from /usr/share/emacs/site-lisp/) | > | > Then you have two differ

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

Hi Marcelo, On 2 November 2018 at 22:02, Marcelo Laia wrote: | Hi! | | I would like to contribute. | | dpkg -l elpa-ess | | ii elpa-ess 18.10-1-2all Emacs mode for statistical programm | | M-x ess-version on emacs show me: | | ess-version: 17.11 [] (loaded from

Bug#912341: libgsl23: operator delete clash when using gsl_filter.h

Hi, On 31 October 2018 at 00:15, D Haley wrote: | Hi, | | I've attached a patch that might suit - Thanks for that. | however I am a bit unsure about modifying a non-leaf package, such as GSL. "Yes but" this is new-ish functionality in 2.5 only. So few depends on this. I'd say if 'make;

Bug#912341: libgsl23: operator delete clash when using gsl_filter.h

Guess we had overlapping emails there. On 30 October 2018 at 18:51, D Haley wrote: | Hi, | | Thanks for the very quick response. | | On my system, it is gsl/gsl_filter.h, rather than Sorry -- I confused myself between an older installation, my sources, and then Debian testing/unstable. My

Bug#912341: libgsl23: operator delete clash when using gsl_filter.h

I am a little hesitant to cook up a patch especially as I am not using the code. But if you wrote and tested on I could entertain applying such a patch until upstream catches. It may touch quite a few files, so some patience and dedication would be needed. Dirk edd@rob:~/deb/gsl(master)$ ag

Bug#912341: libgsl23: operator delete clash when using gsl_filter.h

On 30 October 2018 at 15:47, D Haley wrote: | Package: libgsl23 | Version: 2.5+dfsg-5 | Severity: normal | | Dear Maintainer, | | The following program will not compile when using a c++ compiler: | | #include You meant #include | int main() | { | } | | This gives the following

Bug#911957: [src:rquantlib] FTBFS with boost1.67

On 26 October 2018 at 17:13, Giovanni Mascellani wrote: | Package: src:rquantlib | Version: 0.4.5-1 | Severity: wishlist | Tags: patch | User: team+bo...@tracker.debian.org | Usertags: boost1.67 | | Dear Maintainer, | | your package fails to build with boost1.67. You can find a build log |

Bug#911957: [src:rquantlib] FTBFS with boost1.67

Giovanni, On 26 October 2018 at 17:13, Giovanni Mascellani wrote: | Package: src:rquantlib | Version: 0.4.5-1 | Severity: wishlist | Tags: patch | User: team+bo...@tracker.debian.org | Usertags: boost1.67 | | Dear Maintainer, | | your package fails to build with boost1.67. You can find a

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

Hi Sebastian, There maybe something wrong -- "It works for me". But I did get one error report already (on the r-sig-debian list, part of the R lists, good resource) On 24 October 2018 at 16:32, Sebastian Meyer wrote: | Yesterday I updated | | elpa-ess:amd64 (17.11-4~ubuntu16.04.1~ppa1,

Bug#911291: r-cran-bh: Missleading version

On 18 October 2018 at 11:15, Andreas Tille wrote: | Package: r-cran-bh | Severity: normal | | Hi, | | when I tried to build r-cran-rstan version 2.18.1 which is LinkingTo BH | (>= 1.66) I failed when building against r-cran-bh. I think r-cran-bh | should reflect the version of libboost which

Bug#909725: quantlib-swig: FTBFS on mips64el

On 27 September 2018 at 18:42, Adrian Bunk wrote: | Control: tags -1 patch | | On Thu, Sep 27, 2018 at 12:01:56PM +0200, Mattia Rizzolo wrote: | > Source: quantlib-swig | > Version: 1.13-5 | > Severity: serious | > | >

Bug#908408: /quantlib-swig: FTBFS on hppa -- Build needs to use long calls

On 9 September 2018 at 18:10, Dirk Eddelbuettel wrote: | | On 9 September 2018 at 18:49, John David Anglin wrote: | | On 2018-09-09 6:45 PM, Dirk Eddelbuettel wrote: | | > Now, one thing has me puzzled. You say the build failed, but on the on | | > status page hppa looks

Bug#908408: /quantlib-swig: FTBFS on hppa -- Build needs to use long calls

On 9 September 2018 at 18:49, John David Anglin wrote: | On 2018-09-09 6:45 PM, Dirk Eddelbuettel wrote: | > Now, one thing has me puzzled. You say the build failed, but on the on | > status page hppa looks "green": | > | > https://buildd.debian.org/status/packa

Bug#908408: /quantlib-swig: FTBFS on hppa -- Build needs to use long calls

On 9 September 2018 at 18:17, John David Anglin wrote: | On 2018-09-09 3:01 PM, Dirk Eddelbuettel wrote: | > | #    CXXFLAGS="-O0 -g0 --param ggc-min-expand=20 -DBOOST_NO_AUTO_PTR | > | -mlong-calls"                 \ | > | > Right. | -ffunction-sections isn't enough.  We

Bug#908408: /quantlib-swig: FTBFS on hppa -- Build needs to use long calls

On 9 September 2018 at 14:44, John David Anglin wrote: | On 2018-09-09 11:56 AM, Dirk Eddelbuettel wrote: | > Thanks for the hint and its testing! | > | > I'll add this. Before I do so can you quickly check if the tests in | > debian/rules identify the platform correctly? Ie

Bug#908408: /quantlib-swig: FTBFS on hppa -- Build needs to use long calls

On 9 September 2018 at 11:08, John David Anglin wrote: | Source: quantlib-swig | Version: 1.13-5 | Severity: normal | | Dear Maintainer, | | The build fails here: | g++ -shared -O0 -g0 --param ggc-min-expand=20 -DBOOST_NO_AUTO_PTR -Wdate-time -D_FORTIFY_SOURCE=2

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

On 6 September 2018 at 13:03, Zack Weinberg wrote: | Yes, that is correct: | | ii emacs 1:25.2+1-11 | ii emacs-bin-common 1:25.2+1-11 | ii emacs-common 1:25.2+1-11 | ii emacs-gtk 1:25.2+1-11 | ii emacsen-common3.0.2 | | See my other message: this appears to

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

Weird. And you are running the standard emacs from testing/unstable, correct? Because that is what I loaded inside Docker -- emacs and then ess (ie elpa-ess). I am not sure how I could proceed given that I cannot reproduce this. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel |

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

Zack, On 5 September 2018 at 06:22, Dirk Eddelbuettel wrote: | | Hi Zack, | | Thanks for the report. I am CCing David who was very helpful with the | transition to elpa-ess. I am wondering if we can address this here, or | whether I need to talk to upstream about this. | | David, any

Bug#908004: quantlib-swig: does not build for all supported versions of Python 3

Hi Michael, On 5 September 2018 at 15:05, Michael Hudson-Doyle wrote: | Source: quantlib-swig | Version: 1.13-4 | Severity: normal | Tags: patch | | Dear Maintainer, | | Currently the build process builds only for the default version of | Python 3. It's not hard to build for all supported

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

Hi Zack, Thanks for the report. I am CCing David who was very helpful with the transition to elpa-ess. I am wondering if we can address this here, or whether I need to talk to upstream about this. David, any thought? Is this something that (package-initialize) may fix? Another trick to pass

Bug#907382: Corebird timing out

I am getting the exact same issue, have been googling, and found eg an older upstream issue (https://github.com/baedert/corebird/issues/599) where I added the current issue. However, a German-language Debian forum had a link to this: https://www.patreon.com/posts/corebirds-future-18921328

Bug#907165: package installation fails with "ERROR: install script from ess package failed"

On 24 August 2018 at 13:50, Stefano Zacchiroli wrote: | On Fri, Aug 24, 2018 at 06:40:24AM -0500, Dirk Eddelbuettel wrote: | > and it is as 17.11-4 in 'experimental' (I was debating dropping it into | [...] | > Can you try the 'elpa-ess' and 'ess' (transition) package set,

Bug#907165: package installation fails with "ERROR: install script from ess package failed"

On 24 August 2018 at 13:13, Stefano Zacchiroli wrote: | Package: ess | Version: 17.11-3 | Severity: serious | | scaramouche $ sudo dpkg --configure ess | Setting up ess (17.11-3) ... | Install emacsen-common for emacs25 | emacsen-common: Handling install of emacsen flavor emacs25 |

Bug#907119: gsl: fix underlinking of libgsl against libgslcblas

Ok -- I can't categorically exclude that something is also irregular with my repo and debian/patches. So I reversed the existing patch, then applied your changes, dpkg-source --commit'ed locally -- and it is building now. And inspecting the pbuilder dir while it is happening shows the two

Bug#907119: gsl: fix underlinking of libgsl against libgslcblas

On 23 August 2018 at 17:18, Steve Langasek wrote: | On Thu, Aug 23, 2018 at 06:53:29PM -0500, Dirk Eddelbuettel wrote: | | > Ok. I am being stupid. | | > I applied the .debdiff you sent via patch ... < ... redirection. That gets me | > a modified Makefile.am and two new debian/pa

Bug#907119: gsl: fix underlinking of libgsl against libgslcblas

Ok. I am being stupid. I applied the .debdiff you sent via patch ... < ... redirection. That gets me a modified Makefile.am and two new debian/patches/ files. But then the build command complains about Makefile.am, dpkg-source --commit fails ("reversed patch") so I undo Makefile.am. But then

<    1   2   3   4   5   6   7   8   9   10   >