As lyx is not listed in 'Writing R Extensions', the one (authorative) manual
describing how to build packages for R, I would not assume it to be present
on every CRAN machine building packages. Also note that several user recently
had to ask here how to deal with less common fonts for style
Hi Michelle,
On 21 May 2024 at 13:46, Nixon, Michelle Pistner wrote:
| Hi all,
|
| I'm running into build issues for my package (fido:
https://github.com/jsilve24/fido) on the r-devel-linux-x86_64-debian-clang
system on CRAN (full check log here:
On 21 May 2024 at 15:59, Ivan Krylov wrote:
| On Tue, 21 May 2024 14:48:48 +0200
| Kurt Hornik wrote:
|
| > I guess foer the CXXFLAGS we want dpkg-buildflags --get CXXFLAGS?
Good catch, and expansion, by both of you.
| It must be the case. It's both the documented option [1] and it
|
On 21 May 2024 at 13:01, Jeroen Ooms wrote:
| Compiling packages with C++ code using the default r-base-dev
| configuration on debian:sid shows a lot of:
|
|cc1plus: warning: '-Werror=' argument
| '-Werror=implicit-function-declaration' is not valid for C++
|
| Can this flag be removed
On 20 May 2024 at 19:12, Andreas Tille wrote:
| Source: car
| Version: 3.1-2-2
| Severity: normal
|
| Hi,
|
| car mentions r-cran-maptools in (Build-)Depends which is not backed up
| by the DESCRIPTION file. Since maptools is removed from CRAN I'd like
Yes, we fail to build if 'added'
On 18 May 2024 at 07:59, Dirk Eddelbuettel wrote:
|
| Hi Laurent,
|
| We a build issue in Debian found via bulk rebuilds. Which everything current
| in 'unstable', rpy2 (version 3.5.16) segfaults in a test when embedding.
|
| Details are at https://bugs.debian.org/1071362
|
| If you kee 1071
On 18 May 2024 at 07:59, Dirk Eddelbuettel wrote:
|
| Hi Laurent,
|
| We a build issue in Debian found via bulk rebuilds. Which everything current
| in 'unstable', rpy2 (version 3.5.16) segfaults in a test when embedding.
|
| Details are at https://bugs.debian.org/1071362
|
| If you kee 1071
Appears to be a duplicate of 1071379, maybe check if your script meant to
remove another one.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
On 17 May 2024 at 23:05, Santiago Vila wrote:
| Dirk Eddelbuettel wrote:
| > Is there a chance this could be spurious?
|
| Unlikely because it also happens here:
|
| https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rpy2.html
Ok, I will get in touch with Laurent.
D
On 17 May 2024 at 23:05, Santiago Vila wrote:
| Dirk Eddelbuettel wrote:
| > Is there a chance this could be spurious?
|
| Unlikely because it also happens here:
|
| https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rpy2.html
Ok, I will get in touch with Laurent.
D
Is there a chance this could be spurious? The R API is reasonably stable,
including the part for embedding R (and I am upstream for a small project
doing that from C++). rpy2 is also mature and stable. So could this be a
one-off?
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel |
Is there a chance this could be spurious? The R API is reasonably stable,
including the part for embedding R (and I am upstream for a small project
doing that from C++). rpy2 is also mature and stable. So could this be a
one-off?
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel |
On 16 May 2024 at 05:34, Duncan Murdoch wrote:
| I forget now, but presumably the thinking at the time was that Suggested
| packages would always be available for building and checking vignettes.
Yes. I argued for years (cf https://dirk.eddelbuettel.com/blog/2017/03/22/
from seven (!!) years
On 10 May 2024 at 06:28, Dirk Eddelbuettel wrote:
|
| On 10 May 2024 at 10:54, Graham Inggs wrote:
| | Source: r-cran-ff
| | Version: 4.0.12+ds-1
| | Severity: serious
| | X-Debbugs-Cc: Dirk Eddelbuettel
| | User: debian...@lists.debian.org
| | Usertags: regression
| |
| | Hi Maintainer
On 10 May 2024 at 06:28, Dirk Eddelbuettel wrote:
|
| On 10 May 2024 at 10:54, Graham Inggs wrote:
| | Source: r-cran-ff
| | Version: 4.0.12+ds-1
| | Severity: serious
| | X-Debbugs-Cc: Dirk Eddelbuettel
| | User: debian...@lists.debian.org
| | Usertags: regression
| |
| | Hi Maintainer
On 10 May 2024 at 11:01, Graham Inggs wrote:
| Source: r-bioc-mutationalpatterns
| Version: 3.12.0+dfsg-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-bioc-mutationalpatterns' autopkgtest regresses when
On 10 May 2024 at 11:04, Graham Inggs wrote:
| Source: r-bioc-s4vectors
| Version: 0.40.2+dfsg-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-bioc-s4vectors' autopkgtest regresses when tested with r
On 10 May 2024 at 11:01, Graham Inggs wrote:
| Source: r-bioc-mutationalpatterns
| Version: 3.12.0+dfsg-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-bioc-mutationalpatterns' autopkgtest regresses when
On 10 May 2024 at 11:04, Graham Inggs wrote:
| Source: r-bioc-s4vectors
| Version: 0.40.2+dfsg-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-bioc-s4vectors' autopkgtest regresses when tested with r
On 10 May 2024 at 10:58, Graham Inggs wrote:
| Source: r-bioc-iranges
| Version: 2.36.0-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-bioc-iranges' autopkgtest regresses when tested with r-base 4.4.0
On 10 May 2024 at 10:58, Graham Inggs wrote:
| Source: r-bioc-iranges
| Version: 2.36.0-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-bioc-iranges' autopkgtest regresses when tested with r-base 4.4.0
On 10 May 2024 at 10:54, Graham Inggs wrote:
| Source: r-cran-ff
| Version: 4.0.12+ds-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-cran-ff's autopkgtest regresses when tested with r-base 4.4.0 [1
On 10 May 2024 at 10:54, Graham Inggs wrote:
| Source: r-cran-ff
| Version: 4.0.12+ds-1
| Severity: serious
| X-Debbugs-Cc: Dirk Eddelbuettel
| User: debian...@lists.debian.org
| Usertags: regression
|
| Hi Maintainer
|
| r-cran-ff's autopkgtest regresses when tested with r-base 4.4.0 [1
Software Heritage (see [1] for their website and [2] for a brief intro I gave
at useR! 2019 in Toulouse) covers GitHub and CRAN [3]. It is by now 'in
collaboration with UNESCO', supported by a long and posh list of sponsors [4]
and about as good as it gets to 'ensure longevity of artifacts'.
It
On 9 May 2024 at 03:20, Sameh Abdulah wrote:
| I need to serialize and save a 20K x 20K matrix as a binary file.
Hm that is an incomplete specification: _what_ do you want to do with it?
Read it back in R? Share it with other languages (like Python) ? I.e. what
really is your use case? Also,
On 8 May 2024 at 11:02, Josiah Parry wrote:
| CRAN has rejected this package with:
|
| * Size of tarball: 18099770 bytes*
|
| *Please reudce to less than 5 MB for a CRAN package.*
Are you by chance confusing a NOTE (issued, but can be overruled) with a
WARNING (more severe, likely a
Package: r-cran-tmb
Version: 1.9.11-1
Severity: important
CRAN package Matrix had a new release 1.7.0 bringing in a new
SuiteSparse API which requires a rebuild if (and only if) the
Matrix headers are used. Your package is one of those that do,
and therefore needs a rebuild.
This was
Package: r-cran-openmx
Version: 2.21.11+dfsg-3
Severity: important
CRAN package Matrix had a new release 1.7.0 bringing in a new
SuiteSparse API which requires a rebuild if (and only if) the
Matrix headers are used. Your package is one of those that do,
and therefore needs a rebuild.
This was
Package: r-cran-irlba
Version: 2.3.5.1-3
Severity: important
CRAN package Matrix had a new release 1.7.0 bringing in a new
SuiteSparse API which requires a rebuild if (and only if) the
Matrix headers are used. Your package is one of those that do,
and therefore needs a rebuild.
This was
On 30 April 2024 at 11:59, peter dalgaard wrote:
| svn diff -c 86235 ~/r-devel/R
Which is also available as
https://github.com/r-devel/r-svn/commit/f7c46500f455eb4edfc3656c3fa20af61b16abb7
Dirk
| (or 86238 for the port to the release branch) should be easily backported.
|
| (CC Luke in
The file 'issue_563_fread.txt' appears to be an input to data.table::fread()
for a test on encodings, glancing at the context.
I can run 'R CMD check --as-cran data.table_1.15.4.tar.gz' just fine [1] here
without any failing tests (and I have no locale or anything set). It's not my
package but
The package is pristine at CRAN
https://cran.r-project.org/web/checks/check_results_data.table.html
(apart from some new warnings several packages now get about interal R API
headers, nothing to do with tests)
Maybe you can sort this with upstream -- data.table is effectively holding up
On 30 April 2024 at 01:21, Rolf Turner wrote:
| On Mon, 29 Apr 2024 06:30:20 -0500
| Dirk Eddelbuettel wrote:
|
|
|
| > These days, I strongly recommend r2u [1]. As you already use R via
| > CRAN through apt, r2u adds one more repository after which _all_ R
| > packages are ha
Rolf,
This question might have been more appropriate for r-sig-debian than here.
But as Simon noted, the lack of detail makes is difficult to say anything to
aid. It likely was an issue local to your setup and use.
These days, I strongly recommend r2u [1]. As you already use R via CRAN
Package: r-cran-data.table
Version: 1.14.10+dfsg-1
Severity: normal
data.table had a release 1.15.0 in January -- the first new one in three
years! -- and two follow-ups since bringing it 1.15.4 at CRAN.
Please update the Debian package to the current upstream version.
This should likely
On 27 April 2024 at 10:53, 신선영(수학과) via ESS-help wrote:
| Dear all,
|
| I get the following error message:
|
| make -C lisp all
| make[1]: Entering directory '/home/mathi/ess-24.01.1/lisp'
| test -f ../etc/.IS.RELEASE || wget -qO -
reassign 1069842 r-base
thanks
On 25 April 2024 at 18:27, Santiago Vila wrote:
| Package: src:rjava
| Version: 1.0-11-1
| Severity: serious
| Tags: ftbfs
|
| Dear maintainer:
|
| During a rebuild of all packages in unstable, your package failed to build:
Thanks for this. It is caused by the
reassign 1069842 r-base
thanks
On 25 April 2024 at 18:27, Santiago Vila wrote:
| Package: src:rjava
| Version: 1.0-11-1
| Severity: serious
| Tags: ftbfs
|
| Dear maintainer:
|
| During a rebuild of all packages in unstable, your package failed to build:
Thanks for this. It is caused by the
Hi Kurt,
On 25 April 2024 at 08:07, Kurt Hornik wrote:
| > Hervé Pagès writes:
|
| > Hi Kurt,
| > Is it intended that numeric_version() returns an error by default on
| > non-character input in R 4.4.0?
|
| Dear Herve, yes, that's the intention.
|
| > It seems that I can turn this into
On 21 April 2024 at 15:25, Sebastiaan Couwenberg wrote:
| On 4/21/24 3:04 PM, Dirk Eddelbuettel wrote:
| > R upstream no longer releases or tests for 32 bits (and has not since the R
| > 4.3.0 release a year ago) so 'expect trouble there'. I think you all in the
| > release team
Hi Graham, Hi Release Team,
On 21 April 2024 at 13:37, Graham Inggs wrote:
| On Thu, 18 Apr 2024 at 13:38, Dirk Eddelbuettel wrote:
| > Right now it now only shows 'all reports (re-)running'.
|
| That was because of the new upload, but I see the results there now.
|
| The packa
Hi Paul,
On 18 April 2024 at 11:50, Paul Gevers wrote:
| Hi Dirk,
|
| On 18-04-2024 4:41 a.m., Dirk Eddelbuettel wrote:
| > I uploaded a first
| > beta release r-base_4.3.3.20240409-1 to 'experimental' a week ago, I just
| > followed up with a rc release r-base_4.3.3.20240416-1.
|
R 4.4.0 will be released on April 24 (following the long established pattern
of annual 'a.b.0' releases). As is common, nightlies (as alpha, betas, rc)
have been made available for four weeks leading up to it. I uploaded a first
beta release r-base_4.3.3.20240409-1 to 'experimental' a week ago,
R 4.4.0 will be released on April 24 (following the long established pattern
of annual 'a.b.0' releases). As is common, nightlies (as alpha, betas, rc)
have been made available for four weeks leading up to it. I uploaded a first
beta release r-base_4.3.3.20240409-1 to 'experimental' a week ago,
As an aside, the odd format does not seem to bother data.table::fread() which
also happens to be my personally preferred workhorse for these tasks:
> fname <- "/tmp/r/filename.csv"
> read.csv(fname)
Gene SNP prot log10p
1 YWHAE 13:62129097_C_T 1433 7.35
2 YWHAE 4:72617557_T_TA
On 16 April 2024 at 10:46, jing hua zhao wrote:
| Dear R-developers,
|
| I came to a somewhat unexpected behaviour of read.csv() which is trivial but
worthwhile to note -- my data involves a protein named "1433E" but to save
space I drop the quote so it becomes,
|
| Gene,SNP,prot,log10p
|
On 9 April 2024 at 18:45, Jose Manuel Abuin Mosquera wrote:
| If possible, I would like to contribute. At work we use the Go and
| Python implementations, also, in the short term, we will start using the
| Rust one.
Similar for us, and we have seen plenty of build headaches across pypi or
On 9 April 2024 at 18:45, Jose Manuel Abuin Mosquera wrote:
| If possible, I would like to contribute. At work we use the Go and
| Python implementations, also, in the short term, we will start using the
| Rust one.
Similar for us, and we have seen plenty of build headaches across pypi or
On 9 April 2024 at 18:45, Jose Manuel Abuin Mosquera wrote:
| If possible, I would like to contribute. At work we use the Go and
| Python implementations, also, in the short term, we will start using the
| Rust one.
Similar for us, and we have seen plenty of build headaches across pypi or
On 8 April 2024 at 18:21, Lucas Thode wrote:
| Apologies for the confusion, I didn't realize the patch in question was a new
| addition. Just confirmed that it errors out instead of segfaulting or
hanging.
Thanks for confirming!
Dirk
| On Sat, Apr 6, 2024 at 5:32 PM Dirk Eddelbuettel
Hi Lucas,
As Milan suggested, please sure you are current. If in doubt, park you
current checkout and start from
git checkout https://github.com/eddelbuettel/dieharder.git
where you should see today's commit from merging PR 24.
edd@rob:~/git/dieharder(master)$ git ls | head
*
Hi Lucas,
On 30 March 2024 at 22:47, Lucas Thode wrote:
| Package: dieharder
| Version: 3.31.1.4-1.1
| Severity: normal
| X-Debbugs-Cc: thode...@gmail.com
|
| Dear Maintainer,
|
| `dieharder -d 209 -n $nvalue` crashes for $nvalue>17:
|
| $ dieharder -d 209
|
On 2 April 2024 at 09:41, Duncan Murdoch wrote:
| On 02/04/2024 8:50 a.m., Dirk Eddelbuettel wrote:
| > On 2 April 2024 at 07:37, Dirk Eddelbuettel wrote:
| > blosxom, simple as it is, takes (IIRC) filesystem ctime as the posting
| > timestamp so would be best if you had a backup wit
On 2 April 2024 at 07:37, Dirk Eddelbuettel wrote:
|
| On 2 April 2024 at 08:21, Duncan Murdoch wrote:
| | I have just added R-4-4-branch to the feeds. I think I've also fixed
| | the \I issue, so today's news includes a long list of old changes.
|
| These feeds can fussy: looks like you
On 2 April 2024 at 08:21, Duncan Murdoch wrote:
| I have just added R-4-4-branch to the feeds. I think I've also fixed
| the \I issue, so today's news includes a long list of old changes.
These feeds can fussy: looks like you triggered many updates. Feedly
currently greets me with 569 new
On 1 April 2024 at 17:44, Uwe Ligges wrote:
| Untested:
|
| install.packages() calls available.packages() to find out which packages
| are available - and passes a "filters" argument if supplied.
| That can be a user defined filter. It should be possible to write a user
| defined filter which
On 31 March 2024 at 11:43, Martin Morgan wrote:
| So all repositories are consulted and then the result filtered to contain just
| the most recent version of each. Does it matter then what order the
| repositories are visited?
Right. I fall for that too often, as I did here. The order matters
Julian,
Arrow is a complicated and large package. We use it at work (where there is a
fair amount of Python, also to Conda etc) and do have issues with more
complex builds especially because it is 'data infrastructure' and can come in
from different parts. I would recommend against packaging at
Julian,
Arrow is a complicated and large package. We use it at work (where there is a
fair amount of Python, also to Conda etc) and do have issues with more
complex builds especially because it is 'data infrastructure' and can come in
from different parts. I would recommend against packaging at
Julian,
Arrow is a complicated and large package. We use it at work (where there is a
fair amount of Python, also to Conda etc) and do have issues with more
complex builds especially because it is 'data infrastructure' and can come in
from different parts. I would recommend against packaging at
Julian,
Arrow is a complicated and large package. We use it at work (where there is a
fair amount of Python, also to Conda etc) and do have issues with more
complex builds especially because it is 'data infrastructure' and can come in
from different parts. I would recommend against packaging at
Julian,
Arrow is a complicated and large package. We use it at work (where there is a
fair amount of Python, also to Conda etc) and do have issues with more
complex builds especially because it is 'data infrastructure' and can come in
from different parts. I would recommend against packaging at
Greg,
There are AFAICT two issues here: how R unrolls the named vector that is the
'repos' element in the list 'options', and how your computer resolves DNS for
localhost vs 172.17.0.1. I would try something like
options(repos = c(CRAN = "http://localhost:3001/proxy;,
On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
| Dear all,
|
| I have a question regarding the R-devel version of .make_numeric_version()
function. As far as I can understand, the current code
Marco,
It usually helps to be aware of one's hardware platform ;-)
There is an option for Docker command to tell it to switch to x86_64, my
colleagues who are on M1 and alike use that to access the generally richer
eco-system of binaries for the Intel world. If on the other hand you prefer
to
: https://github.com/google/highway
docs: https://google.github.io/highway/en/master/
|
| Op di 26 mrt 2024 om 15:41 schreef Dirk Eddelbuettel :
| >
| >
| > On 26 March 2024 at 10:53, jesse koops wrote:
| > | How can I make this portable and CRAN-acceptable?
| >
| > But wri
On 27 March 2024 at 11:03, Prof Brian Ripley via R-devel wrote:
| On 27/03/2024 10:28, Alexandre Courtiol wrote:
| > Hi all,
| >
| > I don't know if it is a local issue on my hands or not, but after
| > installing R-devel the output of grDevices::dev.capabilities()$paths is
| > FALSE, while it
On 26 March 2024 at 09:37, Dirk Eddelbuettel wrote:
|
| Avi,
|
| That was a hickup and is now taken care of. When discussing this (off-line)
| with Jeroen we (rightly) suggested that keeping an eye on
Typo, as usual, "he (rightly) suggested". My bad.
D.
|
|https://con
On 26 March 2024 at 10:53, jesse koops wrote:
| How can I make this portable and CRAN-acceptable?
But writing (or borrowing ?) some hardware detection via either configure /
autoconf or cmake. This is no different than other tasks decided at
install-time.
Start with 'Writing R Extensions', as
Avi,
That was a hickup and is now taken care of. When discussing this (off-line)
with Jeroen we (rightly) suggested that keeping an eye on
https://contributor.r-project.org/svn-dashboard/
is one possibility to keep track while we have no status alert system from
CRAN. I too was quite
On 25 March 2024 at 11:12, Jairo Hidalgo Migueles wrote:
| I'm reaching out to seek some guidance regarding the storage of relatively
| large data, ranging from 10-40 MB, intended for use within an R package.
| Specifically, this data consists of regression and random forest models
| crucial for
On 23 March 2024 at 07:25, Dirk Eddelbuettel wrote:
|
| On 22 March 2024 at 11:12, Dirk Eddelbuettel wrote:
| |
| | On 27 February 2024 at 19:01, Dirk Eddelbuettel wrote:
| | | A couple of days ago, the (effective) Maintainer and rather active
developer
| | | of the Matrix package Mikael
On 23 March 2024 at 07:25, Dirk Eddelbuettel wrote:
|
| On 22 March 2024 at 11:12, Dirk Eddelbuettel wrote:
| |
| | On 27 February 2024 at 19:01, Dirk Eddelbuettel wrote:
| | | A couple of days ago, the (effective) Maintainer and rather active
developer
| | | of the Matrix package Mikael
On 22 March 2024 at 11:12, Dirk Eddelbuettel wrote:
|
| On 27 February 2024 at 19:01, Dirk Eddelbuettel wrote:
| | A couple of days ago, the (effective) Maintainer and rather active developer
| | of the Matrix package Mikael Jagan (CC'ed) posted on the r-package-devel
list
| | (the primary
On 22 March 2024 at 11:12, Dirk Eddelbuettel wrote:
|
| On 27 February 2024 at 19:01, Dirk Eddelbuettel wrote:
| | A couple of days ago, the (effective) Maintainer and rather active developer
| | of the Matrix package Mikael Jagan (CC'ed) posted on the r-package-devel
list
| | (the primary
On 27 February 2024 at 19:01, Dirk Eddelbuettel wrote:
| A couple of days ago, the (effective) Maintainer and rather active developer
| of the Matrix package Mikael Jagan (CC'ed) posted on the r-package-devel list
| (the primary list for R package development) that the upcoming change
On 27 February 2024 at 19:01, Dirk Eddelbuettel wrote:
| A couple of days ago, the (effective) Maintainer and rather active developer
| of the Matrix package Mikael Jagan (CC'ed) posted on the r-package-devel list
| (the primary list for R package development) that the upcoming change
Salut Annaig,
On 21 March 2024 at 09:26, Annaig De-Walsche wrote:
| Dear R-package-devel Community,
|
| I hope this email finds you well. I am reaching out to seek assistance
regarding package development in R.
|
| Specifically, I am currently developing an R package for querying composite
Hi Chris,
On 20 March 2024 at 11:05, Chris Lamb wrote:
| Source: gretl
| Version: 2023c-2.1
| Severity: wishlist
| Tags: patch
| User: reproducible-bui...@lists.alioth.debian.org
| Usertags: timestamps
| X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
|
| Hi,
|
| Whilst working on the
Dear Uwe,
Did CRAN ever reach a decision here with a suitable volunteer (or group of
volunteers) ? The state of XML came up again recently on mastodon, and it
might be helpful to share an update if there is one.
Thanks, as always, for all you and the rest of the team do for CRAN.
Cheers,
Years ago Duncan set up a nightly job to feed RSS based off changes to NEWS,
borrowing some setup parts from CRANberries as for example the RSS 'compiler'.
That job is currently showing the new \I{...} curly protection in an
unfavourable light. Copying from the RSS reader I had pointed at this
-Depends to fix build issue
from side effects of t64 transition (Closes:
#1065216)
-- Dirk Eddelbuettel Mon, 04 Mar 2024 08:54:45 -0600
I will take care of it in -3.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
-Depends to fix build issue
from side effects of t64 transition (Closes:
#1065216)
-- Dirk Eddelbuettel Mon, 04 Mar 2024 08:54:45 -0600
I will take care of it in -3.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
On 5 March 2024 at 15:12, Duncan Murdoch wrote:
| On 05/03/2024 2:26 p.m., Dirk Eddelbuettel wrote:
| > The default behaviour is to build after every commit to the main branch.
But
| > there are options. On the repo I mentioned we use
| >
| > "branch": "*rele
On 5 March 2024 at 13:28, Duncan Murdoch wrote:
| What I'm seeing is that the tags are ignored, and it is distributing the
| HEAD of the main branch. I don't think most users should be using that
| version: in my packages it won't have had full reverse dependency
| checks, I only do that
On 5 March 2024 at 11:56, Duncan Murdoch wrote:
| I have mixed feelings about r-universe. On the one hand, it is really
| nicely put together, and it offers the service described above. On the
| other, it's probably a bad idea to follow its advice and use
| install.packages() with `repos`
On 5 March 2024 at 06:25, Duncan Murdoch wrote:
| You could make a compatible version of `survivalmodels` available on a
| non-CRAN website, and refer to that website in the
| Additional_repositories field of DESCRIPTION.
Every r-universe sub-site fits that requirement. For this package
On 1 March 2024 at 23:36, Aurelien Jarno wrote:
| Source: r-base
| Version: 4.3.3-1
| Severity: serious
| Tags: ftbfs
| Justification: fails to build from source (but built successfully in the past)
| User: debian-gl...@lists.debian.org
| Usertags: libtirpc-dev
|
| Dear maintainer,
|
|
On 1 March 2024 at 23:36, Aurelien Jarno wrote:
| Source: r-base
| Version: 4.3.3-1
| Severity: serious
| Tags: ftbfs
| Justification: fails to build from source (but built successfully in the past)
| User: debian-gl...@lists.debian.org
| Usertags: libtirpc-dev
|
| Dear maintainer,
|
|
Hi Murray,
On 4 March 2024 at 07:03, Murray Efford wrote:
| Dirk
| Thanks for a very helpful reply. I'll simplify my return values.
|
| I mentioned Intel with rhub2 in my earlier post here, but I'm sorry
| that was somewhat buried. Debugging is somewhere between painful and
| impossible when
And "beauty" (ahem) of discussion scattered over two mailing lists: I now see
you have a testbed via rhub2 (good) even though it does not reproduce (hm...).
So you could still try the suggested simplication.
Cheers, Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
On 3 March 2024 at 20:47, Murray Efford wrote:
| A couple of days ago I posted on R-package-devel about a mysterious
| segfault from R CMD checks of my package secrdesign (see
| https://CRAN.R-project.org/package=secrdesign, and
| https://github.com/MurrayEfford/secrdesign) The issue rises only
the following:
|
| > extSoftVersion()["BLAS"]
Ah yes -- I keep forgetting about that one. Good reminder!
| Thanks for your help!
Always a pleasure. Glad you are all set.
Dirk
| On Sat, Feb 24, 2024 at 9:17 AM Dirk Eddelbuettel wrote:
|
|
| On 24 February 2024 at 11:44, Ro
Hi Nikhil,
Don't post images. I read in a text-based reader. The mailing list software
also scrubs html (I think).
I would simplify. Start with the simplest Rcpp Modules setup. Then add. Check
checking. Eventually on your way towards what you are doing now you may spot
the error.
Hope this
On 29 February 2024 at 00:20, Steve Langasek wrote:
| Dear maintainer,
|
| Please find attached a final version of this patch for the time_t
| transition. This patch is being uploaded to unstable.
|
| Note that this adds a versioned build-dependency on dpkg-dev, to guard
| against accidental
On 29 February 2024 at 00:20, Steve Langasek wrote:
| Dear maintainer,
|
| Please find attached a final version of this patch for the time_t
| transition. This patch is being uploaded to unstable.
|
| Note that this adds a versioned build-dependency on dpkg-dev, to guard
| against accidental
On 28 February 2024 at 21:28, mwhud...@fastmail.fm wrote:
| Dear maintainer,
|
| Please find attached a final version of this patch for the time_t
| transition. This patch is being uploaded to unstable.
|
| Note that this adds a versioned build-dependency on dpkg-dev, to guard
| against
On 28 February 2024 at 21:28, mwhud...@fastmail.fm wrote:
| Dear maintainer,
|
| Please find attached a final version of this patch for the time_t
| transition. This patch is being uploaded to unstable.
|
| Note that this adds a versioned build-dependency on dpkg-dev, to guard
| against
On 28 February 2024 at 10:17, Sébastien Villemot wrote:
| Salut Dirk,
|
| Le mercredi 21 février 2024 à 06:54 -0600, Dirk Eddelbuettel a écrit :
| > Source: ess
| > Version: 24.01.0-1
| > Severity: minor
| >
| > Salut Seb -- and thanks for packaging the recent 24.1.0 which in
On 28 February 2024 at 19:05, Avraham Adler wrote:
| I am hoping the solution to this question is simple, but I have not
| been able to find one. I am building a routine in C to be called from
| R. I am including Rmath.h. However, when I have a call to "log", I get
| the error "called object
1 - 100 of 15988 matches
Mail list logo
