Package: r-cran-knitr
Severity: normal
We have knitr 1.31 per
https://packages.debian.org/search?keywords=r-cran-knitr
but upstream is (since April) at 1.33 per
https://cran.r-project.org/package=knitr
which is now needed by e.g. rgl aka r-cran-rgl.
We are in a freeze, so I too have been
Hi there,
On 16 June 2021 at 13:52, Vagrant Cascadian wrote:
| Source: tclap
| Severity: normal
| Tags: patch
| User: reproducible-bui...@lists.alioth.debian.org
| Usertags: buildpath usrmerge shell
| X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
|
| The build path, several binary
Andreas,
On 9 April 2021 at 23:40, Andreas Beckmann wrote:
| On 09/04/2021 23.23, Dirk Eddelbuettel wrote:
|
| > | The --doc-main-package option can be used when the
| > | auto-detection is insufficient or to reset the path to its previous
| > | value if there is
Hi John,
On 26 April 2021 at 23:00, John Scott wrote:
| Source: gsl
| Version: 2.6+dfsg-2
| Severity: wishlist
|
| Examples are included in doc/examples along with text files that appear
| to contain the programs' output. You'll probably want to just install
| the *.c and *.h files though.
On 9 April 2021 at 22:33, Andreas Beckmann wrote:
| On 09/04/2021 22.19, Dirk Eddelbuettel wrote:
| > That is ... quite possible. It's actually the same with line above in
| > debian/rules. The actual underlying problem, though, is that a lot of
| > content that once appears to have
On 6 April 2021 at 17:18, Andreas Beckmann wrote:
| Package: gretl
| Version: 2021a-1
| Severity: normal
| User: debian...@lists.debian.org
| Usertags: piuparts
|
| Hi,
|
| during a test with piuparts I noticed your package ships (or creates)
| a broken symlink.
|
| >From the attached log
On 8 April 2021 at 11:29, Graham Inggs wrote:
| Control: forwarded -1 https://deb.li/6f4z
|
| TMB upstream have submitted a bug report [1] to R-forge.
|
| > Headers need update corresponding to new SuiteSparse version 5.7.1
| >
| > SuiteSparse was recently updated from version 4.2.1 to 5.7.1,
On 25 March 2021 at 20:29, Rogério Theodoro de Brito wrote:
| On March 25, 2021 1:31:11 PM GMT-03:00, Dirk Eddelbuettel
wrote:
| >
| >Howdy,
| >
| >On 25 March 2021 at 13:12, Rogério Brito wrote:
| >| I was looking into some of my executables and discovered tha
Howdy,
On 25 March 2021 at 13:12, Rogério Brito wrote:
| I was looking into some of my executables and discovered that /usr/bin/r is
| not stripped and it contains debugging info on my system:
|
| ,[ file /usr/bin/r ]
| | /usr/bin/r: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
Rock, meet hard place.
The last change I made for Debian was just that: https://bugs.debian.org/968531
So I may have to close your bug report instead.
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
On 9 March 2021 at 14:26, Graham Inggs wrote:
| Control: tags -1 - fixed-upstream + upstream
| Control: notforwarded -1
|
|
| >From TMB upstream [1]:
|
| > Digging a bit deeper I found that after calling
| >
| > M_cholmod_factorize_p(A, mm, (int*)NULL, 0 /*fsize*/, f, )
| >
| > the
On 8 March 2021 at 20:05, Davide Prina wrote:
| Package: jags
| Version: 4.3.0-3
| Severity: normal
|
| I have see that the project homepage do not respond anymore:
| http://www-fis.iarc.fr/~martyn/software/jags/
Good catch. Martyn Plummer no longer works there but is now at Warwick. I'll
Hi Graham and Martin,
Thanks for coming back to this, I had also meant to write to Martin this
weekend.
On 6 March 2021 at 19:16, Graham Inggs wrote:
| Is there a bug opened for this issue with Matrix upstream?
Per field Bug-Reports in DESCRIPTION, the repo (and bug tracker) are (still)
at
Graham, Martin,
So I logged back onto the s390x box we can access. Matrix 1.13-2 does fail
the factorization test when doing
_R_CHECK_FORCE_SUGGESTS_=false R CMD check --no-manual \
--no-vignettes Matrix_1.3-2.tar.gz
and Matrix 1.2-18 passes it. So Graham was right all-along
If it were me I would turn off the autopkgtest in r-cran-glmmtmb (maybe just
on s390x) and move on. I still have not been convinced by anyone that it is
an issue in package Matrix causing this.
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Indeed: "Should" is the operational term here.
But just pointing at packages for which I am upstream author / maintainer and
Debian maintainer, we already use the other approach for RcppArmadillo,
RcppEigen, RcppCCTZ, RcppDate, ... and we fudged it for BH with the empty
shell r-cran-bh which
severity 982465 wishlist
thanks
I am sorry but I simply see no bug in package r-base here.
The RcppParallel maintainer tried a Debian-local modification to that CRAN
package. That didn't work, and now fingers are pointed at r-base.
Which is simply not the right way to go about this as package
Graham,
Thanks for the bug tracker follow-up which made me aware of the ongoing
discussion in #665 at glmmTMB. It's frustrating to have the run around but it
really looks like as I argued all along: not an issue in Matrix. Now, TMB is
of course a complex package too.. Appreciate you chasing
On 17 February 2021 at 16:58, Graham Inggs wrote:
| Hi Dirk
|
| On Wed, 17 Feb 2021 at 15:10, Dirk Eddelbuettel wrote:
| > Graham: What does that bigendian box say for Sys.info()[["machine"]] ?
|
| The other big-endian box I tested was perotto.debian.net [*], it says:
|
wnloaded_packages$
(Obviously the if above could be indentented and all that.)
Graham: What does that bigendian box say for Sys.info()[["machine"]] ?
Should we test for endianness instead? And then maybe try to roll up to the
cause of the difference?
Dirk
| Best, Martin
|
Martin,
I have this long-running bug report against Matrix, triggered by glmmTMB on
s390x. Graham has been chasing this patiently and we are now at the level of
checking on a shell account on the appropriate hardware.
We validated that everything does in fact "still break" with CRAN-current
On 14 February 2021 at 12:00, Graham Inggs wrote:
| glmmTMB upstream came up with a minimal reproducer (see forwarded bug):
|
| stopifnot(require("testthat"),
| require("glmmTMB"),
| require("lme4"))
| data("Orthodont", package="nlme")
| fm1 <- glmmTMB(distance ~ age +
On 11 February 2021 at 16:06, Johannes Ranke wrote:
| > | > The documentation does not list a search behaviour for bare library
| > | > names on non-Windows systems. So completely ignoring the system library
| > | > paths is kind of weird.
| > |
| > | I can see that it looks weird - but is it
On 11 February 2021 at 12:50, Johannes Ranke wrote:
| Am Donnerstag, 11. Februar 2021, 12:20:33 CET schrieb Bastian Blank:
| > Hi Johannes
|
| Hello Bastian!
|
| > On Thu, Feb 11, 2021 at 09:26:48AM +0100, Johannes Ranke wrote:
| > > dyn.load is used in base R to load compiled code from R
On 10 February 2021 at 20:35, Bastian Blank wrote:
| On Wed, Feb 10, 2021 at 01:30:10PM -0600, Dirk Eddelbuettel wrote:
| > Thanks for the CVE. I am happy to discuss this with R Core and one fellow in
| > particular.
| > Before I do so can you clarify what you think the issue is? Loa
Hi Bastian,
On 10 February 2021 at 20:03, Bastian Blank wrote:
| Hi Dirk
|
| On Wed, Feb 10, 2021 at 12:18:04PM -0600, Dirk Eddelbuettel wrote:
| > As for your suggested patch to R's own dynload.c: that is very well tested
| > and robust system code I do not have any real int
Hi Bastian,
Thanks for taking the time to propose a bug report.
However (and please see below) I don't think this is the way forward. There
have been a lot of recent changed in RcppParallel upstream (as I lurk on the
GH repo which is part of our Rcpp org), and maybe some of these things will
Hi Graham,
On 2 February 2021 at 11:32, Graham Inggs wrote:
| Control: forwarded -1 https://github.com/glmmTMB/glmmTMB/issues/665
|
| After another detour via #981623, r-cran-glmmtmb is now also rebuilt.
| Even with the rebuilt r-cran-glmmtmb, I still see the "gradient
| function must return a
On 6 February 2021 at 15:17, Sébastien Villemot wrote:
| Le samedi 06 février 2021 à 08:12 -0600, Dirk Eddelbuettel a écrit :
|
| > # edd 03 Apr 2003 cf Section 10.1.2 of Debian Policy
| > # edd 06 Feb 2021 #982069, with a nod to Python's
debian/PVER-minimal.posti
On 6 February 2021 at 14:57, Sébastien Villemot wrote:
| Le samedi 06 février 2021 à 07:49 -0600, Dirk Eddelbuettel a écrit :
| > So I now have this. Or do I need to protect /usr/local/lib/R/site-
| > library too?
|
| You need to protect both.
|
| In order to simplify the code, you ca
So I now have this. Or do I need to protect /usr/local/lib/R/site-library too?
# edd 03 Apr 2003 cf Section 10.1.2 of Debian Policy
# edd 06 Feb 2021 #982069
if [ ! -e /usr/local/lib/R ]; then
if [ -f /etc/staff-group-for-usr-local ]; then
if mkdir /usr/local/lib/R
On 6 February 2021 at 10:04, Sébastien Villemot wrote:
| Package: r-base-core
| Version: 3.5.2-1
That is two+ years behind (3.5.0 released April 2018, 3.6.0 in April 2019,
4.0.0 last year -- and 4.1.0 soon).
| Severity: normal
|
| Hi Dirk,
|
| The /usr/local/lib/R directory (and its
On 31 January 2021 at 20:09, Graham Inggs wrote:
| Hi Dirk
|
| On Sun, 31 Jan 2021 at 16:13, Dirk Eddelbuettel wrote:
| > This is a bug in glmmTMB.
|
| I don't see how you can be so sure.
Experience around R. glmmTMB is a huge package with many dependencies, there
will be a stale
On 31 January 2021 at 09:20, Graham Inggs wrote:
| Control: reopen -1
|
| Hi Dirk
|
| Paul's test results showed that the run-unit-test autopkgtest still
| fails with the same errors (
| Error: gradient function must return a numeric vector of length...) as
| in my original report.
|
|
| The
Hi Graham,
On 28 January 2021 at 08:19, Graham Inggs wrote:
| On Thu, 28 Jan 2021 at 01:12, Dirk Eddelbuettel wrote:
| > Any update here? It still points at Matrix aka rmatrix aka r-cran-matrix,
| > and I still think wrongly.
|
| I'm still waiting for the results of the autopkgtest a
Graham,
Any update here? It still points at Matrix aka rmatrix aka r-cran-matrix,
and I still think wrongly.
Best, Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Package: wnpp
Owner: Dirk Eddelbuettel
Severity: wishlist
* Package name: xrprof
Version : 0.3.1
Upstream Author : Aaron Jacobs
* URL or Web page : https://github.com/atheriel/xrprof
* License : GPL-2
Description : External sampling profiler for R
This (still
On 25 January 2021 at 21:39, Graham Inggs wrote:
| Thanks again for your input on this issue!
Always a pleasure :)
Best, Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
On 25 January 2021 at 09:17, Graham Inggs wrote:
| Hi
|
| On Sun, 24 Jan 2021 at 18:06, Graham Inggs wrote:
| > I'm awaiting autopkgtest results on the binNMU'd r-cran-tmb. I will
| > update this bug and #980809 when they are in.
|
| The autopkgtests for r-cran-tmb [1] and r-cran-glmmtmb [2]
On 25 January 2021 at 10:21, Andreas Tille wrote:
| Hi Graham,
|
| On Mon, Jan 25, 2021 at 10:31:36AM +0200, Graham Inggs wrote:
| > Control: tags -1 + patch
| >
| > The attached patch upgrades the warning() to a stop().
| > This will cause r-cran-tmb's autopkgtests to fail whenever rmatrix is
Hi Graham,
On 24 January 2021 at 18:06, Graham Inggs wrote:
| Hi Dirk
|
| On Sun, 24 Jan 2021 at 14:47, Dirk Eddelbuettel wrote:
| > R code can promote warnings to errors on a per-session basis:
|
| Thanks! This could be useful in the r-cran-tmb autopkgtest.
|
| > I am still not quit
Howdy,
On 24 January 2021 at 18:01, Graham Inggs wrote:
| Hi Andreas
|
| On Sun, 24 Jan 2021 at 09:55, Andreas Tille wrote:
| > dh-r injects versioned dependencies if this is specified in the
| > DESCRIPTION file of an r-* package. If this is not specified we
| > need to add this manually
Hi Graham,
On 24 January 2021 at 17:53, Graham Inggs wrote:
| On Sun, 24 Jan 2021 at 07:10, Dirk Eddelbuettel wrote:
| > There is a confusion here. You filed this again rmatrix (aka "Matrix").
| > Matrix does not impose dependencies -- dependent packages do.
|
| I filed
On 24 January 2021 at 06:08, Graham Inggs wrote:
| The actual warning message is generated by r-base, is there a way to
| make this an error instead of a warning?
R code can promote warnings to errors on a per-session basis:
> warning("I am just a warning")
Warning message:
I am just
Graham,
On 24 January 2021 at 06:08, Graham Inggs wrote:
| Source: rmatrix
| Version: 1.3-2-1
| Severity: important
| Control: affects -1 src:r-cran-tmb
| X-Debbugs-CC: debia...@lists.debian.org
|
| Hi R Maintainers
There is a confusion here. You filed this again rmatrix (aka "Matrix").
Hi Graham,
On 23 January 2021 at 00:21, Graham Inggs wrote:
| On Fri, 22 Jan 2021 at 23:38, Dirk Eddelbuettel wrote:
| > Can you still please talk to the corresponding Debian maintainer for glmmTMB
| > so that he/she can walk it upstream?
|
| I have assigned this bug to both packages,
Hi Graham,
On 22 January 2021 at 23:13, Graham Inggs wrote:
| Hi Dirk
|
| On Fri, 22 Jan 2021 at 22:39, Dirk Eddelbuettel wrote:
| > Matrix 1.3.0 from December has long been known to fail. Please use release
1.3.2.
|
| The test at [2], run at 2021-01-22 17:34:51 UTC was against
| r-c
On 22 January 2021 at 22:03, Graham Inggs wrote:
| While investigating this failure, I noticed the following output in
| the test log:
|
|
| > library('glmmTMB')
| Warning message:
| In checkMatrixPackageVersion() : Package version inconsistency detected.
| TMB was built with Matrix version
On 22 January 2021 at 21:45, Graham Inggs wrote:
| Source: rmatrix, r-cran-glmmtmb
| Control: found -1 rmatrix/1.3-0-1
| Control: found -1 r-cran-glmmtmb/1.0.2.1-1
| Severity: serious
| Tags: sid bullseye
| X-Debbugs-CC: debian...@lists.debian.org
| User: debian...@lists.debian.org
| Usertags:
Package: wnpp
Owner: Dirk Eddelbuettel
Severity: wishlist
* Package name: r-cran-nanotime
Version : 0.3.2
Upstream Author : Dirk Eddelbuettel and Leonardo Silvestri
* URL or Web page : https://github.com/eddelbuettel/nanotime
* License : GPL-2+
Description
On 18 January 2021 at 13:49, Ian Jackson wrote:
| Control: tags -1 + confirmed
|
| Dirk Eddelbuettel writes ("Bug#977919: vm: Mail quoting no longer works in
emacs27"):
| >
| > As per the previous bug report emacs27 and vm are having some issues.
Another
| > wart i
On 18 January 2021 at 13:47, Ian Jackson wrote:
| Control: priority -1 normal
|
| Dirk Eddelbuettel writes ("Bug#977918: vm: Package vm prevents clean emacs27
start"):
| > And of course in a minimal container with just emacs27 and vm the issue does
| > not reproduce. Wh
On 6 January 2021 at 05:33, Peter Hickey wrote:
| Thanks. I've been camping since Christmas without laptop/reception but I'll
| be back next week and deal with these issues
Ah the 'seasonal' advantages of being down under! Lovely. Take your time;
we have to wait on Martin Maechler and CRAN to
On 5 January 2021 at 19:20, Michael R. Crusoe wrote:
| On Tue, 5 Jan 2021 at 19:12, Dirk Eddelbuettel wrote:
|
| > On 5 January 2021 at 18:41, Michael R. Crusoe wrote:
| >
|
|
| > | r-cran-matrix 1.3-0-1 causes a bug that is evidently fixed in version
| > | 1.3-2
| &g
On 5 January 2021 at 18:41, Michael R. Crusoe wrote:
| Source: rmatrix
| Version: 1.3-0-1
| Severity: important
|
| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA512
|
| Hello,
|
| r-cran-matrix 1.3-0-1 causes a bug that is evidently fixed in version
| 1.3-2
|
On 28 December 2020 at 00:25, Aurelien Jarno wrote:
| Package: r-cran-pbkrtest
| Version: 0.5-0.1-1
| Severity: serious
|
| r-cran-pbkrtest is currently not installable in sid:
|
| # apt-get install r-cran-pbkrtest
| Reading package lists... Done
| Building dependency tree
| Reading state
Package: wnpp
Severity: wishlist
* Package name: r-cran-rcppdate
Version : 0.0.1
Upstream Author : Dirk Eddelbuettel
* URL or Web page : https://cran.r-project.org/package=RcppDate
* License : GPL (>= 2)
Description : R bindings of Date library
This is the sec
Package: wnpp
Severity: wishlist
* Package name: r-cran-rcppcctz
Version : 0.2.9-0
Upstream Author : Dirk Eddelbuettel
* URL or Web page : https://cran.r-project.org/package=RcppCCTZ
* License : GPL (>= 2)
Description : R binding for CCTZ
This is one of th
Package: vm
Version: 8.2.0b-6
Severity: serious
Using the (awesome !!) newer emacs 27.1, I am having issues with package
vm. One issue is that on startup, a message 'Package cl is deprecated' is
shown. Startup appears to finish in interactive, but does not in daemon
Package: vm
Version: 8.2.0b-6
Severity: serious
As per the previous bug report emacs27 and vm are having some issues. Another
wart is that mail replies no longer work. Hitting 'F' for a quoted reply
inserts the full email including headers _unquoted_ and _unindented_ with an
error message
Package: vm
Version: 8.2.0b-6
Severity: serious
Using the (awesome !!) newer emacs 27.1, I am having issues with package
vm. One issue is that on startup, a message 'Package cl is deprecated' is
shown. Startup appears to finish in interactive, but does not in daemon mode
which is how I used to
On 5 December 2020 at 12:09, Andreas Tille wrote:
| this issue is something for our advent calendar. Anybody with cblas
| knowledge?
I am the GNU GSL maintainer, and I at one point also worked a lot with the
Atlas and other LAPACK/BLAS packages. I think Mo may be wrong here: I did the
same
| Thanks!
|
|
| Anton
|
| Am Di., 24. Nov. 2020 um 21:57 Uhr schrieb Dirk Eddelbuettel
:
| > Thanks, that is pertinent. The error is actually from the final step where R
| > tries to load the package it just built. So the simplest solution then is
to
| > check that libquantlib0-dev
Hi Anton,
On 24 November 2020 at 20:53, Anton Gladky wrote:
| Package: rquantlib
| Version: 0.4.12-1
| Severity: important
| Tags: ftbfs
| User: team+bo...@tracker.debian.org
| Usertags: boost174
|
| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA512
|
| Dear maintainer,
|
| it was discovered
Package: wnpp
Owner: Dirk Eddelbuettel
Severity: wishlist
* Package name: r-cran-mathjaxr
Version : 1.0-1
Upstream Author : Wolfgang Viechtbauer
* URL or Web page : https://github.com/wviechtb/mathjaxr
* License : GPL-3
Description : GNU R package for 'Mathjax
On 19 November 2020 at 19:07, Andreas Tille wrote:
| Control: tags 972074 pending
| Control: block 972074 by 963392
|
| On Thu, Nov 19, 2020 at 07:53:06AM -0600, Dirk Eddelbuettel wrote:
| > |
| > | I do not have the slightest idea what this might mean.
| >
| > ABI/API slippage
On 19 November 2020 at 14:37, Andreas Tille wrote:
| Control: tags -1 help
|
| Hi, since version 0.7.0 (uploaded by Dylan Aïssi in CC) the autopkgtest
| of r-cran-bayestestr fails with the error mentioned in the bug log. It
| has slightly changed with the version I pushed to Git. It is now:
|
On 31 October 2020 at 18:46, Sebastian Ramacher wrote:
| On 2020-05-28 11:58:09 -0500, Dirk Eddelbuettel wrote:
| >
| > Thanks everybody for the help with the transition: 4.0.0-3 is now in
testing.
|
| So let's close this one.
Indeed. Thanks for catching that!
Dirk
|
Hi Simon,
On 16 August 2020 at 23:53, Simon McVittie wrote:
| Source: littler
| Version: 0.3.11-1
| Severity: minor
|
| A bug report against fteqcc (#968524) prompted me to look for other
| instances of the same anti-pattern on codesearch.debian.net.
|
| d/rules in littler invokes 'install
Nilesh,
On 12 August 2020 at 21:17, Nilesh wrote:
| Hi,
|
| This patch fixes the build. Let me know if something else is needed:
|
| --- a/SRC/primes_32.c
| +++ b/SRC/primes_32.c
| @@ -7,7 +7,7 @@
| #define NO 0
| #define NPRIMES 1000
|
| -int primes[NPRIMES];
| +extern int
Hi Shane,
On 25 July 2020 at 10:34, Shane McDonald wrote:
| This FTBFS is caused by a change in the default
| behaviour of GCC from version 9 to version 10.
| In version 10, if a global variable is defined in a
| header file, and that header file is included by
| several files, this results in
Package: wnpp
Owner: Dirk Eddelbuettel
Severity: wishlist
* Package name: r-cran-conquer
Version : 1.0.1
Upstream Author : Xuming He, Xiaoou Pan, Kean Ming Tan, and Wen-Xin Zhou
* URL or Web page : https://cran.r-project.org/package=conquer
* License : GPL-3
On 12 June 2020 at 16:38, Riccardo (Jack) Lucchetti wrote:
| On Fri, 12 Jun 2020, Dirk Eddelbuettel wrote:
|
| > | Quickly looking at the source code of gretl, I am under the impression
that it
| > | may need to be slightly patched in order to find the x13as executable (it
Hi Seb,
On 12 June 2020 at 15:59, Sébastien Villemot wrote:
| Package: gretl
| Version: 2020b-1
| Severity: wishlist
|
| Hi Dirk,
|
| gretl is able to take advantage of X-13ARIMA-SEATS (a.k.a. x13as) for
| performing seasonal adjustment of time series.
I know. There was some back and forth
It would be nice if we could hear from team r-cran-data.table on this matter.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
As a follow-up, I may have found the one commit for fixing the "'origin' must
be supplied" issue (from reading the upstream NEWS [1] backwards landing at
#4428 [2]
Dirk
[1] https://rdatatable.gitlab.io/data.table/news/index.html
[2] https://github.com/Rdatatable/data.table/pull/4428
--
On 8 June 2020 at 21:25, Paul Gevers wrote:
| Source: r-base, r-cran-data.table
| Control: found -1 r-base/4.0.1-1
| Control: found -1 r-cran-data.table/1.12.8+dfsg-1
| Severity: serious
| Tags: sid bullseye
| X-Debbugs-CC: debian...@lists.debian.org
| User: debian...@lists.debian.org
|
Package: wnpp
Owner: Dirk Eddelbuettel
Severity: wishlist
* Package name: r-cran-tmvnsim
Version : 1.0-2
Upstream Author : Samsiddhi Bhattacjarjee
* URL or Web page : https://cran.r-project.org/package=tmvnsim
* License : GPL-2
Description : GNU R package
Hi Graham,
On 4 June 2020 at 10:50, Graham Inggs wrote:
| On Wed, 3 Jun 2020 at 18:36, Dirk Eddelbuettel wrote:
| > Graham do you think you can get it turned off for at least openblas?
|
| Already fixed in Groovy [1] and the Stable Release Update [2] for
| Focal is in the queue [3] await
Conrad (of Armadillo fame) sent me this (and ok'ed passing it on):
According to an Intel report back from 2011, -Bsymbolic-functions "is
a dangerous option which can often result in some non-intuitive side
effects".
The report explicitly shows various problems with the option.
For completeness, Conrad Sanderson (who is the main author of Armadillo,
which is used inter alia by MLPACK) posted another good summary with links to
other projects including also a launchpad bug report:
https://bugs.launchpad.net/ubuntu/+source/openblas/+bug/1870138
Dirk
--
On 30 May 2020 at 21:39, Sébastien Villemot wrote:
| Control: tags -1 + patch
|
| Hi Graham,
|
| Le samedi 30 mai 2020 à 15:09 +0200, Graham Inggs a écrit :
|
| > I was able to reproduce this in Ubuntu 20.04 on i7-2600 with the
| > Rscript -e "example(solve)"
| > test case. Rebuilding
On 30 May 2020 at 15:09, Graham Inggs wrote:
| Hi
|
| I was able to reproduce this in Ubuntu 20.04 on i7-2600 with the
| Rscript -e "example(solve)"
| test case. Rebuilding with
| export DEB_LDFLAGS_MAINT_STRIP="-Wl,-Bsymbolic-functions"
| in debian/rules solved it for me.
|
| On Sat,
On 30 May 2020 at 01:19, Mo Zhou wrote:
| Control: tags -1 -moreinfo
|
| Hi Sébastien,
|
| Good catch! I tried to remove the mentioned LDFLAG
|
| DEB_LDFLAGS_MAINT_STRIP="-Wl,-Bsymbolic-functions"
|
| and rebuilt the openblas 3.8 package.
|
| Then deadlock issue disappeared.
Wow. Nice
Dylan,
On 29 May 2020 at 08:03, Dylan Aïssi wrote:
| Hi Dirk,
|
| Le jeu. 28 mai 2020 à 18:03, Dirk Eddelbuettel a écrit :
| >
| > OTOH the way we implement the tag doesn't it get added automagically by the
| > r-base-core package when constructing an r-{cran,bioc,...}-* package?
| &
On 29 May 2020 at 07:51, Dylan Aïssi wrote:
| Hi,
|
| Le jeu. 28 mai 2020 à 18:58, Dirk Eddelbuettel a écrit :
| >
| > Thanks everybody for the help with the transition: 4.0.0-3 is now in
testing.
| >
|
| \o/
|
| Both transition trackers (r-api-4.0 and r-api-bioc-3.11) were
On 29 May 2020 at 01:13, Mo Zhou wrote:
| Control: severity -1 important
| Control: tags -1 +moreinfo
| Clarification: possibly a Ubuntu bug
You may be right! I just double checked the earliest report (on the
r-sig-debian list) and it too was on Ubuntu 20.04!
| Hello guys,
|
| The way to
Thanks everybody for the help with the transition: 4.0.0-3 is now in testing.
Which is lovely as upstream is already at work with 4.0.1 which will drop on
June 6 [1]. I'll likely make an rc upload.
Special thanks to Graham for calmly pulling a few strings here and there.
Cheers, Dirk
[1]
On 28 May 2020 at 16:55, Sébastien Villemot wrote:
| Hi Dirk,
|
| Le jeudi 28 mai 2020 à 07:07 -0500, Dirk Eddelbuettel a écrit :
| > Package: libopenblas-dev
| > Version: 0.3.8+ds-1
| > Severity: serious
|
| > In short, when libopenblas-dev is installed (as e.g. fro
Hi Paul,
On 28 May 2020 at 08:23, Paul Gevers wrote:
| Hi Dirk,
|
| On 28-05-2020 01:14, Dirk Eddelbuettel wrote:
| > Shall I close this one 'by hand'? Or will it get closed by migrating
| > quantlib-swig? I just close the other one (#956830) that was at the start
of
| > thi
On 28 May 2020 at 10:10, Dylan Aïssi wrote:
| Package: lintian
| Version: 2.77.1
| Severity: wishlist
| X-Debbugs-CC: debia...@lists.debian.org
|
| Hi,
|
| I just saw a R binary package (r-cran-isospec) with wrong dependencies
| (bug not yet opened). Lintian doesn't warn about a problem in its
Package: libopenblas-dev
Version: 0.3.8+ds-1
Severity: serious
This is a somewhat 'late' bug report followed several on and off discussion
threads on debian-science and/or debian-r (and started on the r-sig-debian
list from the R Project).
In short, when libopenblas-dev is installed (as e.g.
Paul,
Shall I close this one 'by hand'? Or will it get closed by migrating
quantlib-swig? I just close the other one (#956830) that was at the start of
this by hand.
Best, Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Paul,
Thanks for the hint. The package for mipsel is now gone, migration of
quantlib-python should now resume.
Leaves the second part. Come to think about it I have never written an
debian/rules to _not_ build something. So maybe something like
ifneq "$(findstring $(cpu), mipsel)"
On 25 May 2020 at 09:32, Graham Inggs wrote:
| Hi All
|
| Thanks everyone for doing all the hundreds of uploads that were needed
| for this combined transition.
| All rebuilds for r-api-bioc3.11 are done [1] and there's one
| outstanding FTBFS on a release architecture for r-api-4.0 [2].
The
Package: ftp.debian.org
Severity: normal
My package quantlib-swig failed to build on mipsel for a while; I believe
this to be a standard 'resource starvation': the package is heavy on
templated C++ and needs a lot of ram.
Paul (CC'ed) reminded me in #961398 that the held up migration would
Hi Paul,
On 24 May 2020 at 20:31, Paul Gevers wrote:
| Hi Dirk,
|
| On 24-05-2020 20:19, Dirk Eddelbuettel wrote:
| > Hm. Easy to implement but won't it create a permanent 'fail' on that
platform?
| > (But then maybe that is the goal once I ask the release team to drop the old
| &g
Hi Paul,
On 24 May 2020 at 19:54, Paul Gevers wrote:
| Hi Dirk,
|
| On 24-05-2020 19:09, Dirk Eddelbuettel wrote:
| > But how I prevent the build in the future?
| >
| > Via 'Architecture: any [!xyx]' ? Last I checked I though we had no such
| > explicit white/black listin
On 24 May 2020 at 18:47, Paul Gevers wrote:
| Hi Dirk,
|
| On 24-05-2020 13:43, Dirk Eddelbuettel wrote:
| > This used to build. It just takes a long as it is a library with old-school
| > many templates "big C++".
| >
| > There is nothing I can do here. If it ends being
301 - 400 of 2397 matches
Mail list logo
