Thank you both for quick thumbs-up! 1.7.7-1.2 was just shipped, fingers
crossed about how it'll do with the builders.
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
, 2021 5:42:33 PM GMT+01:00, Dirk Eddelbuettel
wrote:
| >Package: tiledb
| >Version: 1.7.7-1.1
| >Severity: normal
| >Tags: patch pending
| >
| >Dear maintainer,
| >
| >I have prepared an NMU for tiledb (versioned as 1.7.7-1.2) and
| >can uploaded it to DELAYED/10. Pleas
for a more minimal build, also remove sphinx
+ * debian/control: Remove Build-Depends: on hdfs
+ * debian/control: Set Standards-Version: 2.6.0
+
+ -- Dirk Eddelbuettel Wed, 29 Dec 2021 09:55:15 -0600
+
tiledb (1.7.7-1.1) unstable; urgency=medium
* Non-maintainer upload.
* Source-only upload
Package: r-cran-rsgcc
Severity: normal
rsgcc has been off CRAN for a while:
https://cran.r-project.org/web/packages/rsgcc/index.html
It would be nice if you could retire the package so that we can
also retire 'r-cran-gwidgetsrgtk2' which was also remove from CRAN
On 28 December 2021 at 17:44, Sebastiaan Couwenberg wrote:
| On 12/28/21 17:17, Dirk Eddelbuettel wrote:
| > | Your comments regarding builds suggests that tiledb isn't very stable
| > | yet, so even if the package get actively maintained, building on top of
| > | it may not be wise.
|
, but mostly
smaller ones) packages I know how much work it is. ]
On 28 December 2021 at 16:41, Sebastiaan Couwenberg wrote:
| On 12/28/21 15:39, Dirk Eddelbuettel wrote:
| > 4) TileDB 1.7.7 in Debian -- There is a packaging attempt of a more minimal
| > TileDB configuration in unstable, with a
Greetings,
As both a Debian'er and a TileDB employee, I had looked a few times into
packaging TileDB for Debian. The good news is that I currently have something
in my own informal PPA (see below) -- including rebuilds of the gdal and pdal
packages taken from ubuntugis-unstable.
Some related
Ezra,
[ A gentle plea: Can you please turn the encryption signing off when you
reply? Thank you, it really confuses one of the email programs I use. ]
What you state in passing is somewhere between misleading and just wrong,
likely due to a misunderstanding. Quoting from your email:
a
Hi Noah,
On 26 December 2021 at 20:18, Noah Meyerhans wrote:
| On Sun, Dec 26, 2021 at 06:08:56PM -0600, Dirk Eddelbuettel wrote:
| > I have a package that could take advantage of this if it were packaged, and
I
| > am sure a number of other packages are in a similar situation giv
Does anybody know where we are with respect to the WNPPs / ITPs / ... on the
Amazon SDK for C++?
I have a package that could take advantage of this if it were packaged, and I
am sure a number of other packages are in a similar situation given how
pervasive AWS use is. So does anybody know where
This bug now blocks resolution of #1002648 for the removal of r-cran-multicore.
It would be nice if you could adjust the (apparently also dead upstream)
package r-other-mott-happy to just rely on package 'parallel' which is
included in R.
Thanks, Dirk
--
https://dirk.eddelbuettel.com |
Package: ftp.debian.org
Severity: normal
The OmegaHat project was once (around 2000) aiming to write 'the next
R'. That never happend. But R Core member Duncan Temple Lang maintained a
repository for several years with a number of extension packages. But it
ceased to exist years ago and
Package: ftp.debian.org
Severity: normal
The 'multicore' package for R was an early extension (during 2009 to 2011) to
support process-parallel work. Its key parts (especially those that matter
for us on Linux) were replaced / rewritten many years ago by package
'parallel' which is a part of
Hi Nilesh,
On 26 December 2021 at 00:20, Nilesh Patra wrote:
| control: reassign -1 r-cran-tmb/1.7.22-1
|
| Hi Dirk,
|
| On Thu, 23 Dec 2021 14:30:10 -0600 Dirk Eddelbuettel wrote:
| > passfail
| > | rmatrixfrom testing1.4-0-1
|
Hi Nilesh,
On 26 December 2021 at 00:20, Nilesh Patra wrote:
| control: reassign -1 r-cran-tmb/1.7.22-1
|
| Hi Dirk,
|
| On Thu, 23 Dec 2021 14:30:10 -0600 Dirk Eddelbuettel wrote:
| > passfail
| > | rmatrixfrom testing1.4-0-1
|
On 23 December 2021 at 20:03, Paul Gevers wrote:
| Source: r-cran-tmb
| Version: 1.7.22-1
| Severity: serious
| X-Debbugs-CC: debian...@lists.debian.org, rmat...@packages.debian.org
| Tags: sid bookworm
| User: debian...@lists.debian.org
| Usertags: needs-update
| Control: affects -1 src:rmatrix
On 23 December 2021 at 20:03, Paul Gevers wrote:
| Source: r-cran-tmb
| Version: 1.7.22-1
| Severity: serious
| X-Debbugs-CC: debian...@lists.debian.org, rmat...@packages.debian.org
| Tags: sid bookworm
| User: debian...@lists.debian.org
| Usertags: needs-update
| Control: affects -1 src:rmatrix
Package: r-other-mott-happy.hbrem
Severity: normal
I am currently cleaning up a little and removing a handful of r-cran-*
packages that have vanished from CRAN years ago.
One of those is 'multicore' which was subsumed in package 'parallel' which is
part of base R.
Package
On 23 December 2021 at 11:07, Tomas Kalibera wrote:
| You can have a look at CRAN package Rblpapi which is using an external DLL.
Yes with one big caveat: You have to make sure the library follows what is
the "hour-glass pattern": it needs to have an internal (the "narrow" part) C
library
FYI, and as a follow-up, someone mentioned in a another thread
utils::file.edit() (see https://rdrr.io/r/utils/file.edit.html)
and the general rule still holds: "if it is generally useful, it probably
already is in base R" ...
Dirk
--
https://dirk.eddelbuettel.com | @eddelbuettel |
Package: ftp.debian.org
Severity: normal
The 'int64' package for R was one of two approaches to 'retro-fit' an int64_t
into R (which has a limited set of basetypes). It failed and as
https://cran.r-project.org/package=int64
was orphaned in 2012 and formally archived in 2013. We kept it
On 20 December 2021 at 11:25, David Winsemius wrote:
| Ran `update.packages()` again and found quite a few not-yet-updated
| packages, many of them fairly essential, but NOT in the directory you
| were worried about, but rather such as in '/usr/lib/R/site-library' and
| '/usr/lib/R/library'
On 20 December 2021 at 15:48, Sebastian Meyer wrote:
| Am 20.12.21 um 15:19 schrieb Dirk Eddelbuettel:
| >
| > On 19 December 2021 at 18:14, David Winsemius wrote:
| > | I initially attempted installation of pkg:MatrixExtra with
| > | `install.packages on my Ubuntu 18.04 LTS system
R 4.1.0 brought the native pipe and the related ability to use '=>' if one
opted into it by setting _R_USE_PIPEBIND_. I often forget about '=>' and
sadly can never find anything in the docs either (particularly no 'see als'
from '|>' docs) which is not all that heplful.
Can we anticipate a
On 19 December 2021 at 18:14, David Winsemius wrote:
| I initially attempted installation of pkg:MatrixExtra with
| `install.packages on my Ubuntu 18.04 LTS system from within RStudio. It
| failed with an error attempting to compile a function named "matmul.cpp"
| so I tried running R from a
retitle 1001892 RM: r-cran-hdf5 -- ROM: retired upstream twelve years ago
quit
Setting a better / correct title.
Dirk
On 18 December 2021 at 08:10, Dirk Eddelbuettel wrote:
|
| Package: ftp.debian.org
| Severity: normal
|
| Winthin the R system, hdf5 packages have a difficult history
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
--
701 - 800 of 15988 matches
Mail list logo
