reassign ftp.debian.org
quit
I must have been absent-minded when I filed this as I got the Subject: right
but use the package itself instead of ftp.debian.org. My bad!
Dirk
On 10 October 2021 at 12:04, Dirk Eddelbuettel wrote:
|
| Severity: normal
| Package: its
|
| The its package
On 16 November 2021 at 12:08, bodo riediger-klaus wrote:
| Hello,
|
| i get a key-expired message when i try to update my repository
|
| root@merlot:/etc/apt/sources.list.d# cat rbase-stable.list
| deb http://ftp.gwdg.de/pub/misc/cran/bin/linux/debian buster-cran40/
|
|
| W: GPG-Fehler:
On 9 November 2021 at 22:28, Lucas Nussbaum wrote:
| Source: beancounter
| Version: 0.8.10
| Severity: important
| Justification: Debian Policy section 4.9
| Tags: bookworm sid
| User: debian...@lists.debian.org
| Usertags: missing-build-arch-indep
|
| Dear maintainer,
|
| Your package does
On 8 November 2021 at 22:14, Sebastian Ramacher wrote:
| Control: tags -1 moreinfo
| Control: forwarded -1
https://release.debian.org/transitions/html/auto-gsl.html
|
| On 2021-10-31 14:29:40 -0500, Dirk Eddelbuettel wrote:
| >
| > Package: release.debian.org
| > Severity: normal
On 8 November 2021 at 22:14, Sebastian Ramacher wrote:
| Control: tags -1 moreinfo
| Control: forwarded -1
https://release.debian.org/transitions/html/auto-gsl.html
|
| On 2021-10-31 14:29:40 -0500, Dirk Eddelbuettel wrote:
| >
| > Package: release.debian.org
| > Severity: normal
Simon,
Your Makevars [1] is very standard so I would suspect it may be the actions
setup for macOS. Rcpp is still used by a large number of packages all of
which appear to build just fine on macOS (as eg evidenced by the CRAN checks)
if and when everything is setup correctly.
Dirk
[1]
On 2 November 2021 at 16:09, Andrea Pappacoda wrote:
| Control: close -1
|
| Thanks for your fast response.
|
| As you might have guessed I'm not really experienced in Debian
| packaging, and I didn't know this was acceptable.
|
| I have no complaints then, I'm closing this :)
|
| Thanks
On 2 November 2021 at 15:43, Andrea Pappacoda wrote:
| Source: r-cran-tzdb
| Severity: normal
|
| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA256
|
| Dear Maintainer,
|
| I'm currently working to package the "date" library from Howard Hinnant, you
| can see the ITP here:
On 1 November 2021 at 12:38, Andreas Beckmann wrote:
| Source: gsl-doc
| Version: 2.6-1
| Severity: serious
| Tags: ftbfs sid bookworm
| Justification: fails to build from source
|
| Hi,
|
| gsl-doc cannot be built any longer in sid:
|
| Latexmk: applying rule 'pdflatex'...
| This is pdfTeX,
On 1 November 2021 at 12:38, Andreas Beckmann wrote:
| Source: gsl-doc
| Version: 2.6-1
| Severity: serious
| Tags: ftbfs sid bookworm
| Justification: fails to build from source
|
| Hi,
|
| gsl-doc cannot be built any longer in sid:
|
| Latexmk: applying rule 'pdflatex'...
| This is pdfTeX,
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
GNU GSL 2.7 was release a few months ago, and we now realised (in the
discussion of #993324 which also included upstream) that the upstream libtool
instruction were in error by _not_
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
GNU GSL 2.7 was release a few months ago, and we now realised (in the
discussion of #993324 which also included upstream) that the upstream libtool
instruction were in error by _not_
If anybody has a hypothesis of what could be causing the lock, I would
be game to trying different kernel builds (or parameterizations). So
far I mostly glad I can run the machine again, even if it needs a 4.*
kernel.
Otherwise, is there a particular crash I could enable to diagnose? The
If anybody has a hypothesis of what could be causing the lock, I would
be game to trying different kernel builds (or parameterizations). So
far I mostly glad I can run the machine again, even if it needs a 4.*
kernel.
Otherwise, is there a particular crash I could enable to diagnose? The
On 29 October 2021 at 18:14, Paul Wise wrote:
| Package: sm, libfreetype6
| Version: 0.26-1, 2.11.0+dfsg-1
| Severity: important
| File: /usr/games/sm
| Usertags: regression
Maintainer of _source package_ sm here: bad habit, 15 years ago binary
packages like r-cran-sm used their upstream source
Public bug reported:
This issue appeared first under 21.04, and I (wrongly) suspected a bug
in the window manager or graphics stack. I posted on askubuntu at
https://askubuntu.com/questions/1346317/ubuntu-21-04-and-21-10-lock-
hard-with-basic-gui-redrawing-using-standard-intel-g
and even
Public bug reported:
This issue appeared first under 21.04, and I (wrongly) suspected a bug
in the window manager or graphics stack. I posted on askubuntu at
https://askubuntu.com/questions/1346317/ubuntu-21-04-and-21-10-lock-
hard-with-basic-gui-redrawing-using-standard-intel-g
and even
On 24 October 2021 at 11:38, Sebastian Ramacher wrote:
| On 2021-10-23 19:44:49 -0500, Dirk Eddelbuettel wrote:
| >
| > I have now 'patched' the upstream setting of GSL_AGE, this results (as
kindly
| > analysed by Sebastian) in new sonames '26' so I prepared a new version which
| &g
On 24 October 2021 at 11:38, Sebastian Ramacher wrote:
| On 2021-10-23 19:44:49 -0500, Dirk Eddelbuettel wrote:
| >
| > I have now 'patched' the upstream setting of GSL_AGE, this results (as
kindly
| > analysed by Sebastian) in new sonames '26' so I prepared a new version which
| &g
I have now 'patched' the upstream setting of GSL_AGE, this results (as kindly
analysed by Sebastian) in new sonames '26' so I prepared a new version which
just went out to unstable.
Unless I am mistaken, I need to get the release team on board for a proper
transition. Correct?
Dirk
--
I have now 'patched' the upstream setting of GSL_AGE, this results (as kindly
analysed by Sebastian) in new sonames '26' so I prepared a new version which
just went out to unstable.
Unless I am mistaken, I need to get the release team on board for a proper
transition. Correct?
Dirk
--
On 20 October 2021 at 09:31, Sebastian Meyer wrote:
| If you set the environment variable inside a running R process, it will
| only affect that process and child processes, but not an independent R
| process launched from a shell like you seem to be doing here:
Yes. That is somewhat common,
On 16 October 2021 at 17:50, Sebastian Ramacher wrote:
| On 2021-10-15 13:54:07 -0500, Dirk Eddelbuettel wrote:
| >
| > On 15 October 2021 at 20:35, Sebastian Ramacher wrote:
| > | On 2021-10-15 10:38:48 -0500, Dirk Eddelbuettel wrote:
| > | >
| > | > Turns out this was fu
On 16 October 2021 at 17:50, Sebastian Ramacher wrote:
| On 2021-10-15 13:54:07 -0500, Dirk Eddelbuettel wrote:
| >
| > On 15 October 2021 at 20:35, Sebastian Ramacher wrote:
| > | On 2021-10-15 10:38:48 -0500, Dirk Eddelbuettel wrote:
| > | >
| > | > Turns out this was fu
On 15 October 2021 at 20:35, Sebastian Ramacher wrote:
| On 2021-10-15 10:38:48 -0500, Dirk Eddelbuettel wrote:
| >
| > Turns out this was fully my fault. The 2.7 release sets the SO number to 26,
| > and I didn't use that.
|
| No, it doesn't. gsl 2.7 has current=26 and age=1
On 15 October 2021 at 20:35, Sebastian Ramacher wrote:
| On 2021-10-15 10:38:48 -0500, Dirk Eddelbuettel wrote:
| >
| > Turns out this was fully my fault. The 2.7 release sets the SO number to 26,
| > and I didn't use that.
|
| No, it doesn't. gsl 2.7 has current=26 and age=1
Turns out this was fully my fault. The 2.7 release sets the SO number to 26,
and I didn't use that.
So a new package will be forthcoming, and likely need a transition. That
means I should upload to experimental first, right, to then request the
transition? (I'll read up on it later today as a
Turns out this was fully my fault. The 2.7 release sets the SO number to 26,
and I didn't use that.
So a new package will be forthcoming, and likely need a transition. That
means I should upload to experimental first, right, to then request the
transition? (I'll read up on it later today as a
Graham,
On 15 October 2021 at 13:34, Graham Inggs wrote:
| > Yes. And I follow upstream. They didn't change :-/
|
| Right, so please speak to your upstream. Dropping (or renaming) a
Done.
Looks like a 2.8 release is coming, so maybe the soname gets cleaned up there
and we get to do (yet
Graham,
On 15 October 2021 at 13:34, Graham Inggs wrote:
| > Yes. And I follow upstream. They didn't change :-/
|
| Right, so please speak to your upstream. Dropping (or renaming) a
Done.
Looks like a 2.8 release is coming, so maybe the soname gets cleaned up there
and we get to do (yet
On 14 October 2021 at 23:20, Sebastian Ramacher wrote:
| On 2021-10-14 15:52:03 -0500, Dirk Eddelbuettel wrote:
| >
| > Hi Sebastian,
| >
| > On 14 October 2021 at 22:46, Sebastian Ramacher wrote:
| > | Hi Dirk
| > |
| > | On 2021-08-30 16:27:49 -0500, Di
On 14 October 2021 at 23:20, Sebastian Ramacher wrote:
| On 2021-10-14 15:52:03 -0500, Dirk Eddelbuettel wrote:
| >
| > Hi Sebastian,
| >
| > On 14 October 2021 at 22:46, Sebastian Ramacher wrote:
| > | Hi Dirk
| > |
| > | On 2021-08-30 16:27:49 -0500, Di
Hi Sebastian,
On 14 October 2021 at 22:46, Sebastian Ramacher wrote:
| Hi Dirk
|
| On 2021-08-30 16:27:49 -0500, Dirk Eddelbuettel wrote:
| >
| > On 30 August 2021 at 23:42, Niko Tyni wrote:
| > | Package: libgsl25
| > | Version: 2.7+dfsg-2
| > | Control: affects -1 l
Hi Sebastian,
On 14 October 2021 at 22:46, Sebastian Ramacher wrote:
| Hi Dirk
|
| On 2021-08-30 16:27:49 -0500, Dirk Eddelbuettel wrote:
| >
| > On 30 August 2021 at 23:42, Niko Tyni wrote:
| > | Package: libgsl25
| > | Version: 2.7+dfsg-2
| > | Control: affects -1 l
On 14 October 2021 at 10:55, Paul Gevers wrote:
| Source: gsl
| Version: 2.6+dfsg-2
| Severity: serious
| Control: close -1 2.7+dfsg-2
| Tags: sid bookworm
| User: release.debian@packages.debian.org
| Usertags: out-of-sync
|
| Dear maintainer(s),
|
| The Release Team considers packages
On 14 October 2021 at 10:55, Paul Gevers wrote:
| Source: gsl
| Version: 2.6+dfsg-2
| Severity: serious
| Control: close -1 2.7+dfsg-2
| Tags: sid bookworm
| User: release.debian@packages.debian.org
| Usertags: out-of-sync
|
| Dear maintainer(s),
|
| The Release Team considers packages
Severity: normal
Package: its
The its package was retired from CRAN five years ago [1] upon the request of
its original author (who is a friend), but I kept it in Debian because it was
generally useful. However, as time and packaging standards move on (while the
package remains frozen) it is
On 9 October 2021 at 12:08, Ben Bolker wrote:
|FWIW there is some machinery in the glmmTMB package for querying,
| setting, etc. the number of OpenMP threads.
|
| https://github.com/glmmTMB/glmmTMB/search?q=omp
https://cloud.r-project.org/package=RhpcBLASctl
Dirk
--
A new r-cran-rgtk2 build has been uploaded which no longer builds on s390x by
default, so closing the bug report.
If someone from the s390 team wants to try just add the arch to the
Architecture line in debian/control.
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Howdy,
Somone (on r-help which I don't really follow for lack of time) called [3]
this a 'quasi-FAQ':
This problem is pratically a StackOverflow FAQ [1], with link to the
Rcpp-devel mailing list [2].
[1]
On 22 September 2021 at 15:15, Lionel Henry wrote:
| We'd love to do a release but ESS is not in a good place right now.
| Recent versions of Emacs interrupt background commands (essential to
| completion and contextual help like eldoc) when the user starts
| typing, which causes hard to solve
On 20 September 2021 at 13:59, Sparapani, Rodney via ESS-help wrote:
| Generally, this stuff should just work out-of-the-box.
Understood.
| And we are not a company like RStudio so this FOSS setup works for us as
| developers and hopefully it still serves the users well.
But legal structure
On 20 September 2021 at 13:59, Sparapani, Rodney via ESS-help wrote:
| Over the last few years, we have moved away from having to set up features
| with .emacs/etc. as much as possible. Generally, this stuff should just
| work out-of-the-box.
I completely concur and _love it_.
I mostly just
On 20 September 2021 at 07:50, Andreas Tille wrote:
| On Sun, Sep 19, 2021 at 03:45:57PM -0500, Dirk Eddelbuettel wrote:
| >
| > | I'm thinking about a "fake-basilisk" like r-cran-bh or r-bioc-zlib.
| >
| > I had a similar thought. I am also f
On 20 September 2021 at 07:50, Andreas Tille wrote:
| On Sun, Sep 19, 2021 at 03:45:57PM -0500, Dirk Eddelbuettel wrote:
| >
| > | I'm thinking about a "fake-basilisk" like r-cran-bh or r-bioc-zlib.
| >
| > I had a similar thought. I am also f
On 19 September 2021 at 16:09, Andreas Tille wrote:
| On Sun, Sep 19, 2021 at 05:31:14PM +0530, Nilesh Patra wrote:
| >
| > But I do wonder if more packages in future might as well end up needing
basilisk too.
|
| I'm thinking about a "fake-basilisk" like r-cran-bh or r-bioc-zlib.
I had a
On 19 September 2021 at 16:09, Andreas Tille wrote:
| On Sun, Sep 19, 2021 at 05:31:14PM +0530, Nilesh Patra wrote:
| >
| > But I do wonder if more packages in future might as well end up needing
basilisk too.
|
| I'm thinking about a "fake-basilisk" like r-cran-bh or r-bioc-zlib.
I had a
Chris,
I don't have great advice.
I have been doing this in Emacs with ESS (and friends like polymode) 'for
years' and it mostly worked. So thumbs up -- it worth doing and I prefer
doing it in Emacs. Polymode is actually rather cool.
The world being what it is these days, the predictable
Hi Philipp, Hi Simon,
If we have no resolution on this I will have no other way than to re-upload
r-cran-rgtk2 with a build exclusion for s390 as I now have an autoremoval
notice for it (and another package I look after than depends on it).
Or do we have other/better options?
Dirk
--
Hi Philipp, Hi Simon,
If we have no resolution on this I will have no other way than to re-upload
r-cran-rgtk2 with a build exclusion for s390 as I now have an autoremoval
notice for it (and another package I look after than depends on it).
Or do we have other/better options?
Dirk
--
Hi Philipp, Hi Simon,
If we have no resolution on this I will have no other way than to re-upload
r-cran-rgtk2 with a build exclusion for s390 as I now have an autoremoval
notice for it (and another package I look after than depends on it).
Or do we have other/better options?
Dirk
--
On 6 September 2021 at 09:39, Simon McVittie wrote:
| On Sun, 05 Sep 2021 at 20:04:55 -0500, Dirk Eddelbuettel wrote:
| > Please explain what a smoke-test failure is.
|
| Sorry, I thought this was a common term.
|
| A smoke-test for hardware: plug in the device and see whether smoke
| co
On 6 September 2021 at 09:39, Simon McVittie wrote:
| On Sun, 05 Sep 2021 at 20:04:55 -0500, Dirk Eddelbuettel wrote:
| > Please explain what a smoke-test failure is.
|
| Sorry, I thought this was a common term.
|
| A smoke-test for hardware: plug in the device and see whether smoke
| co
On 6 September 2021 at 09:39, Simon McVittie wrote:
| On Sun, 05 Sep 2021 at 20:04:55 -0500, Dirk Eddelbuettel wrote:
| > Please explain what a smoke-test failure is.
|
| Sorry, I thought this was a common term.
|
| A smoke-test for hardware: plug in the device and see whether smoke
| co
Also: No other R packages here. Maybe something off with gtk2?
Build-Depends: debhelper (>= 10), dh-r (>= 20180615), \
r-base-dev (>= 3.6.1), libgtk2.0-dev (>= 2.10.12), \
libglade2-dev, libpango1.0-dev, libcairo2-dev
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel |
Also: No other R packages here. Maybe something off with gtk2?
Build-Depends: debhelper (>= 10), dh-r (>= 20180615), \
r-base-dev (>= 3.6.1), libgtk2.0-dev (>= 2.10.12), \
libglade2-dev, libpango1.0-dev, libcairo2-dev
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel |
On 6 September 2021 at 00:46, Simon McVittie wrote:
| Source: rgtk2
| Version: 2.20.36-2
| Severity: serious
| Tags: ftbfs bookworm sid
| Justification: fails to build from source (but built successfully in the past)
| X-Debbugs-Cc: debian-s...@lists.debian.org
| User:
On 6 September 2021 at 00:46, Simon McVittie wrote:
| Source: rgtk2
| Version: 2.20.36-2
| Severity: serious
| Tags: ftbfs bookworm sid
| Justification: fails to build from source (but built successfully in the past)
| X-Debbugs-Cc: debian-s...@lists.debian.org
| User:
Rolf,
Glad you're sorted out, and I concur in the thanks to Ivan (and Johannes and
other who patiently helped).
To me, the take-away message is that /usr/local wins generally, not just in
your $PATH (or, say, in R's library path) but also for configure and friends
so ... it opens the door for
On 31 August 2021 at 15:36, Andreas Tille wrote:
| I think cheating with different Debian versions is one thing but IMHO
| the versions inside the package (I mean Debian package version and the
| version inside DESCRIPTION) should match no matter what actual libboost
| version is in Debian.
s
(reply to Dirk Eddelbuettel ).
| [...]
| > -BEGIN PGP SIGNED MESSAGE-
| > Hash: SHA256
| >
| > Format: 1.8
| > Date: Tue, 31 Aug 2021 06:40:29 -0500
| > Source: r-cran-bh
| > Architecture: source
| > Version: 1.74.0-2
| > Distribution: unstable
| > Urgency: mediu
-12
| Author: Dirk Eddelbuettel, John W. Emerson and Michael J. Kane
| Maintainer: Dirk Eddelbuettel
| --- a/debian/control
| +++ b/debian/control
| @@ -11,7 +11,7 @@ Homepage: https://cran.r-project.org/package=BH
| Package: r-cran-bh
| Architecture: all
| Multi-Arch: foreign
| -Depe
On 30 August 2021 at 23:42, Niko Tyni wrote:
| Package: libgsl25
| Version: 2.7+dfsg-2
| Control: affects -1 libmath-gsl-perl
| Severity: serious
|
| gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest
regressions:
|
|not ok 7 - use Math::GSL::Matrix;
|
|#
On 30 August 2021 at 23:42, Niko Tyni wrote:
| Package: libgsl25
| Version: 2.7+dfsg-2
| Control: affects -1 libmath-gsl-perl
| Severity: serious
|
| gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest
regressions:
|
|not ok 7 - use Math::GSL::Matrix;
|
|#
On 29 August 2021 at 08:06, Michael Mahoney wrote:
| Forgive me if I'm missing something here, but do you need to install
| from source or do you just need R 4.1.0?
|
| If the latter, my understanding is that you should be able to get R
| version 4.1.0 on Ubuntu distributions via:
An even
Rolf,
I am truly sorry but I am getting lost in your original message. Could you
follow-up and describe (concisely, if possible) what your question is? Is it
- installing 4.1.1 or 4.1.0
- developing a package of yours
- installing a package ?
You seem to interweave a few strands in ways
Rolf,
Asking here is the Right Thing (TM) but I am in at this moment between two
differen things (one of them being dinner...) so I have to come back to this
but regarding
> Package libcurl-dev is a virtual package provided by:
> libcurl4-openssl-dev 7.68.0-1ubuntu2.6
> libcurl4-nss-dev
On 27 August 2021 at 20:48, William Denton via ESS-help wrote:
| Let's say I enter the following keystrokes:
|
| 1 + 1 RET M-p C-a
|
| This adds 1+1, gets the result, then runs comint-previous-input and reenters
the
| previous command. C-a moves to the start of the line ... but puts the
While we generally get an email about these things, CRAN appears to have
closed shop for a week to take a well deserved break until September 1.
Or so the message says---the hourly CRANberriesFeed cron job saw packages
being processed, but that too is not uncommon when the queues get cleared.
As I type this, we are eight messages into this thread -- but I am not sure
it has been made clear what the actual contentious issues are.
There appear to be two toolchains, and they appear to be interoperate (though
Duncan stated he had issues with an (arguably demanding) package). Now, I
On 19 August 2021 at 10:04, Naeem Khoshnevis wrote:
| Thank you so much, everyone, for responding to this email.
Thanks for circling back! This was a pretty impressive thread as you got
three distinct answers that all added some value :)
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel
Naeem,
I would simplify, simplify, simplify -- as 'Rcpp FAQ 7.31' reminds us all,
testing _equality_ of doubles is challenging anyway.
Besides, it may make sense to would ascertain first you get what you want in
_purely serial modes_ and then move to OpenMP.
Dirk
--
On 18 August 2021 at 16:36, Simon Zehnder wrote:
| I am using R 4.0.5 on a Fedora 34 System, Rcpp 1.0.6 and nloptr 1.2.2.2.
Works here (Ubuntu 21.04, Rcpp 1.0.7) (see [1] below)
Works at CRAN (see [2] below)
Works at universe (see [3] below)
I would suspect the error is at your end.
Dirk
On 18 August 2021 at 01:26, Dillon Hammill wrote:
| Thanks for your help Dirk, I think I have everything I need to get things
working now. I just needed a push in the right direction to discover wrap and
as from Rcpp - they are awesome!
They are indeed. (And, if I may, feature prominently in
On 17 August 2021 at 19:19, Dillon Hammill wrote:
| What is the easiest way to perform this conversion (say for vector to RVector
or vector of vectors to matrix)?
I always find that the existing RcppParallel that JJ and Kevin set up years
ago excels there. Study them, they do it right, they
Dillon,
The point of RMatrix and RVector in RcppParallel is to shield objects inside
the RcppParallel blocks using Intel TBB from any interaction with the outer R
process which may, or may not, run a gc() to rearrange its memory.
Where they work, you should not use Rcpp's own NumericMatrix and
Dario,
On 14 August 2021 at 00:00, Dario Strbenac via R-devel wrote:
| Good day,
|
| Ah, I was confident it wouldn't be environment-specific but it is. My
environment is
|
| R version 4.1.0 (2021-05-18)
| Platform: x86_64-pc-linux-gnu (64-bit)
| Running under: Debian GNU/Linux 10 (buster)
|
On 12 August 2021 at 15:19, Andrew Piskorski wrote:
| Ok, but what's the recommended way to actually USE Rprofile.site now?
| Should I move all my local configuration into a special package, and
| do nothing in Rprofile.site except require() that package?
Exactly as before. I set my mirror as I
(I replied earlier but that seems to have gotten lost. Apologies to anybody
who may receive two copies, and thanks to Simon for his answer. -- Dirk)
On 9 August 2021 at 17:04, Naeem Khoshnevis wrote:
| Do you know a workaround for this issue?
Wrap the #include by #ifdef _OPENMP and #endif
Rolf,
Sorry for only briefly chiming in, and late, but I don't usually follow
r-help that much these days.
I am writing this from an Ubuntu machine running R as well as RStudio from
pre-made binary .deb packages. R comes via apt from CRAN (using Michael's
binaries), RStudio from them via
If look closely enough at _Writing R Extensions_ you notice that it mentions
'configure.win' over half a dozen times. A powerful trick is to then use the
fact that there are other packages on CRAN, in fact almost 18k of them.
And e.g. this search
On 3 August 2021 at 09:35, Enrico Schumann wrote:
| More wild guesses:
|
| - maybe some Emacs minor mode does it? Any
| configuration for gtags-mode?
I use it (via elpa).
But I grep'ed and an ag'ed at length for anything related.
| - do you happen to use an Emacs package named ggtags
|
On 2 August 2021 at 21:20, Tyler Smith via ESS-help wrote:
| Can you reproduce the problem after starting Emacs via `emacs -Q`? That would
confirm the problem is not in your Emacs config. Or confirm that it is, if the
problem isn't reproduced.
Can confirm. With emacs -Q nothing happens to
On 2 August 2021 at 17:20, Dirk Eddelbuettel via ESS-help wrote:
|
| On 2 August 2021 at 23:56, Stephen Berman wrote:
| | Did you also try the more direct alternative of grepping simply for
| | "GPATH", "GTAGS", "GRTAGS"? Presumably whatever function update
On 2 August 2021 at 23:56, Stephen Berman wrote:
| Did you also try the more direct alternative of grepping simply for
| "GPATH", "GTAGS", "GRTAGS"? Presumably whatever function updates these
| files has to refer to them, either directly by name or indirectly by a
| variable or function that in
Package: wnpp
Owner: Dirk Eddelbuettel
Severity: wishlist
* Package name: r-cran-vroom
Version : 1.5.3
Upstream Author : James Hester and Hadley Wickham
* URL or Web page : https://cran.r-project.org/package=vroom
* License : MIT
Description : GNU R package
Package: wnpp
Owner: Dirk Eddelbuettel
Severity: wishlist
* Package name: r-cran-vroom
Version : 1.5.3
Upstream Author : James Hester and Hadley Wickham
* URL or Web page : https://cran.r-project.org/package=vroom
* License : MIT
Description : GNU R package
On 30 July 2021 at 21:32, Andreas Leha via ESS-help wrote:
| wild guess: file/dir local variable?
I considered that too esp as I see it only in some repos. But no repo-local
file I can see or tell (and I know repo layout / files well enough).
On 30 July 2021 at 17:27, Tyler Smith via ESS-help
Section 2.7.3 'C++ Support' of the R Admin manual says, "C++ is not used by R
itself, but support is provided ...". This is all stored from when R itself
is configure (prior to compiling) and override-able in package configuration
(Section 2.7.3 covers that) but as that in other places _it all
tl;dr: I enabled an action 'on save' and I no longer find where :-/
Longer story: I settled upon GNU global and ggtags at some point for a
(mostly multilingual) system of tags in R and C++ (and some more). So a few
of source directories have these (ugly names) files GPATH, GTAGS, GRTAGS.
And
Package: wnpp
Owner: Dirk Eddelbuettel
Severity: wishlist
* Package name: r-cran-tzdb
Version : 0.1.2
Upstream Author : Davis Vaughan
* URL or Web page : https://cran.r-project.org/package=tzdb
* License : MIT
Description : GNU R package for Time Zone Database
Package: wnpp
Owner: Dirk Eddelbuettel
Severity: wishlist
* Package name: r-cran-tzdb
Version : 0.1.2
Upstream Author : Davis Vaughan
* URL or Web page : https://cran.r-project.org/package=tzdb
* License : MIT
Description : GNU R package for Time Zone Database
On 24 July 2021 at 15:53, Steve Haroz wrote:
| I'd like to propose moving the default library install location on Windows
from:
| %USERPROFILE%/Documents/R
| to some other location such as:
| %USERPROFILE%/R
Can you not set .Library.site in R_HOME/etc/Rprofile.site (or maybe setting
Russell,
On 24 July 2021 at 12:04, Russell Almond wrote:
| I'm working on a package called RNetica which links to a 3rd party
| library: Netica. Netica is available in both static (libnetica.a) and
| shared (libnetica.so) version (also Netica.dll for windows, but that is
| a separate
Luben,
Adding to what Tyler kindly said:
On 23 July 2021 at 19:35, Tyler Smith wrote:
| libcurl and libcurl4-openssl-dev are Debian packages, not R packages. You can
install them from the command line (not R):
|
| sudo apt-get install libcurl4-openssl-dev
|
| Or use your package manager.
ter system / what is known in the _entire distribution_
which is very different from the build-a-package clean room.
| Package: r-cran-dbi
| Source: dbi
| Version: 1.0.0-2
| Installed-Size: 1931
| Maintainer: Dirk Eddelbuettel
| Architecture: all
| Depends: r-base-core (>= 3.5.0-3), r-api-3.5
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 Gennadiy,
On 20 July 2021 at 10:25, Gennadiy Starostin wrote:
| Thank you for your feedback. There was a misconfigured redirection
| indeed. It should work well now.
Fabulous, thanks as always.
| The top page does say "If you experience any problems or need help you
| can submit a
(Sorry for posting here but the top-level r-forge page does not make it all
that clear where to contact its admins.)
When an old-style 'http' URL at r-forge is resolved / redirected to 'https',
it is corrupted and the redirect breaks. That required a package re-upload
for me a few days ago (as
801 - 900 of 16009 matches
Mail list logo
