Simon,
This is still an issue for arm64. Uploaded tiledb and RQuantLib yesterday,
both already built binaries for macOS (thank you!) but on the x86_64 ones are
on the results page. Can you take another peek at this?
Thanks so much, Dirk
--
dirk.eddelbuettel.com | @eddelbuettel |
On 8 August 2023 at 13:17, Simon Urbanek wrote:
| To be honest I think the motivation of this thread is dubious at best: it is
a bad idea to use detectCore() blindly to specify parallelization and we
explicitly say it's a bad idea - any sensible person will set it according to
the demands,
On 8 August 2023 at 11:21, Simon Urbanek wrote:
| First, detecting HT vs cores is not necessarily possible in general, Linux
may assign core id to each HT depending on circumstances:
|
| $ grep 'cpu cores' /proc/cpuinfo | uniq
| cpu cores : 32
| $ grep 'model name' /proc/cpuinfo | uniq
|
On 7 August 2023 at 13:55, Grose, Daniel wrote:
| As I say - I cannot reproduce the error myself. I will try asking Uwe Ligges
| for more information.
Methinks you are doing it wrong. We created the r-package-devel list years
ago to take load away from the overworked CRAN maintainers who are
Hi Ivan,
I usually 'mentally applaud' when reading your replies on list but not here.
On 7 August 2023 at 16:15, Ivan Krylov wrote:
| SeuratObject 4.1.3. The breakage definitely exists, but not on the
| source package level.
You seem to overlook that a large part of the R Universe only works
On 7 August 2023 at 13:38, Grose, Daniel wrote:
| No - unfortunately not. I cannot reproduce the error locally so I posted the
| snippet that Uwe Ligges sent me regarding the failed CRAN submission. That is
| all of the information I have.
|
| For now I will follow Dirk's advice and see if the
Daniel,
This is not new, and not related to clang.
On 7 August 2023 at 12:58, Grose, Daniel wrote:
| Any ideas ?
Add a line
#define R_NO_REMAP 1
before _any_ inclusion of R headers. See Section 6 of Writing R Extensions.
If you use eg Rcpp it is done for you when you include Rcpp
On 7 August 2023 at 08:48, Nils Kehrein wrote:
| I recently noticed that `detectCores()` ignores the `logical=FALSE`
| argument on Linux platforms. This means that the function will always
| return the number of logical CPUs, i.e. it will count the number of threads
| that theoretically can run
CRAN, by relying on the powerful package management system that is part of R,
provides an unparalleled framework for extending R with nearly 20k packages.
We recently encountered an issue that highlights a missing element in the
otherwise outstanding package management system. So we would like
On 4 August 2023 at 00:06, Jeroen Ooms wrote:
| On Thu, Aug 3, 2023 at 9:16 PM Vivian Kong wrote:
| >
| > Hello,
| >
| > Are there any plans to add R packages for Ubuntu on other architectures in
addition to amd64? We are looking for s390x packages as the version from the
distro's package
Hi Vivian,
On 3 August 2023 at 19:15, Vivian Kong wrote:
| Are there any plans to add R packages for Ubuntu on other architectures in
addition to amd64? We are looking for s390x packages as the version from the
distro's package manger is 4.2.2. I'm happy to help in any way I can.
Ok, now I
On 2 August 2023 at 14:41, Ian Jackson wrote:
| Dirk Eddelbuettel writes ("Re: vm breakage with Emacs 29"):
| > On 2 August 2023 at 13:17, Ian Jackson wrote:
| > | Hi. Since you were helpful with #1039105 "Fails to start with Emacs
| > | 28" I thought I would dr
On 2 August 2023 at 14:41, Ian Jackson wrote:
| Dirk Eddelbuettel writes ("Re: vm breakage with Emacs 29"):
| > On 2 August 2023 at 13:17, Ian Jackson wrote:
| > | Hi. Since you were helpful with #1039105 "Fails to start with Emacs
| > | 28" I thought I would dr
On 31 July 2023 at 23:13, Adrian Bunk wrote:
| On Mon, Jun 19, 2023 at 04:37:22PM +0300, Adrian Bunk wrote:
| > On Tue, Jun 13, 2023 at 03:30:18PM -0500, Dirk Eddelbuettel wrote:
| > >
| > > On 13 June 2023 at 13:15, Steve Langasek wrote:
| > > | Control: reassign -1 r
On 31 July 2023 at 23:13, Adrian Bunk wrote:
| On Mon, Jun 19, 2023 at 04:37:22PM +0300, Adrian Bunk wrote:
| > On Tue, Jun 13, 2023 at 03:30:18PM -0500, Dirk Eddelbuettel wrote:
| > >
| > > On 13 June 2023 at 13:15, Steve Langasek wrote:
| > > | Control: reassign -1 r
On 25 July 2023 at 23:05, Lucas Nussbaum wrote:
| Source: quantlib-swig
| Version: 1.30-2
| Severity: serious
| Justification: FTBFS
| Tags: trixie sid ftbfs
|
| Hi,
|
| During a rebuild of all packages in sid, your package failed to build
| on amd64.
I'll get on this -- it is lagging behind
On 25 July 2023 at 23:05, Lucas Nussbaum wrote:
| Source: quantlib-swig
| Version: 1.30-2
| Severity: serious
| Justification: FTBFS
| Tags: trixie sid ftbfs
|
| Hi,
|
| During a rebuild of all packages in sid, your package failed to build
| on amd64.
I'll get on this -- it is lagging behind
On 24 July 2023 at 06:47, Helmut Grohne wrote:
| Source: gretl
| Version: 2023b-1
| Severity: important
| Tags: patch
|
| gretl contains an empty directory /usr/lib/pkgconfig. Due to having
| implemented the /usr-merge using directory aliasing, this directory is
| prone to loss.
Are we sure
On 23 July 2023 at 11:03, Dirk Eddelbuettel wrote:
| Note that the mlmRev authors / maintainers are the same as / a subset of the
| lme4 authors. They may have an idea.
|
| https://cran.r-project.org/package=mlmRev
I just ran `R CMD check mlmRev_*tar.gz` on my amd64 (under Ubuntu 23.04
On 23 July 2023 at 11:03, Dirk Eddelbuettel wrote:
| Note that the mlmRev authors / maintainers are the same as / a subset of the
| lme4 authors. They may have an idea.
|
| https://cran.r-project.org/package=mlmRev
I just ran `R CMD check mlmRev_*tar.gz` on my amd64 (under Ubuntu 23.04
On 23 July 2023 at 15:07, Graham Inggs wrote:
| Hi
|
| On Sun, 23 Jul 2023 at 13:11, Nilesh Patra wrote:
| > How do you conclude that?
| > The versions of affected packages are same in unstable and testing. They
| > fail in i386 with a newer version of lme4.
|
| For what it's worth,
On 23 July 2023 at 15:07, Graham Inggs wrote:
| Hi
|
| On Sun, 23 Jul 2023 at 13:11, Nilesh Patra wrote:
| > How do you conclude that?
| > The versions of affected packages are same in unstable and testing. They
| > fail in i386 with a newer version of lme4.
|
| For what it's worth,
On 23 July 2023 at 18:42, Nilesh Patra wrote:
| On Sun, 23 Jul 2023 07:15:09 -0500 Dirk Eddelbuettel wrote
| > Is this is not an example of a release manager override? The affectect
| > packages all work together in unstable and could migrate.
|
| How do you conclude that?
| The ve
On 23 July 2023 at 18:42, Nilesh Patra wrote:
| On Sun, 23 Jul 2023 07:15:09 -0500 Dirk Eddelbuettel wrote
| > Is this is not an example of a release manager override? The affectect
| > packages all work together in unstable and could migrate.
|
| How do you conclude that?
| The ve
Paul,
Is this is not an example of a release manager override? The affectect
packages all work together in unstable and could migrate.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Paul,
Is this is not an example of a release manager override? The affectect
packages all work together in unstable and could migrate.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
On 22 July 2023 at 16:07, Dirk Eddelbuettel wrote:
|
| Taylor,
|
| I believe we have been over this at StackOverflow but you may by now have
| deleted the question/
|
| On 21 July 2023 at 20:51, taylor brown via R-package-devel wrote:
| | I have a question about the DESCRIPTION file of an R
On 22 July 2023 at 21:45, Paul Gevers wrote:
| Source: lme4
| Version: 1.1-31-1
| Severity: serious
| Control: close -1 1.1-34-1
| X-Debbugs-CC: debia...@lists.debian.org
| Tags: sid trixie
| User: release.debian@packages.debian.org
| Usertags: out-of-sync
|
| Dear maintainer(s),
|
| The
On 22 July 2023 at 21:45, Paul Gevers wrote:
| Source: lme4
| Version: 1.1-31-1
| Severity: serious
| Control: close -1 1.1-34-1
| X-Debbugs-CC: debia...@lists.debian.org
| Tags: sid trixie
| User: release.debian@packages.debian.org
| Usertags: out-of-sync
|
| Dear maintainer(s),
|
| The
Taylor,
I believe we have been over this at StackOverflow but you may by now have
deleted the question/
On 21 July 2023 at 20:51, taylor brown via R-package-devel wrote:
| I have a question about the DESCRIPTION file of an R package that has some
c++ dependencies.
|
| This package of mine
Simon,
This still persists. As Murray reported, it happened for a while now, it is
still happening eg package tiledb has been rebuilt everywhere [1] since the
upload a few days ago -- yet the results page still reports builds two
uploads ago [2] for both arm64 variants of your macOS setup.
Can
On 16 July 2023 at 14:31, Simon Urbanek wrote:
| I looked into it and there was no issue on the build machine or staging
server, so it will require some more digging in the international waters ..
hopefully sometime next week…
Thanks for checking, sometimes one-offs happen.
Dirk
--
Simon,
On 12 July 2023 at 19:02, Dirk Eddelbuettel wrote:
|
| Simon,
|
| It looks like some result mirroring / pushing from your machines to CRAN fell
| over. One of my packages, digest 0.6.33, arrived on CRAN about a week ago,
| is built almost everywhere (apart from macOS_release_x86_64
The concerns over github going away (!!) (or altering references, tags,
releases, ...) may be somewhat alleviated by Software Heritage [1] covering
and 'preserving' it. FWIW I briefly spoke about that iniative and a possible
CRAN connection at useR! in Toulouse four years ago [2].
I think I
Graham,
On 13 July 2023 at 18:59, Graham Inggs wrote:
| I believe the attached patch should do the trick. It's basically
| Paul's list from message #210, plus r-cran-interval and
| r-cran-maldiquant. I've also used a << relationship against the
| versions in unstable, and appended a tilde at
Graham,
On 13 July 2023 at 18:59, Graham Inggs wrote:
| I believe the attached patch should do the trick. It's basically
| Paul's list from message #210, plus r-cran-interval and
| r-cran-maldiquant. I've also used a << relationship against the
| versions in unstable, and appended a tilde at
Hi Graham,
On 13 July 2023 at 11:14, Graham Inggs wrote:
| On Wed, 12 Jul 2023 at 19:07, Dirk Eddelbuettel wrote:
| > On 12 July 2023 at 19:47, Paul Gevers wrote:
| > | Yes, you only need to carry the Breaks until in the next release. So
| > | every Breaks that's present in the r-bas
Hi Graham,
On 13 July 2023 at 11:14, Graham Inggs wrote:
| On Wed, 12 Jul 2023 at 19:07, Dirk Eddelbuettel wrote:
| > On 12 July 2023 at 19:47, Paul Gevers wrote:
| > | Yes, you only need to carry the Breaks until in the next release. So
| > | every Breaks that's present in the r-bas
Simon,
It looks like some result mirroring / pushing from your machines to CRAN fell
over. One of my packages, digest 0.6.33, arrived on CRAN about a week ago,
is built almost everywhere (apart from macOS_release_x86_64 stuck at 0.6.32)
but the result page still has nags from the 0.6.31 build
Hi Paul,
On 12 July 2023 at 19:47, Paul Gevers wrote:
| On 12-07-2023 16:02, Dirk Eddelbuettel wrote:
| > I can add the Breaks as a 'best of the worse alternative'. And, I presume, I
| > can remove the existing four-year breaks? [1]
|
| Yes, you only need to carry the Breaks until in th
Hi Paul,
On 12 July 2023 at 19:47, Paul Gevers wrote:
| On 12-07-2023 16:02, Dirk Eddelbuettel wrote:
| > I can add the Breaks as a 'best of the worse alternative'. And, I presume, I
| > can remove the existing four-year breaks? [1]
|
| Yes, you only need to carry the Breaks until in th
Hi Paul,
On 11 July 2023 at 20:36, Paul Gevers wrote:
| On 11-07-2023 02:43, Dirk Eddelbuettel wrote:
| I'm totally on board for technical excellence, although I think we have
| different things in mind when we say that.
|
| In Debian, with more QA than we ever had before, we're finding
Hi Paul,
On 11 July 2023 at 20:36, Paul Gevers wrote:
| On 11-07-2023 02:43, Dirk Eddelbuettel wrote:
| I'm totally on board for technical excellence, although I think we have
| different things in mind when we say that.
|
| In Debian, with more QA than we ever had before, we're finding
On 10 July 2023 at 19:43, Dirk Eddelbuettel wrote:
| Someone simply didn't update our Debian package, so it lacks this change and
| fingers point at r-base when the fault, if there is one, is to let our
| package slip behind a compilation and code standard established at CRAN for
| the R 4.3.0
On 10 July 2023 at 19:43, Dirk Eddelbuettel wrote:
| Someone simply didn't update our Debian package, so it lacks this change and
| fingers point at r-base when the fault, if there is one, is to let our
| package slip behind a compilation and code standard established at CRAN for
| the R 4.3.0
Paul,
Here is a case in point from looking at the current excluses list (which is
by now indeed a little shorter).
One package that jumps out is r-cran-maldiquant. We are at version 1.22, with
Debian build 1.22-1.
But one second at the CRAN site and the page for the package shows that it is
Paul,
Here is a case in point from looking at the current excluses list (which is
by now indeed a little shorter).
One package that jumps out is r-cran-maldiquant. We are at version 1.22, with
Debian build 1.22-1.
But one second at the CRAN site and the page for the package shows that it is
Hi Paul,
On 9 July 2023 at 20:11, Paul Gevers wrote:
| On 09-07-2023 18:41, Dirk Eddelbuettel wrote:
| > On 9 July 2023 at 17:40, Paul Gevers wrote:
| > | Did we already discuss that r-cran-ps also seems to be impacted by the
| > | r-base change of the symbols thingy, as can be seen
Hi Paul,
On 9 July 2023 at 20:11, Paul Gevers wrote:
| On 09-07-2023 18:41, Dirk Eddelbuettel wrote:
| > On 9 July 2023 at 17:40, Paul Gevers wrote:
| > | Did we already discuss that r-cran-ps also seems to be impacted by the
| > | r-base change of the symbols thingy, as can be seen
On 9 July 2023 at 11:41, Dirk Eddelbuettel wrote:
| For spacetime and stars I suspect (based on past experience) possible
| interaction from the underlying graphics libraries.
Absent-minded typing error: "geospatial", of course. Not "graphics".
Dirk
--
dirk.eddelbuettel
On 9 July 2023 at 11:41, Dirk Eddelbuettel wrote:
| For spacetime and stars I suspect (based on past experience) possible
| interaction from the underlying graphics libraries.
Absent-minded typing error: "geospatial", of course. Not "graphics".
Dirk
--
dirk.eddelbuettel
Paul,
On 9 July 2023 at 17:40, Paul Gevers wrote:
| Did we already discuss that r-cran-ps also seems to be impacted by the
| r-base change of the symbols thingy, as can be seen in r-cran-xopen [1].
Correct me if I am wrong but the "symbols thingy" was not a change in R 4.2.*
to R 4.3.*. It
Paul,
On 9 July 2023 at 17:40, Paul Gevers wrote:
| Did we already discuss that r-cran-ps also seems to be impacted by the
| r-base change of the symbols thingy, as can be seen in r-cran-xopen [1].
Correct me if I am wrong but the "symbols thingy" was not a change in R 4.2.*
to R 4.3.*. It
Thanks for closing it.
I think in due course as you will see there
a) new tag does not help today (we already took care of the six packages
needing a
rebuild because of the graphics engine constant changing) and
b) what is likely being the exact same sets of packages having issue
On 7 July 2023 at 00:33, Nilesh Patra wrote:
| I think we are hitting this issue here:
https://github.com/tidyverse/dplyr/issues/6793
| The comment says "Looks like some package in the stack sets
R_forceSymbols(dll, TRUE)" and that package is tibble
|
| | $ grep -rnw R_forceSymbols
| |
On 7 July 2023 at 00:33, Nilesh Patra wrote:
| I think we are hitting this issue here:
https://github.com/tidyverse/dplyr/issues/6793
| The comment says "Looks like some package in the stack sets
R_forceSymbols(dll, TRUE)" and that package is tibble
|
| | $ grep -rnw R_forceSymbols
| |
On 6 July 2023 at 08:14, Dirk Eddelbuettel wrote:
|
| On 6 July 2023 at 14:31, Vincent van Hees wrote:
| | Thanks, in that case the REPLEX for the issue may need to be:
| |
| | > remember = Sys.getenv("_R_CHECK_AS_DATA_FRAME_EXPLICIT_METHOD_")
| |
On 6 July 2023 at 14:31, Vincent van Hees wrote:
| Thanks, in that case the REPLEX for the issue may need to be:
|
| > remember = Sys.getenv("_R_CHECK_AS_DATA_FRAME_EXPLICIT_METHOD_")
| > Sys.setenv("_R_CHECK_AS_DATA_FRAME_EXPLICIT_METHOD_" = TRUE)
| > data.frame(time = Sys.time())
|
Paul, Graham,
r-base 4.3.1-2 is now on its way. You will have to update / tweak the ben
file as there is no 'r-api-4.3' tag as there is no such thing API change
upstream in R itself.
Filing the bug reports against the handful of packages testing the graphics
engine version was the right thing
Paul, Graham,
r-base 4.3.1-2 is now on its way. You will have to update / tweak the ben
file as there is no 'r-api-4.3' tag as there is no such thing API change
upstream in R itself.
Filing the bug reports against the handful of packages testing the graphics
engine version was the right thing
Control: severity -1 normal
I am changing this back because
a) there is no general bug in R 4.3.1, and there newer was
there were a few packages requiring an update to the new graphics engine
version (as the packages choose to call R_GE_checkVersionOrDie, it is
coming from
Control: severity -1 normal
I am changing this back because
a) there is no general bug in R 4.3.1, and there newer was
there were a few packages requiring an update to the new graphics engine
version (as the packages choose to call R_GE_checkVersionOrDie, it is
coming from
On 4 July 2023 at 16:00, Graham Inggs wrote:
| Source: r-base
| Version: 4.3.1-1
| Tags: patch
|
| Hi Maintainer
|
| r-base has a build-dependency, and r-base-dev has a dependency, on the
| ancient libpcre3-dev package. I believe these are no longer required
| since the dependencies on the
On 1 July 2023 at 15:26, Graham Inggs wrote:
| Your patch has 'rgraphicsapiversion' and 'r-graphics-api-4.3'.
|
| Upstream [1] refer to it as follows:
|
| The graphics engine version, R_GE_version, has been bumped to 16
| and so packages that provide graphics devices should be
|
This is not a bug in r-base, and does not warrant a transition.
I have written at some length about it, and (if I find some time) will expand
on it in blog post. I will also try to coordinate with upstream.
In short, R header GraphicsEngine.h [1] defines an integer constant declaring
the
This is not a bug in r-base, and does not warrant a transition.
I have written at some length about it, and (if I find some time) will expand
on it in blog post. I will also try to coordinate with upstream.
In short, R header GraphicsEngine.h [1] defines an integer constant declaring
the
On 29 June 2023 at 10:22, Dirk Eddelbuettel wrote:
|
| Package: r-cran-svglite
| Version: 2.1.1-1
| Severity: normal
|
| R 4.3.0 brought (once again) a new graphics API which requires a rebuild for
| functionality that involves creating graphics device. Once rebuilt the
| following will again
Package: r-cran-tikzdevice
Version: 0.12.4-1
Severity: normal
R 4.3.0 brought (once again) a new graphics API which requires a rebuild for
functionality that involves creating graphics device. Once rebuilt the
following will again work:
> getRversion()
[1] ‘4.3.1’
>
On 28 June 2023 at 17:39, Jeremy Bícha wrote:
| Control: severity -1 serious
|
| On Wed, Jun 28, 2023 at 5:29 PM Dirk Eddelbuettel wrote:
| > Feel free to change the severity back if you truly think it is that serious.
|
| Done.
|
| Feel free to close the bug once r-base is ready to migr
On 28 June 2023 at 17:39, Jeremy Bícha wrote:
| Control: severity -1 serious
|
| On Wed, Jun 28, 2023 at 5:29 PM Dirk Eddelbuettel wrote:
| > Feel free to change the severity back if you truly think it is that serious.
|
| Done.
|
| Feel free to close the bug once r-base is ready to migr
Package: r-cran-ragg
Version: 1.2.5-1
Severity: normal
R 4.3.0 brought (once again) a new graphics API which requires a rebuild for
functionality that involves creating graphics device. Once rebuilt the
following will again work:
> getRversion()
[1] ‘4.3.1’
>
Package: r-cran-svglite
Version: 2.1.1-1
Severity: normal
R 4.3.0 brought (once again) a new graphics API which requires a rebuild for
functionality that involves creating graphics device. Once rebuilt the
following will again work:
> getRversion()
[1] ‘4.3.1’
>
Feel free to change the severity back if you truly think it is that serious.
Some of the autopkgtests may be stumbling about the graphics API change and
may need a rebuild of packages interfacing it: svglite, ggplot2, ragg,
tikzdevice. As some of these are widely used the rest may be
severity 1039721 normal
thanks
Hi Jeremy,
That is a false positive (more below) and a duplicate of #1039510; the
discussion of the latter now continues on the debian-r list.
On 28 June 2023 at 12:31, Jeremy Bícha wrote:
| Source: r-base
| Version: 4.3.1-1
| Severity: serious
|
| I'm copying
severity 1039721 normal
thanks
Hi Jeremy,
That is a false positive (more below) and a duplicate of #1039510; the
discussion of the latter now continues on the debian-r list.
On 28 June 2023 at 12:31, Jeremy Bícha wrote:
| Source: r-base
| Version: 4.3.1-1
| Severity: serious
|
| I'm copying
On 28 June 2023 at 14:03, Andreas Tille wrote:
| Am Wed, Jun 28, 2023 at 08:11:05AM +0200 schrieb Bas Couwenberg:
| > 189s DLL requires the use of native symbols
|
| I wonder, whether all those bugs against single r-* packages are
| sensible.
Yes they are. Those are bugs in the packages
On 28 June 2023 at 14:03, Andreas Tille wrote:
| Am Wed, Jun 28, 2023 at 08:11:05AM +0200 schrieb Bas Couwenberg:
| > 189s DLL requires the use of native symbols
|
| I wonder, whether all those bugs against single r-* packages are
| sensible.
Yes they are. Those are bugs in the packages
nce _forever_. Invoking it adds this header above
##' .. content for \description{} (no empty lines) ..
##'
##' .. content for \details{} ..
##' @title
##' @param x
##' @param y
##' @return
##' @author Dirk Eddelbuettel
pyth <- function(x, y) {
sq
On 27 June 2023 at 15:36, Carl Boettiger wrote:
| tools::R_user_dir() provides configurable directories for R packages
| to write persistent information consistent with standard best
| practices relative to each supported operating systems for
| applications to store data, config, and cache
Hi Thomas,
On 27 June 2023 at 22:05, Thomas Lange wrote:
| Hi Dirk,
|
| I'm a vm user for reading my mail.
So there's two of us! :-)
| Thanks a lot for this bug report and fix. It also works for me.
| Patching /etc/emacs/site-start.d/50vm-init.el still compiles vm-vars
| and vm-version, but
Hi Paul,
On 27 June 2023 at 20:08, Paul Gevers wrote:
| Hi Dirk,
|
| On 26-06-2023 22:21, Dirk Eddelbuettel wrote:
| > I really appreciate the diligence and detail you put into this.
| >
| > But I would like to offer a simple shortcut. I am also CCing debian-r again
| > as this
Hi Paul,
On 27 June 2023 at 20:08, Paul Gevers wrote:
| Hi Dirk,
|
| On 26-06-2023 22:21, Dirk Eddelbuettel wrote:
| > I really appreciate the diligence and detail you put into this.
| >
| > But I would like to offer a simple shortcut. I am also CCing debian-r again
| > as this
Hi Paul,
I really appreciate the diligence and detail you put into this.
But I would like to offer a simple shortcut. I am also CCing debian-r again
as this has come up time and time again, is guaranteed to come up again for
as long as combine autopkgtests with letting packages go stake.
Hi Paul,
I really appreciate the diligence and detail you put into this.
But I would like to offer a simple shortcut. I am also CCing debian-r again
as this has come up time and time again, is guaranteed to come up again for
as long as combine autopkgtests with letting packages go stake.
On 26 June 2023 at 21:03, Uwe Ligges wrote:
| On 26.06.2023 02:52, Bernd.Gruber wrote:
| > Thanks, just to make sure:
| >
| > In the policy I find the entry:
| >
| > Additional_repositories:
|
| You can use this for CRAN-style repositories. Not for other inds of
| storage. In that case you
Ben,
POSIX level / glibc level variables are set at process start and AGAIK cannot
really be altered after start. They clearly work when set _before_ calling
sqrt(-1):
$ LANGUAGE=es Rscript -e 'sqrt(-1)'
[1] NaN
Warning message:
In sqrt(-1) : Se han producido NaNs
$
Package: vm
Version: 8.2.0b-8
Severity: normal
Ian,
After updating my main machine (and the only one running vm along and
exim4, dovecot, spamassassin and whatnot) to Ubuntu 23.04 with its Emacs 28.2
(in an upgrade from 22.10 with Emacs 27.*), I found that vm (which I have
been using all
Question #707095 on VM changed:
https://answers.launchpad.net/vm/+question/707095
Dirk Eddelbuettel gave more information on the question:
Uninstalling and re-installing the package worked. That should of
course have been doing the upgrade -- somehow it didn't remake the .elc
fine.
So still
New question #707095 on VM:
https://answers.launchpad.net/vm/+question/707095
After upgrading from Ubuntu 22.10 to 23.04, I cannot launch `vm`. It results
in an error
Wrong number of arguments: #, 0
from either the `(require 'vm)` or a simple `M-x vm`. The emacs version is
On 24 June 2023 at 21:35, Stephen Wade wrote:
| Doesnt seem like the system package is worth it. Should the convention
| simply be to bundle the headers in the package then? What about package
| size - is there some limit to the size of included libraries/headers to
| consider for CRAN?
Here is
Nilesh,
But nobody suggested to turn 32bit builds for R off so it was not a question
that needed adressing. Or did I miss something here?
We do have _a_ package failing. My first suggestion always is to talk to
upstream (and I did so on June 13 in my first post on this bug report). Has
Hi Philip,
On 21 June 2023 at 20:15, Philip Rinn wrote:
| Hi,
|
| could we please close this bug? We released bookworm some days ago and
| propagating to testing should be fine now. [It blocks R packages to propagate
to
| testing currently.]
Thanks for the reminder. I think we had informal
Hi Philip,
On 21 June 2023 at 20:15, Philip Rinn wrote:
| Hi,
|
| could we please close this bug? We released bookworm some days ago and
| propagating to testing should be fine now. [It blocks R packages to propagate
to
| testing currently.]
Thanks for the reminder. I think we had informal
On 21 June 2023 at 07:48, Iago Giné Vázquez wrote:
| Although R 4.3.1 has been released some days ago, and in
http://cloud.r-project.org/bin/linux/debian/ it is claimed that
|
|
| Debian bullseye has been released with R 4.0.4. If you want to upgrade to R
4.3.1 on bullseye, you can use the
Hi William,
On 20 June 2023 at 16:06, William Becker wrote:
| I am the maintainer of a package which is unfortunately involved in a
complicated dispute regarding its intellectual property (since the package was
partly built under a contract with an organisation), but also the "branding" of
On 19 June 2023 at 16:37, Adrian Bunk wrote:
| On Tue, Jun 13, 2023 at 03:30:18PM -0500, Dirk Eddelbuettel wrote:
| >
| > On 13 June 2023 at 13:15, Steve Langasek wrote:
| > | Control: reassign -1 r-cran-rstan r-cran-bh
| > | Control: found -1 r-cran-rstan/2.21.8-1
| > |
| &g
On 13 June 2023 at 13:15, Steve Langasek wrote:
| Control: reassign -1 r-cran-rstan r-cran-bh
| Control: found -1 r-cran-rstan/2.21.8-1
|
| Unfortunately, at least in Ubuntu it appears the r-cran-rstan build still
| exhausts the 32-bit memory space even with boost 1.81.
|
|
On 13 June 2023 at 00:46, Josh Triplett wrote:
| On Mon, Jun 12, 2023 at 05:03:01PM -0500, Dirk Eddelbuettel wrote:
| >
| > reassign 1037113 screen-message
| > thanks
| >
| > Binary package 'sm' is from source package 'screen-message'
| >
| > Binary package 'r-cran-sm' i
On 12 June 2023 at 16:08, Steve Langasek wrote:
| On Mon, Jun 12, 2023 at 05:22:39PM -0500, Dirk Eddelbuettel wrote:
| > edd@rob:~$ cat deb/bh/debian/control
| > Source: r-cran-bh
| > Section: gnu-r
| > Priority: optional
| > Maintainer: Dirk Eddelbuettel
| &g
th discussing.) So for the last few years _Debian's_
r-cran-bh was an empty virtual package dependending on what Debian has as
libboost* (particularly the headers only):
edd@rob:~$ cat deb/bh/debian/control
Source: r-cran-bh
Section: gnu-r
Priority: optional
Maintainer: Dirk Eddelbuett
301 - 400 of 15988 matches
Mail list logo
