Package: ftp.debian.org
Severity: normal
Winthin the R system, hdf5 packages have a difficult history. This package
was one of the earlier ones (earliest?) and was maintained from 2000 to
2009. I packaged it in 2005, and it has served us well. These days the
BioConductor package rhdf5 is a
On 17 December 2021 at 21:13, Patrice Kiener wrote:
| Thank you for your suggestions. Let's give more details. The idea is to
| insert the code in a function and then in a (private) package. We have
| to rely on the default editors provided by the OS to R and cannot invent
| a new editor, as
Patrice,
Also: if you are on a terminal, have you discovered tmux / byobu yet to
multiplex?
It is fairly magic as you can just open as many 'sessions with the outer
sessions', the sessions persist and many more advantages. I talked a little
about this (with short videos) last year
On 17 December 2021 at 18:48, Patrice Kiener wrote:
|
| With Debian and macOS, the default editor (getenv("EDITOR") or
| getOption("editor")) is "vi" which opens vi/vim. The following instruction:
|
|fileREP <- file.path(R.home("etc"), "repositories")
|system2(getOption("editor"),
On 17 December 2021 at 09:51, Simon Urbanek wrote:
| Sure, installed pandoc 2.16.2.
Perfect, thank you!
Dirk
| Cheers,
| Simon
|
|
| > On Dec 17, 2021, at 9:21 AM, Dirk Eddelbuettel wrote:
| >
| >
| > CRAN results flag NOTEs on the two platforms
| > r-release-macos
CRAN results flag NOTEs on the two platforms
r-release-macos-x86_64
r-oldrel-macos-x86_64
because `pandoc` is apparently missing. These platforms being somewhat
common, could pandoc be installed? Or are they running such a jurassic
version that no premade pandoc is available _anywhere_ ?
On 16 December 2021 at 06:38, Joseph Park wrote:
| As R itself has no practical limit, and, large, ugly parameter lists are
| sometimes unavoidable in API's, I respectfully request consideration to
| relax the limit as design and resources allow.
Please keep in mind that this project is provided
On 15 December 2021 at 12:30, Robert J. Hijmans wrote:
| Dirk thanks very much for the help. And sorry, Alex, I misspoke. I meant to
| say that Rcpp will coerce a R "numeric" (vector) to an
| "Rcpp::IntegerVector" if you ask it to do so (and that is what happened in
| the context we were
On 15 December 2021 at 20:10, Balamuta, James Joseph wrote:
| For those interested, the few other instances can be found by looking under
the inst/include/Rcpp/generated/ folder:
|
| https://github.com/RcppCore/Rcpp/tree/master/inst/include/Rcpp/generated
Yup, I mentioned the dir, but thanks
On 15 December 2021 at 10:19, Kevin Ushey wrote:
| I assume we're talking about Vector::create()? Anyone curious poking at it
| can start by looking here:
|
|
https://github.com/RcppCore/Rcpp/blob/940fb23868bf442e587994451e85263baa302d9c/inst/include/Rcpp/vector/Vector.h#L1122-L1126
There is
Joseph,
Sorry, can't quote your message as whatever you used confused my mail
handler. (Maybe try text-only next time if you remeber? I have had this
before, albeit very rarely.)
But it is a good idea. Someone with a bit of time should sit down and could do
this as we now have C++11 / C++14 as
--no-save --debugger=valgrind
| >>> --debugger-args="--track-origins=yes --vgdb=full --vgdb-error=0"
| >>> then in another window start a debugger process with
| >>> $ gdb RHOME/bin/exec/R
| >>> ...
| >>>(gdb) target remote | vgdb
|
retitle 996033 RM: its -- ROM: retired upstream five years ago
quit
Setting a better / correct title.
Dirk
On 18 November 2021 at 10:06, Dirk Eddelbuettel wrote:
|
| reassign 996033 ftp.debian.org
| quit
|
| I must have been absent-minded when I filed this as I got the Subject: right
On 13 December 2021 at 09:15, Bill Dunlap wrote:
| I ran your example under valgrind on Linux (Ubuntu 20.04)
Excellent call, as usual! Thanks for doing that.
R actually makes is so easy to run with valgrind by calling
R CMD check --use-valgrind somePkg_1.2-3.tar.gz
that I started to add
Hi Tobias,
Thanks for piping in!
On 13 December 2021 at 16:42, Tobias Hansen wrote:
| On 12/13/21 4:30 PM, Dirk Eddelbuettel wrote:
| > Hi Alexandre,
| >
| > On 13 December 2021 at 09:08, Alexandre Lymberopoulos wrote:
| > | Hi there, Dirk!
| > |
| > | I see that, libgslbl
On 13 December 2021 at 11:14, Alexander Ilich wrote:
| Hi, I'm upgrading one of my R packages to rely on the terra package instead
| of the raster package for the handling of spatial raster data. Previously
| when relying on the raster package I had to convert the data to a matrix
| and send it
ple email to the maintainer.
Cheers, Dirk
| Best, Alexandre
|
| On Dec 12 2021, Dirk Eddelbuettel wrote:
| >
| > PS As a follow-up, it also looks like the Debian aggregation pages think
| > everything should be fine:
| >
| > https://packages.debian.org/sid/libgslcblas0
| >
|
PS As a follow-up, it also looks like the Debian aggregation pages think
everything should be fine:
https://packages.debian.org/sid/libgslcblas0
Maybe you just has bad luck with a mirror, or hit a mirro sync?
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Salut Alexandre,
On 12 December 2021 at 14:47, Alexandre Lymberopoulos wrote:
| Package: libgsl25
| Version: 2.6+dfsg-2
| Severity: normal
|
| Dear Maintainer,
|
| Trying to upgrade all packages here, I see myself in a dependence
| conflict apparently without solution. Library libgsl25
On 8 December 2021 at 12:16, Sebastian Ramacher wrote:
| gsl now migrated and libgsl25 got removed from testing.
Fantastic! Thanks to you and to Patrick (CC'ed again) and we're back to where
we once were (GSL updates upstream, I can update without fuss or formal
transitions) but now we are
On 8 December 2021 at 12:16, Sebastian Ramacher wrote:
| gsl now migrated and libgsl25 got removed from testing.
Fantastic! Thanks to you and to Patrick (CC'ed again) and we're back to where
we once were (GSL updates upstream, I can update without fuss or formal
transitions) but now we are
On 8 December 2021 at 00:06, Simon Urbanek wrote:
| Hence it's much easier to ban a package than to hack it out of R ;).
Paging Achim for suggested `fortunes` inclusion.
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
Hi Mattia and Sebastian,
On 6 December 2021 at 22:44, Mattia Rizzolo wrote:
| Yes! See https://wiki.debian.org/BuildProfileSpec for the
| documentation.
|
| Unfortunately there have been a few troubles getting a formal and good
| specifical text that was "good enough" for the Debian Policy.
Hi Mattia and Sebastian,
On 6 December 2021 at 22:44, Mattia Rizzolo wrote:
| Yes! See https://wiki.debian.org/BuildProfileSpec for the
| documentation.
|
| Unfortunately there have been a few troubles getting a formal and good
| specifical text that was "good enough" for the Debian Policy.
Hi Sebastian,
On 6 December 2021 at 21:58, Sebastian Ramacher wrote:
| gsl needs another upload. It currently lists libgsl-prof as package that
| should be built, but it isn't. I've been told that in the past this has
| been worked around by manually changing the .dsc before uploading.
It has
Hi Sebastian,
On 6 December 2021 at 21:58, Sebastian Ramacher wrote:
| gsl needs another upload. It currently lists libgsl-prof as package that
| should be built, but it isn't. I've been told that in the past this has
| been worked around by manually changing the .dsc before uploading.
It has
On 5 December 2021 at 17:23, Travers Ching wrote:
| I see that there doesn't exist a Solaris flavor on any CRAN check page.
| However, I'm certain that Solaris was being checked up until very recently.
|
| Is this just temporary?
|
| Is there any information for the future of Solaris on CRAN?
On 3 December 2021 at 12:06, Kevin Ushey wrote:
| I'm a fan. I think we could just have a single header RcppLite.h which
| would turn off the "heaviest" pieces of Rcpp; that is, modules + sugar
| + (maybe?) RTTI.
Yep. That's where I started. I may make that a PR then.
But I also still lean to
On 3 December 2021 at 19:47, Iñaki Ucar wrote:
| Mmmh, no strong opinions here. I think it doesn't matter much whether
| it's an include or a define. What matters most is whether this is
| discoverable and the user understands what it does.
That was my motivation -- by pointing to such a
On 3 December 2021 at 17:03, Iñaki Ucar wrote:
| On Fri, 3 Dec 2021 at 15:44, Víthor Rosa wrote:
| >
| > Thank you for your response. Adding my functions to an R package and
changing the Makevars file as suggested reduced the runtime by half. Excited
for Rcpp 1.0.8! :)
|
| Excellent! Glad it
On 2 December 2021 at 15:57, Dirk Eddelbuettel wrote:
| Yep. It's in the queue by now. I sometimes forget if an experimental ->
| unstable passage does or does not need an orig.tar.gz to go along or not but
| the bots will tell me if so :)
And by now in unstable.
Thanks so much for look
On 2 December 2021 at 15:57, Dirk Eddelbuettel wrote:
| Yep. It's in the queue by now. I sometimes forget if an experimental ->
| unstable passage does or does not need an orig.tar.gz to go along or not but
| the bots will tell me if so :)
And by now in unstable.
Thanks so much for look
On 2 December 2021 at 22:39, Sebastian Ramacher wrote:
| On 2021-12-02 15:11:20, Dirk Eddelbuettel wrote:
| >
| > On 2 December 2021 at 20:55, Sebastian Ramacher wrote:
| > | gsl cleared NEW thanks to ta. So this should be good to go.
| > |
| > | Please go ahead with the upl
On 2 December 2021 at 22:39, Sebastian Ramacher wrote:
| On 2021-12-02 15:11:20, Dirk Eddelbuettel wrote:
| >
| > On 2 December 2021 at 20:55, Sebastian Ramacher wrote:
| > | gsl cleared NEW thanks to ta. So this should be good to go.
| > |
| > | Please go ahead with the upl
On 2 December 2021 at 17:48, Iñaki Ucar wrote:
| My simulation package makes heavy use of calls to R user functions from a
| C++ simulation loop, and therefore greatly benefits from this feature too,
| which I think we should promote to default.
I agree and believe I looked into it once before
On 2 December 2021 at 20:55, Sebastian Ramacher wrote:
| gsl cleared NEW thanks to ta. So this should be good to go.
|
| Please go ahead with the upload to unstable.
Will do. Without any other requirements, correct? I.e. standard upload which
thanks to Patrick's work will be around a new
On 2 December 2021 at 20:55, Sebastian Ramacher wrote:
| gsl cleared NEW thanks to ta. So this should be good to go.
|
| Please go ahead with the upload to unstable.
Will do. Without any other requirements, correct? I.e. standard upload which
thanks to Patrick's work will be around a new
On 1 December 2021 at 21:47, Patrick Alken wrote:
| Ok please send along the patches.
Sure thing. They are actually 'in the open' as we (== Debian devs) these days
have most / all work in git(-lab via our instance at salsa.debian.org). See
this directory and note that the 'series' file governs
On 1 December 2021 at 21:47, Patrick Alken wrote:
| Ok please send along the patches.
Sure thing. They are actually 'in the open' as we (== Debian devs) these days
have most / all work in git(-lab via our instance at salsa.debian.org). See
this directory and note that the 'series' file governs
On 1 December 2021 at 21:41, Sebastian Ramacher wrote:
| Indeed, it will need a trip through NEW. So going via experimental would
| be appreciated. But, once it passed NEW, you can then immediatly follow
| up with the upload to unstable. I will take care of the binNMUs of the
| reverse
On 1 December 2021 at 21:41, Sebastian Ramacher wrote:
| Indeed, it will need a trip through NEW. So going via experimental would
| be appreciated. But, once it passed NEW, you can then immediatly follow
| up with the upload to unstable. I will take care of the binNMUs of the
| reverse
On 1 December 2021 at 09:45, Sebastian Ramacher wrote:
| On 2021-11-30 22:43:11 -0700, Patrick Alken wrote:
| > All, I have uploaded a new GSL release (2.7.1) which I hope fixes the
| > libtool version numbers
Patrick,
Big big thank you! (And I missed this email yesterday)
| Thank you!
|
|
On 1 December 2021 at 09:45, Sebastian Ramacher wrote:
| On 2021-11-30 22:43:11 -0700, Patrick Alken wrote:
| > All, I have uploaded a new GSL release (2.7.1) which I hope fixes the
| > libtool version numbers
Patrick,
Big big thank you! (And I missed this email yesterday)
| Thank you!
|
|
Hi Witold,
On 26 November 2021 at 17:09, Witold E Wolski wrote:
| We have been using the package at work since 2018. We made some
| feature requests in 2019 to the maintainer and Author Amir B.K.
| Foroushani and was so kind to
| implement them for us and release a new version in 2019. But
Agreed. I have used `.pkgenv` in a few packages (digest, rpushbullet, ...),
and usually added a comment that it is package-global.
And so have a few others:
https://github.com/search?l=R=org%3Acran+pkgenv=Code
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
On 26 November 2021 at 14:40, Witold E Wolski wrote:
| I am submitting a package to CRAN and I am asked to fix 2 NOTE's
| I am not sure how I should ask the following NOTE?
|
|
| * this is package 'sigora' version '3.0.9'
| * checking CRAN incoming feasibility ... NOTE
| Maintainer: 'Witold
On 23 November 2021 at 12:19, Hervé Pagès wrote:
| But why would you need to check for anything in the first place?
|
| If you only use 2 cores in your examples, vignettes, and unit tests, 'R
| CMD check' will run fine everywhere and not eat all the CPU power of the
| machine where it's
This may be more of a question for r-package-devel than for r-devel.
On 23 November 2021 at 14:11, Dipterix Wang wrote:
| I recently received an email from Prof. Ripley. He pointed out that my
package seriously violates the CRAN policy: "using 8 threads is a serious
violation of the CRAN
On 22 November 2021 at 09:08, Patrick Alken wrote:
| Hi all, sorry for all this trouble. I will try to make a new GSL release
| with the correct numbers.
Much appreciate it!
Sebastian, we'll then run a new transition with gsl 2.8 (or whichever version
number it will be) and its new somajor.
On 22 November 2021 at 09:08, Patrick Alken wrote:
| Hi all, sorry for all this trouble. I will try to make a new GSL release
| with the correct numbers.
Much appreciate it!
Sebastian, we'll then run a new transition with gsl 2.8 (or whichever version
number it will be) and its new somajor.
Hi Patrick,
Can you please chime in (as you did in the earlier exchanges when Sebastian
explained to us how to set valus triplet for libtool via configure.ac) ?
On 21 November 2021 at 23:00, Sebastian Ramacher wrote:
| On 2021-11-09 12:54:44 -0600, Dirk Eddelbuettel wrote:
| >
| >
Hi Patrick,
Can you please chime in (as you did in the earlier exchanges when Sebastian
explained to us how to set valus triplet for libtool via configure.ac) ?
On 21 November 2021 at 23:00, Sebastian Ramacher wrote:
| On 2021-11-09 12:54:44 -0600, Dirk Eddelbuettel wrote:
| >
| >
reassign 996033 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
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
701 - 800 of 15962 matches
Mail list logo
