Bug#1072036: release.debian.org: Transition for gsl-2.8 / libgsl28
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition GNU GSL 2.8 was released a few days ago, and I uploaded a new version to experimental was has now cleared NEW. I checked my email folder, and the last time this happened (gsl 2.7, early 2021) we attempted an automatic transition but some things got in the way it seems. Help from Graham (CC'ed) was invaluable then, I am easy either way: a formal or automatic transition works for me, so please advise as to what you preferred course of action is. The package has a fair number of reverse dependencies but rebuilds "should" work cleanly. Tentative ben file below. - title = "gsl 2.8 transition"; is_affected = .depends ~ /libgsl-dev/; is_good = .depends ~ "libgsl28"; is_bad = .depends ~ "libgsl27"; - Let me know if I can help otherwise. Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: R 4.4.0 coming April 24
On 21 April 2024 at 15:25, Sebastiaan Couwenberg wrote: | On 4/21/24 3:04 PM, Dirk Eddelbuettel wrote: | > R upstream no longer releases or tests for 32 bits (and has not since the R | > 4.3.0 release a year ago) so 'expect trouble there'. I think you all in the | > release team may need to override this to unblock. | | Wouldn't it be better then to add architecture-is-64-bit to the r-base | build dependencies to prevent it from building on 32bit architectures | and then file partial RM bugreports for r-base and its rdeps to get them | removed from the 32bit architectures? Yes!! I actually grep'ed among all my (100+) packages but did not see an example. I may be missing the best way to do this: so is this (new to me) 'architecture-is-64-bit' the way to do it? A quick 'apt-cache search' leads me to 'architecture-properties'. I would be in favor. So thanks for the suggestion! Are there concerns or side effects or our desire to build for as many platforms as possible etc? Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: R 4.4.0 coming April 24
Hi Graham, Hi Release Team, On 21 April 2024 at 13:37, Graham Inggs wrote: | On Thu, 18 Apr 2024 at 13:38, Dirk Eddelbuettel wrote: | > Right now it now only shows 'all reports (re-)running'. | | That was because of the new upload, but I see the results there now. | | The packages with failing autopkgtests are: | | r-bioc-iranges/2.36.0-1 | r-bioc-mutationalpatterns/3.12.0+dfsg-1 | r-bioc-s4vectors/0.40.2+dfsg-1 | r-cran-data.table/1.14.10+dfsg-1 | r-cran-ff/4.0.12+ds-1 I checked these five just now: four of them are current so I may have to leave this with their maintainer. But r-cran-data.table is quite badly behind (the once again very active upstream) and the current release is 1.15.4. I use package a lot myself and keep an eye out on their upstream work, there were some minor CRAN required updates so an update could cure that for us too. And given how widely data.table is used (i.e. by r-bioc-s4vectors which itself is used by r-bioc-iranges and r-bioc-mutationalpatterns) we quite possibly have one package causing four hickups. | > But package r-base | > has had the usual issues in unstable for a few weeks now because 'some | > people' insist on adding autopkg tests including for architectures / build | > sizes no longer supported upstream -- R stopped 32 bit support over a year | > and release ago | | For the pseudo-excuses in experimental only amd64 and arm64 are | tested, no 32-bit architectures. Ah. I expect more skirmish then. R upstream no longer releases or tests for 32 bits (and has not since the R 4.3.0 release a year ago) so 'expect trouble there'. I think you all in the release team may need to override this to unblock. R 4.4.0 itself is fine. I decided to also eat my own dogfood and sent the same package I sent to experimental to launchpad for Ubuntu 23.10 (my daily driver here), and I am running it now for a over a day. "Everything works", I have hourly cronjobs for R too and there is no issue. So I plan to proceed with R 4.4.0. | > -- as well continually letting dependencies slip so that the | > autopkg tests involve old and outdated package releases combined with the | > fact that BioConductor has _very_ specific release cycles yet they throw | > r-bioc-* package in too) so there is little I can do on the end of package | > r-base. Briefly, I am being put into a bad corner by other maintainers here, | > and I no longer have the energy to discuss that with them. We have been at | > this for years. | | I think "discuss" was probably not the best word for Paul to suggest here. | | You only need to inform the maintainers of the affected packages, and | that can be done by filing RC bugs against the affected versions. If | the packages don't get updated, auto-removal will take care of them. | The sooner this is done, the better. Well when r-base 4.3.3-3 was being held back by what I consider autopkg overuse and a 100+ packages failed on two of the non-release-for-R 32-bit arches. I was not exactly in the mood to deal with 100+ RC bugs manually. _My package_ is fine and I take care of it. But I presume you guys have scripts for this while I do not. Some help and coordination may be useful and appreciated. One more thing: I forgot / failed to follow-up on what I had emailed about earlier. The Matrix package (aka "r-cran-matrix") update affecting the handful of packages _compiling against the Matrix header files_. That is just a few among hundreds using Matrix just as an R package (and which remain unaffected from the exported header API update which is shielded for normal use). CRAN and the Matrix team decided to wait for R 4.4.0 so Matrix will follow shortly after R 4.4.0 and I think I can handle that manually. Either n-day NMUs or simply initial bug reports requesting a rebuild. Cheers, and thanks as always for all you all on the release team do. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: R 4.4.0 coming April 24
Hi Paul, On 18 April 2024 at 11:50, Paul Gevers wrote: | Hi Dirk, | | On 18-04-2024 4:41 a.m., Dirk Eddelbuettel wrote: | > I uploaded a first | > beta release r-base_4.3.3.20240409-1 to 'experimental' a week ago, I just | > followed up with a rc release r-base_4.3.3.20240416-1. | | Thanks for preparing in experimental, as that triggers some QA. | | > Given these non-changes, I do not think we need a formal transition. If the | > release teams thinks otherwise, please let me know, ideally before April 24. | | https://qa.debian.org/excuses.php?experimental=1=r-base shows | there are 5 reverse (test) dependencies who's autopkgtest fail with the | latest r-base in experimental. You'll want to discuss with the | maintainers of those packages what that means for either r-base or their | packages (ideally by filing bug reports to track the discussion). Right now it now only shows 'all reports (re-)running'. But package r-base has had the usual issues in unstable for a few weeks now because 'some people' insist on adding autopkg tests including for architectures / build sizes no longer supported upstream -- R stopped 32 bit support over a year and release ago -- as well continually letting dependencies slip so that the autopkg tests involve old and outdated package releases combined with the fact that BioConductor has _very_ specific release cycles yet they throw r-bioc-* package in too) so there is little I can do on the end of package r-base. Briefly, I am being put into a bad corner by other maintainers here, and I no longer have the energy to discuss that with them. We have been at this for years. The r-base package itself is fine in unstable, as well as with eg the packages I maintain. It is also fine in Ubuntu (and Debian, both also via backports we coordinate at the R mirror network CRAN) and I run an add-on project [1] where *every* CRAN package (and 400+ BioConductor packages) is turned into .deb packages access from R via install.packages() (for the two most recent LTS releases). I know this stuff, I have been using and contributing to R for 25 years, I am in close contact with upstream, and I happen to sit on the R Foundation board. Cheers, Dirk [1] https://eddelbuettel.github.io/r2u | Paul | x[DELETED ATTACHMENT OpenPGP_signature.asc, application/pgp-signature] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
R 4.4.0 coming April 24
R 4.4.0 will be released on April 24 (following the long established pattern of annual 'a.b.0' releases). As is common, nightlies (as alpha, betas, rc) have been made available for four weeks leading up to it. I uploaded a first beta release r-base_4.3.3.20240409-1 to 'experimental' a week ago, I just followed up with a rc release r-base_4.3.3.20240416-1. (The date is the commit date, the tar.gz sources are updated nightly.) There is no documented (or anticipated) API change (see the doc/NEWS file, I also followed up with upstream to double-check) so the virtual tag can stay at r-api-4.0, the tag we have used since R 4.0.0. The graphics API (affecting graphics devices) also did not change and remains at 16 so the (auto-generated) tag remains at r-graphics-engine-16. Given these non-changes, I do not think we need a formal transition. If the release teams thinks otherwise, please let me know, ideally before April 24. Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: CRAN Package Matrix update and a possible transition or not
On 23 March 2024 at 07:25, Dirk Eddelbuettel wrote:
|
| On 22 March 2024 at 11:12, Dirk Eddelbuettel wrote:
| |
| | On 27 February 2024 at 19:01, Dirk Eddelbuettel wrote:
| | | A couple of days ago, the (effective) Maintainer and rather active
developer
| | | of the Matrix package Mikael Jagan (CC'ed) posted on the r-package-devel
list
| | | (the primary list for R package development) that the upcoming change of
| | | Matrix 1.7-0, planned for March 11, will be _very midly disruptive_ but
only
| | | to the very small subset of Matrix dependents that _actually use its
| | | headers_. See the full mail at [1]. The gory detail is that Matrix embeds
and
| | | uses an advanced sparse matrix library (called SuiteSparse) which it
updates,
| | | and the change in headers affects those (and only those!) who compile
against
| | | these headers.
| | |
| | | Now, Matrix currently has 1333 packages at CRAN using it [2]. But he
lists 15
| | | (fifteen) of possibly breaking because these are the packages having a
| | | 'LinkingTo: Matrix' [3]. That 1.113 per cent.
| | |
| | | It is similar for us. Running a simple `apt-cache rdepends r-cran-matrix
| wc -l`
| | | gets us 145 lines (including headers and meta packages). Call it 140 that
a
| | | transition would cover.
| | |
| | | But among the 15 affected only five are in Debian:
| | |
| | | irlbar-cran-irlba
| | | lme4 r-cran-lme4
| | | OpenMx r-cran-openmx
| | | TMP r-cran-tmp
| | | bcSeqr-bioc-bcseq
| | |
| | | One of these is mine (lme4), I can easily produce a sequenced update. I
| | | suggested we deal with the other _four packages_ by standard bug reports
and
| | | NMUs as needed instead of forcing likely 140 packages through a
transition.
| | |
| | | Note that is in fact truly different from the past two hickups with Matrix
| | | transition which happened at the R-only level of caching elements of its
OO
| | | resolution and whatnot hence affecting more package. This time it really
is
| | | compilation, and packages NOT touching the SuiteSparse headers (ie roughly
| | | 135 or so of the 140 Debian packages using Matrix) will not be affected.
| | |
| | | That said, I of course defer to the release team. If the feeling is 'eff
| | | this, transition it is' that is what we do. Whether I think is overkill or
| | | not is moot.
| | |
| | | Feel free to CC me as I am not longer a regular on debian-devel.
| |
| | The new Matrix release is now on CRAN so I plan to proceed as outlined with
a
| | first upload experimental, likely later today or this evening (my timezone).
|
| My bad. That was another release in the 1.6-* series, namely 1.6-5. No
| special action needed. 1.7-0 is still pending.
Gaaa. Wrong *again*. 1.7-0 *was* released (see my CRANberries log [1]) but
has since been withdrawn (!!) at CRAN. We continue to monitor.
Dirk
[1] https://dirk.eddelbuettel.com/cranberries/2024/03/22/#Matrix_1.7-0
| Dirk
|
| | Dirk
| |
| | |
| | | Cheers, Dirk
| | |
| | |
| | | [1] https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010463.html
| | | [2] In R:
| | | > db <- tools::CRAN_package_db()
| | | > matrixrevdep <- tools::package_dependencies("Matrix", reverse=TRUE,
db=db)[[1]]
| | | > length(matrixrevdep)# the vector 'matrixrevdep' list all
| | | [1] 1333
| | | >
| | | [3] LinkingTo:, despite its name, is the directive to include the package
C
| | | headers in the compilation. The 'db' object above allows to us to
subset
| | | which of the 1333 packages using Matrix also have a LinkingTo
| | |
| | |
| | | --
| | | dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
| |
| | --
| | dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
|
| --
| dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: CRAN Package Matrix update and a possible transition or not
On 22 March 2024 at 11:12, Dirk Eddelbuettel wrote:
|
| On 27 February 2024 at 19:01, Dirk Eddelbuettel wrote:
| | A couple of days ago, the (effective) Maintainer and rather active developer
| | of the Matrix package Mikael Jagan (CC'ed) posted on the r-package-devel
list
| | (the primary list for R package development) that the upcoming change of
| | Matrix 1.7-0, planned for March 11, will be _very midly disruptive_ but only
| | to the very small subset of Matrix dependents that _actually use its
| | headers_. See the full mail at [1]. The gory detail is that Matrix embeds
and
| | uses an advanced sparse matrix library (called SuiteSparse) which it
updates,
| | and the change in headers affects those (and only those!) who compile
against
| | these headers.
| |
| | Now, Matrix currently has 1333 packages at CRAN using it [2]. But he lists
15
| | (fifteen) of possibly breaking because these are the packages having a
| | 'LinkingTo: Matrix' [3]. That 1.113 per cent.
| |
| | It is similar for us. Running a simple `apt-cache rdepends r-cran-matrix |
wc -l`
| | gets us 145 lines (including headers and meta packages). Call it 140 that a
| | transition would cover.
| |
| | But among the 15 affected only five are in Debian:
| |
| | irlbar-cran-irlba
| | lme4 r-cran-lme4
| | OpenMx r-cran-openmx
| | TMP r-cran-tmp
| | bcSeqr-bioc-bcseq
| |
| | One of these is mine (lme4), I can easily produce a sequenced update. I
| | suggested we deal with the other _four packages_ by standard bug reports and
| | NMUs as needed instead of forcing likely 140 packages through a transition.
| |
| | Note that is in fact truly different from the past two hickups with Matrix
| | transition which happened at the R-only level of caching elements of its OO
| | resolution and whatnot hence affecting more package. This time it really is
| | compilation, and packages NOT touching the SuiteSparse headers (ie roughly
| | 135 or so of the 140 Debian packages using Matrix) will not be affected.
| |
| | That said, I of course defer to the release team. If the feeling is 'eff
| | this, transition it is' that is what we do. Whether I think is overkill or
| | not is moot.
| |
| | Feel free to CC me as I am not longer a regular on debian-devel.
|
| The new Matrix release is now on CRAN so I plan to proceed as outlined with a
| first upload experimental, likely later today or this evening (my timezone).
My bad. That was another release in the 1.6-* series, namely 1.6-5. No
special action needed. 1.7-0 is still pending.
Dirk
| Dirk
|
| |
| | Cheers, Dirk
| |
| |
| | [1] https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010463.html
| | [2] In R:
| | > db <- tools::CRAN_package_db()
| | > matrixrevdep <- tools::package_dependencies("Matrix", reverse=TRUE,
db=db)[[1]]
| | > length(matrixrevdep)# the vector 'matrixrevdep' list all
| | [1] 1333
| | >
| | [3] LinkingTo:, despite its name, is the directive to include the package C
| | headers in the compilation. The 'db' object above allows to us to subset
| | which of the 1333 packages using Matrix also have a LinkingTo
| |
| |
| | --
| | dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
|
| --
| dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: CRAN Package Matrix update and a possible transition or not
On 27 February 2024 at 19:01, Dirk Eddelbuettel wrote:
| A couple of days ago, the (effective) Maintainer and rather active developer
| of the Matrix package Mikael Jagan (CC'ed) posted on the r-package-devel list
| (the primary list for R package development) that the upcoming change of
| Matrix 1.7-0, planned for March 11, will be _very midly disruptive_ but only
| to the very small subset of Matrix dependents that _actually use its
| headers_. See the full mail at [1]. The gory detail is that Matrix embeds and
| uses an advanced sparse matrix library (called SuiteSparse) which it updates,
| and the change in headers affects those (and only those!) who compile against
| these headers.
|
| Now, Matrix currently has 1333 packages at CRAN using it [2]. But he lists 15
| (fifteen) of possibly breaking because these are the packages having a
| 'LinkingTo: Matrix' [3]. That 1.113 per cent.
|
| It is similar for us. Running a simple `apt-cache rdepends r-cran-matrix | wc
-l`
| gets us 145 lines (including headers and meta packages). Call it 140 that a
| transition would cover.
|
| But among the 15 affected only five are in Debian:
|
| irlbar-cran-irlba
| lme4 r-cran-lme4
| OpenMx r-cran-openmx
| TMP r-cran-tmp
| bcSeqr-bioc-bcseq
|
| One of these is mine (lme4), I can easily produce a sequenced update. I
| suggested we deal with the other _four packages_ by standard bug reports and
| NMUs as needed instead of forcing likely 140 packages through a transition.
|
| Note that is in fact truly different from the past two hickups with Matrix
| transition which happened at the R-only level of caching elements of its OO
| resolution and whatnot hence affecting more package. This time it really is
| compilation, and packages NOT touching the SuiteSparse headers (ie roughly
| 135 or so of the 140 Debian packages using Matrix) will not be affected.
|
| That said, I of course defer to the release team. If the feeling is 'eff
| this, transition it is' that is what we do. Whether I think is overkill or
| not is moot.
|
| Feel free to CC me as I am not longer a regular on debian-devel.
The new Matrix release is now on CRAN so I plan to proceed as outlined with a
first upload experimental, likely later today or this evening (my timezone).
Dirk
|
| Cheers, Dirk
|
|
| [1] https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010463.html
| [2] In R:
| > db <- tools::CRAN_package_db()
| > matrixrevdep <- tools::package_dependencies("Matrix", reverse=TRUE,
db=db)[[1]]
| > length(matrixrevdep)# the vector 'matrixrevdep' list all
| [1] 1333
| >
| [3] LinkingTo:, despite its name, is the directive to include the package C
| headers in the compilation. The 'db' object above allows to us to subset
| which of the 1333 packages using Matrix also have a LinkingTo
|
|
| --
| dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
CRAN Package Matrix update and a possible transition or not
A couple of days ago, the (effective) Maintainer and rather active developer
of the Matrix package Mikael Jagan (CC'ed) posted on the r-package-devel list
(the primary list for R package development) that the upcoming change of
Matrix 1.7-0, planned for March 11, will be _very midly disruptive_ but only
to the very small subset of Matrix dependents that _actually use its
headers_. See the full mail at [1]. The gory detail is that Matrix embeds and
uses an advanced sparse matrix library (called SuiteSparse) which it updates,
and the change in headers affects those (and only those!) who compile against
these headers.
Now, Matrix currently has 1333 packages at CRAN using it [2]. But he lists 15
(fifteen) of possibly breaking because these are the packages having a
'LinkingTo: Matrix' [3]. That 1.113 per cent.
It is similar for us. Running a simple `apt-cache rdepends r-cran-matrix | wc
-l`
gets us 145 lines (including headers and meta packages). Call it 140 that a
transition would cover.
But among the 15 affected only five are in Debian:
irlbar-cran-irlba
lme4 r-cran-lme4
OpenMx r-cran-openmx
TMP r-cran-tmp
bcSeqr-bioc-bcseq
One of these is mine (lme4), I can easily produce a sequenced update. I
suggested we deal with the other _four packages_ by standard bug reports and
NMUs as needed instead of forcing likely 140 packages through a transition.
Note that is in fact truly different from the past two hickups with Matrix
transition which happened at the R-only level of caching elements of its OO
resolution and whatnot hence affecting more package. This time it really is
compilation, and packages NOT touching the SuiteSparse headers (ie roughly
135 or so of the 140 Debian packages using Matrix) will not be affected.
That said, I of course defer to the release team. If the feeling is 'eff
this, transition it is' that is what we do. Whether I think is overkill or
not is moot.
Feel free to CC me as I am not longer a regular on debian-devel.
Cheers, Dirk
[1] https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010463.html
[2] In R:
> db <- tools::CRAN_package_db()
> matrixrevdep <- tools::package_dependencies("Matrix", reverse=TRUE,
db=db)[[1]]
> length(matrixrevdep)# the vector 'matrixrevdep' list all
[1] 1333
>
[3] LinkingTo:, despite its name, is the directive to include the package C
headers in the compilation. The 'db' object above allows to us to subset
which of the 1333 packages using Matrix also have a LinkingTo
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)
On 9 December 2023 at 01:06, Charles Plessy wrote:
| I do not know for r-bioc-netsam, but for r-bioc-org.hs.eg.db and similar
| packages, it is because it is an "annotation package" made of data and
| therefore not managed the same way as the other Bioconductor packages.
|
| This is why it DESCRIPTION file does not mention its Bioconductor Git
| branch. This is also why its version number matches the Bioconductor
| release number. Also, its homepage resolves to
|
https://bioconductor.org/packages/release/data/annotation/html/org.Hs.eg.db.html
| while for regular packages there is no data/annotation/html in the URL.
|
| I think that it does not have to depend on the bioc api pseudo-package.
When r2u builds all of CRAN plus the ~ 200 BioC that are implied plus ~ 200
more that either in Debian or high on BioC's own 'karma' list, I query all
four repositories as one must. That is basically what the BioC installer
helpers always did for twenty-some years. My code (quicker for me to find)
is
## cf contrib.url(BiocManager::repositories())
## [1] "https://bioconductor.org/packages/3.14/bioc/src/contrib;
## [2]
"https://bioconductor.org/packages/3.14/data/annotation/src/contrib;
## [3]
"https://bioconductor.org/packages/3.14/data/experiment/src/contrib;
biocrepo <- paste0("https://bioconductor.org/packages/;,
.getConfig("bioc_version"), "/bioc")
apBIOC <- data.table(ap="Bioc",
as.data.frame(available.packages(repos=biocrepo)))
biocdataannrepo <- paste0("https://bioconductor.org/packages/;,
.getConfig("bioc_version"), "/data/annotation")
apBIOCdataann <- data.table(ap="Bioc",
as.data.frame(available.packages(repos=biocdataannrepo)))
apBIOC <- merge(apBIOC, apBIOCdataann, all=TRUE)
biocdataexprepo <- paste0("https://bioconductor.org/packages/;,
.getConfig("bioc_version"), "/data/experiment")
apBIOCdataexp <- data.table(ap="Bioc",
as.data.frame(available.packages(repos=biocdataexprepo)))
apBIOC <- merge(apBIOC, apBIOCdataexp, all=TRUE)
Ah, and younger Dirk left a message for current Dirk that this does indeed
show it too:
> contrib.url(BiocManager::repositories())
'getOption("repos")' replaces Bioconductor standard repositories, see
'help("repositories", package = "BiocManager")' for details.
Replacement repositories:
CRAN: https://cloud.r-project.org
[1] "https://bioconductor.org/packages/3.18/bioc/src/contrib;
[2] "https://bioconductor.org/packages/3.18/data/annotation/src/contrib;
[3] "https://bioconductor.org/packages/3.18/data/experiment/src/contrib;
[4] "https://bioconductor.org/packages/3.18/workflows/src/contrib;
[5] "https://bioconductor.org/packages/3.18/books/src/contrib;
[6] "https://cloud.r-project.org/src/contrib;
>
And when I bulk-updated the BioC packages for my 20.04 and 22.04 build in
r2u, I did notice that some of the 'non-R-package packages' in annotations
and experiment did not update. One could always ask BioC which of these are
/ are not considered release dependent. Their slack is open and pretty
friendly, I hang there too.
Cheers, Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Matrix update triggering need for four rebuilds
On 17 November 2023 at 23:50, Nilesh Patra wrote: | | | On 17 November 2023 11:34:21 pm IST, Dirk Eddelbuettel wrote: | > | >On 17 November 2023 at 18:43, Andreas Tille wrote: | >| Am Fri, Nov 17, 2023 at 10:12:02AM -0600 schrieb Dirk Eddelbuettel: | >| > Leaving | >| > | >| >r-cran-irlba | >| >r-cran-openmx | >| > | >| > for you (unless you got to it already). | >| | >| To make it pretty clear: I will not simply rebuild these packages before | >| we have a promising solution for the future. If you do not agree with | >| this you can either | >| | >|* Ask for Bin-NMU which should be sufficient | >|* Do a team upload | > | >"Our users are our preference". Debian Social Contract. | | You don't get to play this card with uncoordinated transitions. | | Nobody is stopping you from doing team uploads for these packages fwiw. I tried to explain that upstream (both the package and CRAN) have no real handle on this so it is by _definition_ what you refer to (in a denigrating tone) an uncoordinated transition. In which a rebuild is good enough for upstream. And I have done one for my affected packages. My role ends there. If you guys think you must ambush your users and leave known broken packages in that state then that is your choice. At least you are saying so out loud. I'll will retreat and focus on things I can control. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Matrix update triggering need for four rebuilds
On 17 November 2023 at 18:43, Andreas Tille wrote: | Am Fri, Nov 17, 2023 at 10:12:02AM -0600 schrieb Dirk Eddelbuettel: | > Leaving | > | >r-cran-irlba | >r-cran-openmx | > | > for you (unless you got to it already). | | To make it pretty clear: I will not simply rebuild these packages before | we have a promising solution for the future. If you do not agree with | this you can either | |* Ask for Bin-NMU which should be sufficient |* Do a team upload "Our users are our preference". Debian Social Contract. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Matrix update triggering need for four rebuilds
On 15 November 2023 at 05:23, Dirk Eddelbuettel wrote: | | On 15 November 2023 at 07:00, Andreas Tille wrote: | | Am Tue, Nov 14, 2023 at 04:49:01PM -0600 schrieb Dirk Eddelbuettel: | | > | | > On 14 November 2023 at 16:17, Dirk Eddelbuettel wrote: | | > | | | > | On 14 November 2023 at 11:06, Andreas Tille wrote: | | > | | Am Mon, Nov 13, 2023 at 07:23:06AM -0600 schrieb Dirk Eddelbuettel: | | > | | > Most of these are not in Debian but I think we need binary rebuilds of | | > | | > | | > | | >irlbabecause of headers | | > | | >OpenMx because of headers, a new upstream 2.21.10 is out too | | > | | >TMB because of headers | | > | | | | > | | Uploaded yesterday since I realised the need. | | > | | | > | Thank you! | | > | | > I misread that, I think. So you updated TMB. Good. One done, three to go. | | | | Yes, that is what I intended to express. | | | | > irlba is widely used, OpenMx is big and I think MatrixModels also pops up. | | > If you could do a sweep over those I would appreciate it. | | | | I'll happily update these as soon as possible. However, I'd like to | | know what might be some sensible means to catch this quickly in future. | | For r-cran-tmb the strict version checking in d/rules (which is not the | | best thing to do according to the release team) was raising some signal. | | | | I'd like to clarify first, whether there will be some better solution | | via some r-matrix-api before I upload those other packages. | | I relayed information I got from Matrix upstream in private email which then | also lead to the emails written to r-package-devel I already referenced: | | https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010051.html | https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010054.html | | There is nothing more at this point. | | But we know the remaining Debian packages | | r-cran-irlba | r-cran-openmx | r-cran-matrixmodels | | require a rebuild. r-cran-matrixmodels is actually one of mine, and they just put a new upstream out so I'll update now. Leaving r-cran-irlba r-cran-openmx for you (unless you got to it already). Dirk | | Dirk | | | -- | dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Matrix update triggering need for four rebuilds
On 15 November 2023 at 07:00, Andreas Tille wrote: | Am Tue, Nov 14, 2023 at 04:49:01PM -0600 schrieb Dirk Eddelbuettel: | > | > On 14 November 2023 at 16:17, Dirk Eddelbuettel wrote: | > | | > | On 14 November 2023 at 11:06, Andreas Tille wrote: | > | | Am Mon, Nov 13, 2023 at 07:23:06AM -0600 schrieb Dirk Eddelbuettel: | > | | > Most of these are not in Debian but I think we need binary rebuilds of | > | | > | > | | >irlba because of headers | > | | >OpenMx because of headers, a new upstream 2.21.10 is out too | > | | >TMB because of headers | > | | | > | | Uploaded yesterday since I realised the need. | > | | > | Thank you! | > | > I misread that, I think. So you updated TMB. Good. One done, three to go. | | Yes, that is what I intended to express. | | > irlba is widely used, OpenMx is big and I think MatrixModels also pops up. | > If you could do a sweep over those I would appreciate it. | | I'll happily update these as soon as possible. However, I'd like to | know what might be some sensible means to catch this quickly in future. | For r-cran-tmb the strict version checking in d/rules (which is not the | best thing to do according to the release team) was raising some signal. | | I'd like to clarify first, whether there will be some better solution | via some r-matrix-api before I upload those other packages. I relayed information I got from Matrix upstream in private email which then also lead to the emails written to r-package-devel I already referenced: https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010051.html https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010054.html There is nothing more at this point. But we know the remaining Debian packages r-cran-irlba r-cran-openmx r-cran-matrixmodels require a rebuild. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Matrix update triggering need for four rebuilds
On 14 November 2023 at 16:17, Dirk Eddelbuettel wrote: | | On 14 November 2023 at 11:06, Andreas Tille wrote: | | Am Mon, Nov 13, 2023 at 07:23:06AM -0600 schrieb Dirk Eddelbuettel: | | > Most of these are not in Debian but I think we need binary rebuilds of | | > | | >irlba because of headers | | >OpenMx because of headers, a new upstream 2.21.10 is out too | | >TMB because of headers | | | | Uploaded yesterday since I realised the need. | | Thank you! I misread that, I think. So you updated TMB. Good. One done, three to go. irlba is widely used, OpenMx is big and I think MatrixModels also pops up. If you could do a sweep over those I would appreciate it. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Matrix update triggering need for four rebuilds
On 14 November 2023 at 11:06, Andreas Tille wrote: | Am Mon, Nov 13, 2023 at 07:23:06AM -0600 schrieb Dirk Eddelbuettel: | > Most of these are not in Debian but I think we need binary rebuilds of | > | >irlbabecause of headers | >OpenMx because of headers, a new upstream 2.21.10 is out too | >TMB because of headers | | Uploaded yesterday since I realised the need. Thank you! The rest is an open issue and not clear. I had a number of emails with both the active maintainer of Matrix (Mikael) who is considering declaring an API version at the package level, and one of the maintainers of an affected package (my colleague who is upstream for SeuratObject which was bitten by the S4 signature/namespace caching). I am also in some emails with CRAN and R Core but no resolution there. So for now this is "just an unfortunate one-off" and not yet something ready for a more systematic change. | >MatrixModels because of S4 caching | > | > I would appreciate it if someone could tickle rebuilds. To me a quick | > informal touch of debian/changelog would do; if someone thinks this needs a | > formal transition go for it. | | In principle upgrading four packages at request is cheap. However, I | have the feeling that we are technically more safe if we would introduce | some r-tmb-api which would technically raise a signal for tmb | dependencies. I've "hacked" some workaround into r-cran-tmb since I | was motivated by the github issue discussing the relation to Matrix[1] | to fix a very specifix Matrix version. I've put the release team in | CC since they were involved into the according discussion. I did not follow this closely but was that rather 'change in TMB driving issues in glmmTMB and alike' whereas this email is about 'TMB as a client of Matrix' ? Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1054657: transition: r-bioc-biocgenerics
On 7 November 2023 at 14:58, Andreas Tille wrote:
| Do you see any way to answer the question that is discussed in this
| thread by r2u how to know whether new Bioconductor packages might have
| new dependencies not yet packaged for Debian?
"Kinda. Sorta. Not fully." I have written related code doing most of this
during the many attempt for 'turning CRAN into .deb packages'.
I.e. when I recompile BioC packages in r2u as I did this weekend I start from
all BioC packages I have already built within r2u (same for you here for a
'within Debian' check), use available.packages() etc to get the package
database (in the R sense) and use that to map out dependencies. In my case I
sort strip off CRAN (already built) and base R packages to get a count of
'pure BioC depends'. I then sort and first build all of these with a
dependency count of zero, refresh the index so that these become available,
then all with a count of one and so. (Max count this weekend was 41.)
The one step I did not do (as I didn't need it) was to check 'is package X
already available'. When it wasn't I just built it :) But you can do all that
from either shell into apt-cache, or R via my RcppAPT package, or via
python-apt and friends.
My code is in R with use of data.table for the mangling so it is somewhat
'internal'. It is based on R's own 'tools::package_dependencies()'. There
must also be suitable code in R itself which I never pulled out because R can
run a package's reverse dependencies. But anyway here is a minimal sketch
using R and its data.table package.
> AP <- suppressMessages( data.table(available.packages(repos =
> BiocManager::repositories())) )
> AP[, lcpkg := tolower(Package)]
> basePkgs <- c("base", "class", "codetools", "datasets", "graphics", "grid",
> "lattice",
+ "Matrix", "mgcv", "nnet", "rpart", "splines", "stats4", "tcltk",
"translations",
+ "boot", "cluster", "compiler", "foreign", "grDevices", "KernSmooth", "MASS",
+ "methods", "nlme", "parallel", "spatial", "stats", "survival", "tools",
"utils")
> cranPkgs <- AP[Repository=="https://cloud.r-project.org/src/contrib;, Package]
> biocPkgs <- AP[Repository!="https://cloud.r-project.org/src/contrib;, Package]
>
> pkg <- "SingleCellExperiment"
> deps <- tools::package_dependencies(pkg, AP, recursive=TRUE)[[1]]
> nAll <- length(deps)
> nBase <- length(intersect(deps, basePkgs))
> nCran <- length(intersect(deps, cranPkgs))
> nBioc <- length(intersect(deps, biocPkgs))
>
> intersect(deps, biocPkgs)
[1] "SummarizedExperiment" "S4Vectors""BiocGenerics"
"GenomicRanges"
[5] "DelayedArray" "MatrixGenerics" "IRanges"
"S4Arrays"
[9] "GenomeInfoDb" "XVector" "Biobase"
"GenomeInfoDbData"
[13] "zlibbioc"
>
So for all packages you are interested in (here I look just at
'SingleCellExperiment') you construct the BioC (or maybe CRAN and BioC)
dependencies, and then create an aggregate list of the unique
combination. Those are the packages you need and apt-cache and related will
tell you if they exist.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1054657: transition: r-bioc-biocgenerics
On 7 November 2023 at 22:01, Charles Plessy wrote: | One possible direction would be to leverage the work done by Dirk and | others in r2u, where the Bioc transition is over, and for each package | in Debian, look if the r2u equivalent has a dependency not in Debian. | | https://fediscience.org/@eddelbuettel@mastodon.social/111359074099802189 Thanks for the endorsement, Charles. As you brought r2u up, allow me to add my perspective. I have done so before without changing anyone's mind but once every few years I get to howl at these windmills. So I have been maintaining CRAN packages in Debian for 20 years [1], and I said for twenty years that we can trust CRAN. I meant that then, I mean it now. Ditto for BioConductor. Doubling all our testing up, and also throwing spanners into our own wheels via the autopkgtests, is (to me) a waste of our (limited !!) volunteer time. We *do* add value to CRAN (and BioConductor) because we build on much more exotic platforms than they do. But testing _again_ on core platforms like x86_64 is (to me) simply does not seem all that efficient. My r2u [2] is a case in point. As of last Friday, I had ~ 270 BioConductor packages in it (that is for Ubuntu LTS release 20.04 and 22.04, and of course in addition to the 22k CRAN packages each already has). I then rebuilt those 270 first for 'focal' (20.04) and then 'jammy' (22.04) on my machine [3] and uploaded them. After that, I realized I could and should check against BioConductor's own 'popularity context' [4,5] and ensured I had the top 200+ packages. And I also ran a `setdiff()` against the package 'testing' knew. So I added from both these source on the weekend. So r2u is now at 391 or so BioConductor packages, all at 3.18, for both 20.04 and 22.04. And 22.2k for CRAN. This does provide the obvious existence proof that yes, right after a BioConductor release their stuff of course works: they have AFAIK paid staff to ensure this. r2u has been running for a little over 1 1/2 years. It has shipped over 10 million packages (and I luckily have access to a well-connected mirror on the U of Illinois campus as I teach there part-time). It had a download spike in October (from a European research center, I have access to download logs) fetching 3+ million in two days (!!). It now sees a daily (!!) download from a 'well known US west coast tech giant' taking in about 5200 packages _each day_ from what looks like a cron job. It serves about 1000 unique IPs each day. There is clear demand for this. So if we wanted to do something useful, we should extend r2u to Debian. I have limited 'personal' bandwidth and hardware but if someone wanted to join we could make some hay here. People trust apt. The technology is there and works as we all know. It might be worth discussing how we can offer the 19.9k packages on CRAN [6] and all/most of BioConductor. We may want to do that in a to-be-determined form outside the distro as the ftpmasters (whose work I so appreciate, so let me say a big thanks here) cannot possibly 'manually' check 20+k thousand packages. But as I said on the outset: We *can* trust CRAN and BioConductor and take advantage and leverage their work which (among many other things) contains the same authorship, copyright, IP, ... tests we do. Thanks for listening for my sermon. I will now be quiet again and concentrate on these (in aggregate coming up on) 45k packages. I do appreciate everything that everybody does here -- we are after all a bunch of committed volunteers. Cheers, Dirk [1] The very first one we had was IIRC my r-cran-rodbc as ODBC headers always baffled users; and still do [2] See https://eddelbuettel.github.io/r2u [3] For BioConductor I cannot (?) use pre-made binaries as I do for (most of) CRAN via R-style binaries from p3m.dev which I turn into proper .deb files. [4] They call it somethings else, and 'score' downloads by unique IP over a rolling (12 months if I recall) window [5] See https://bioconductor.org/packages/stats/bioc/bioc_pkg_scores.tab [6] CRAN purges reasonably aggressively which is how r2u is now at 22.2k while CRAN is at 19.9k. -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1054657: transition: r-bioc-biocgenerics
On 27 October 2023 at 16:43, Andreas Tille wrote: | Am Fri, Oct 27, 2023 at 09:19:22AM -0500 schrieb Dirk Eddelbuettel: | > | > | BioConductor has just released version 3.17. Since the next r-base | > | > Typo: 3.18 | | Yes. Thanks for pointing this out. | | > | release is pending on 2023-10-31 we do not think it is a good idea to | > | start the transition before but it might make sense to open this bug | > | > These two events are basically unrelated. (BioC releases twice a year, and | > the April release comes usually right after an R release. Those may warrant | > staging. October releases do not. It uses R 4.3.*. Note the wildcard.) | > | > | right now. (No idea whether we will see a proper r-api transition but | > | > R does not change APIs on _minor_ releases such as 4.3.2 next week. | | Thank you for this information. Since we will "loose" just about one | week I think waiting for r-base 4.3.2 makes sense anyway. It might | even last some days until release team might have setup the transition | tracker. Let me stress again that it is not relevant. You need R 4.3.0 or R 4.3.1 which havce existed for months inside the distro. Nothing in the release notes will suggest R 4.3.2 and none of those packages will change between use with either R 4.3.1 and R 4.3.2. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1054657: transition: r-bioc-biocgenerics
On 27 October 2023 at 16:00, Andreas Tille wrote: | Package: release.debian.org | Severity: normal | User: release.debian@packages.debian.org | Usertags: transition | X-Debbugs-Cc: r-bioc-biocgener...@packages.debian.org, debia...@lists.debian.org | Control: affects -1 + src:r-bioc-biocgenerics | | Hi, | | BioConductor has just released version 3.17. Since the next r-base Typo: 3.18 | release is pending on 2023-10-31 we do not think it is a good idea to | start the transition before but it might make sense to open this bug These two events are basically unrelated. (BioC releases twice a year, and the April release comes usually right after an R release. Those may warrant staging. October releases do not. It uses R 4.3.*. Note the wildcard.) | right now. (No idea whether we will see a proper r-api transition but R does not change APIs on _minor_ releases such as 4.3.2 next week. Dirk | building everything against the new r-base sounds like less hassle | than doing r-api-bioc transition right now.) | The BioConductor transition will bump the virtual package | r-api-bioc-3.17 to r-api-bioc-3.18. | | BTW, I'm aware that a couple of r-bioc-* packages did not yet migrated | to testing due to some autopkgtest issues on some architectures. We | decided that it makes sense to do the transition first and approach | upstream about their latest release in case those issues might remain. | | Kind regards and thanks a lot for your work as release team | Andreas. | | Ben file: | | title = "r-bioc-biocgenerics"; | is_affected = .depends ~ "r-api-bioc-3.17" | .depends ~ "r-api-bioc-3.18"; | is_good = .depends ~ "r-api-bioc-3.18"; | is_bad = .depends ~ "r-api-bioc-3.17"; | -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
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 the end. I believe this | will work better for derivatives and make backports easier. Almost done building, will upload shortly. Thanks, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
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-base package in bookworm can be | > | removed from the r-base package in unstable. | > | > Good point and much less ugly then :) | | I'll prepare a patch dropping the old and adding the new Breaks. Sounds good, and thanks for the assist! I should be able to provide a pretty quick turn-around. Onwards! Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
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 the next release. So | every Breaks that's present in the r-base package in bookworm can be | removed from the r-base package in unstable. Good point and much less ugly then :) Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
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 a class | of issues that often went unnoticed years ago. One of these things is Of course I am not against testing auto-upgrades. I imagine nobody is. What I am not happy about is that we fell into a hole we would not need to be in, ideally. Please hear me out on this: - R has an annual release cycle at the end of April - During that cycle the 'next' release (in VCS) is referred to as r-devel. - CRAN checks all packages at all uploads, as well as periodically, against r-devel. - When a change is needed because something would break once r-devel becomes 'r-release' they contact the package author and request the change, this is a hard requirement and non-compliant package are thrown off CRAN. No - breakage allowed! - What I showed with maldiquant was that its upstream made the change in March still well before the R 4.3.0 release requiring it - So we could have (we had the freeze, more below) had the package which would have passed both 'r-release' then and 'r-devel then' (which is 'r-release now') and everything would pass. Even under our tests. That is an ideal I would really like us to move towards with the CRAN packages in Debian. As CRAN makes it so easy for us to 'always build / build @HEAD' we really should take the fullest advantage of it. So I typically roll up my packages the day or week of a CRAN change. (And maintain 2 x 21k binaries off CRAN in r2u, but that is a different story.) As it happens, not everybody does, sometimes we have freezes, and other things happen. Also the number of CRAN packages increases of course and the net-net of that is that we then have to spend precious manual time picking up the pieces. Clearly not ideal, but better than having installation bugs. | that partial upgrades can leave you in a bad state. So more and more we | see that packages "have to" add Breaks to tell apt that when you want to | upgrade package X, you also have to upgrade package Y if you happen to | have that installed. As package Y can not tell that, package X has to | add the Breaks on the broken version of Y. As an example, see the list | of Breaks in libc6 [1]. While partial upgrades aren't officially Thanks for that. An impressively long list! | supported, we rely on them nevertheless (even if only for QA (piuparts, | autopkgtest)), and as a Release Team member I consider that class of | fixes technical excellence: ensuring as best as we can that the user | that upgrades a package keeps a working system. Yes. | While a rebuild of everything combined with bumping the "api" would | achieve that, I'm much more in favor of targeted Breaks, like we have | been discussing here. It's typically more work, but it's more correct. Fully agreed. | For the future, with the recent change in dh-r, r-base will be much less | impacted by this "problem" as the new uploads of reverse dependencies | can migrate *before* r-base, and hence this class of issues will I don't think so. The recent change helps with the (approximately a handful or two CRAN packages) setting the graphics engine check (out of a total of maybe 1300 CRAN/BioC packages at Debian leaving the many others unaffected). | disappear once that happens (autopkgtest failures are retried after a | day). So unless somebody investigates the issues in time, the retry will We will get the same breakage next time will CRAN assumes (and ensures !!) everything is current at HEAD, we usually have slippage for various reasons so in practice I fear ... here we are and remain. | pass after the migration and the issue will no longer block r-base. I | can live with that, but I find it a shame nevertheless. Yep. We should aim to have 'less shame, more technical excellence'. | So, what do you say: technical excellence and you add the Breaks? Or we | let this slip in? I prefer the former, I can live with the latter. I can add the Breaks as a 'best of the worse alternative'. And, I presume, I can remove the existing four-year breaks? [1] Cheers, Dirk [1] edd@rob:~/deb/r-base(master)$ git blame debian/control | grep -A24 Breaks 52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 55) Breaks: r-bioc-graph (<< 1.62.0-1~), 52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 56) r-cran-bbmle (<< 1.0.20-5~), 52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 57) r-cran-biocmanager (<< 1.30.4+dfsg-2~), 52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 58) r-cran-caret (<< 6.0-84-2~), 52de7d776d (Dirk Eddelbuettel 2019-08-08 19:11:55 -0500 59) r-cran-cmprsk (<< 2.2-8-1~), 52de7d776d (Dirk Eddelbuettel 2
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
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 relese in April. | | I still have hopes that we can let technical excellence rule and not require | blunt instruments such as forced recompilation. | | Because with slips like this, even forcing recompilation of over 1000+ | sources packages times 10+ architectures (for binary-any) will not help | against stale code, and hence mismatched expectations in the language engine | (r-base) and its client packages. I should have double-checked. 1.22.1-1 is in unstable, so that is good, and hence works with R 4.3.[01]. So what tripped me up is the (known, and expected, if "you know") failure in the (hence not all that informative) autopkgtest of trying R 4.3.1 with the outdated maldiquant 1.22 (not 1.22.1). I am not versed well-enough in the mechanics of release details. If the only way to get r-base into testing consists of having a Breaks for r-cran-maldiquant (<< 1.22.1) then I guess that is what we need to do. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
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 upstream at 1.22.1, since March, with a sole entry in NEWS being CHANGES IN MALDIquant VERSION 1.22.1 [2023-03-20]: -- * Use symbols instead of names in `.Call` for faster lookup of C functions. So there it is. 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 relese in April. I still have hopes that we can let technical excellence rule and not require blunt instruments such as forced recompilation. Because with slips like this, even forcing recompilation of over 1000+ sources packages times 10+ architectures (for binary-any) will not help against stale code, and hence mismatched expectations in the language engine (r-base) and its client packages. Best, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
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 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 was a change by some packages opting into different behavior.
|
| I don't understand this then. For several packages we're seeing failures
| in testing even if we only use r-base from unstable and everything else
| from testing to run the test. They pass with a rebuild r-cran-fnn and/or
| a rebuild and updated r-cran-ps, and/or r-cran-tibble. (Sorry, in my
| previous message I think I added r-cran-dplyr by mistake, misremembered).
It would be useful to break this down into concrete reproducible examples.
| > | 33s 10. ps:::not_null(.Call("psll_connections", p))
| >
| > Tis would be a bug in r-cran-ps and I think a Breaks may be warranted.
|
| Ok, let's remember this.
|
| > Given
| > that ps always had 'native symbols', maybe testthat changed?
|
| But I think (I would need to check for the autopkgtest fallback) in none
| of the tests, the version of testthat in testing changed between passing
| and failing tests. Would testthat embed something during the build of
| the binaries (from the name, I would assume not)?
I don't think it would do anything _explicit_.
I think what we are seeing is simply 'fragility from some packages with
larger tails'. If you install 'testthat' (presumably just to run tests) you
end up with with 30+ packages loaded (without considering Suggests:). It is
similar with other 'tidyverse' packages (dplyr, tibble, vctrs, ...) are all
part of that.
| > | Same for r-cran-fnn, which impacts r-cran-uwof [2].
I just looked at FNN, it is very narrow package at its core, it gets a bit of
tail via the Suggests of chemometrics.
| > | I think what we should do is add a versioned Breaks in r-base on
| > | , r-cran-ps, r-cran-tibble,
| > | r-cran-dplyr, r-cran-fnn. I think that's the right thing to do for
| >
| > I think it would be best to work out to corresponding package pairings and
| > apply the Breaks to them. If we can.
|
| Sure, lets add the Breaks to the place where it belongs.
|
| > For spacetime and stars I suspect (based on past experience) possible
| > interaction from the underlying graphics libraries.
|
| Good to hear, didn't check yet, but will shortly (geospatial).
It's a complex block. spacetime is one of the older ones using 'sp' (and then
'raster' via Suggests), 'stars' is newer using 'sf'. Sometimes these prefer /
work better with a consistent rebuild.
| > If I am not mistaken all of these were already in the Excuses list before we
| > made addition of the r-graphics-engine-* tag (which was taken care of for R
| > 4.3.* already, having it may help if another change happens like that).
|
| Sure, I'd hope the r-graphics-engine-* Provides only reduced issue, so
| I'm currently considering them to be different. But I might be proven
| wrong easily.
I don't think it had a net effect this. The
|
| > Unfortunately I find
| > the reports a little hard to read and am hence not very efficient at
| > pinpointing underlying causes. Above you pointed eg at [2] for uwot, I see
no
| > error in there :-/
|
| Well, that log has two tests. The first second one passes, the first one
| has:
| 51s > library(testthat)
| 51s > library(uwot)
| 51s Loading required package: Matrix
| 53s >
| 53s > test_check("uwot")
| 53s Error in FNN::get.knn(X, k) : DLL requires the use of native symbols
| 53s Calls: test_check ... eval -> create_data -> find_nn -> FNN_nn ->
|
| 53s Execution halted
But uwot itself does not force symbols:
https://github.com/jlmelville/uwot/blob/master/src/RcppExports.cpp#L228-L231
and I mentioned, using just those two lines in common. So the forceSymbols
comes from somewhere else.
Ok, I rechecked. R 4.3.0 has this
* Attempting to use a character string naming a foreign function
entry point in a foreign function call in a package will now
signal an error if the packages has called R_forceSymbols to
specify that symbols must be used.
It used to _ignore_ the combinatation of calling R_forceSymbols _and_ use of
non-symbols / quoted identifiers. Now it errors: if you have R_forceSymbols
each .Call() will require symbols (not strings).
So this is where R 4.3.[01] will possibly break with some older packages.
But the fix is simple because when R 4.3.0 came out all packages at CRAN
complied. We need to have current packages that correspond to the R 4.3.0
standard.
(If one were super picky one could call this an ABI/API change and reason for
forcing _all_ packa
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
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.com | @eddelbuettel | e...@debian.org
Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
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 was a change by some packages opting into different behavior.
| In unstable r-cran-xopen works. If I take r-cran-ps, r-cran-xopen and
| r-base from unstable and test in testing, r-cran-xopen works. If I only
| take r-base and r-cran-ps from unstable and test in testing,
| r-cran-xopen works. Can somebody with R understanding confirm?
|
| 33s Error in `not_null(.Call("psll_connections", p))`: DLL requires
| the use of native symbols
| 33s Backtrace:
| 33s 1. testthat::test_that(...)
| 33sat test.R:4:0
| 33s 2. testthat:::test_code(desc, code, env = parent.frame(),
| reporter = reporter)
| 33s 3. reporter$start_test(context = reporter$.context, test = test)
| 33s 4. testthat:::o_apply(self$reporters, "start_test", context, test)
| 33s 5. base::lapply(objects, f)
| 33s 6. testthat (local) FUN(X[[i]], ...)
| 33s 7. x$start_test(...)
| 33s 8. ps::ps_connections(ps_handle())
| 33s 9. ps:::psl_connections(p)
| 33s 10. ps:::not_null(.Call("psll_connections", p))
Tis would be a bug in r-cran-ps and I think a Breaks may be warranted. We
are apparently between version 1.7.2 and 1.7.5 of package (r-cran-)ps but I
see no smoking gun in https://github.com/r-lib/ps/blob/main/NEWS.md that
would have caused this.
Looking further, `git blame` indicates that the package had
`registation=TRUE` for five years / all its existence, see line 2 here
https://github.com/r-lib/ps/blame/357f9c01f5db95b67ce9e230282391bc835afca4/R/ps.R
It also used 'forceSymbols' for the same five years (lines 99 to 101 here
https://github.com/r-lib/ps/blame/357f9c01f5db95b67ce9e230282391bc835afca4/src/init.c
So I think the issue here may not be coming from ps. I has not changed how it
refers to its symbols. Same R API, same usage.
As the last entry here is into the (unexported) ps:::not_null we can look
into it. It just indexes with map_lgl which is a local function (from R/utils)
and calls psll_connection, a local compiled function in the package. Given
that ps always had 'native symbols', maybe testthat changed?
However, it does not force symbols :-/ Lines 20 and 21 use the two required
initialization but not the optional symbol forcing that eg ps has.
https://github.com/r-lib/testthat/blob/main/src/init.c
So I got nothing here. Cause is unclear to me.
| Same for r-cran-fnn, which impacts r-cran-uwof [2].
|
| I think what we should do is add a versioned Breaks in r-base on
| , r-cran-ps, r-cran-tibble,
| r-cran-dplyr, r-cran-fnn. I think that's the right thing to do for
I think it would be best to work out to corresponding package pairings and
apply the Breaks to them. If we can.
| bookworm to trixie upgrades (and current trixie to trixie with the new
| r-base). Has anyone see other packages throwing that "DLL requires the
| use of native symbols" error? I spotted the ones below [3, 4, 5, 6], but
| I haven't identified which package brings in the issue. I first thought
| it would be from the package itself, but for some (r-cran-spacetime and
| r-cran-stars) their versions in unstable fail their own testsuite in
For spacetime and stars I suspect (based on past experience) possible
interaction from the underlying graphics libraries.
| testing. Would it hint at the same problem for the packages, or just for
| their tests? I suspect the former, then they should also need to be
| added to the Breaks list.
|
| Paul
|
| [1]
|
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-xopen/35575366/log.gz
| [2]
|
https://ci.debian.net/data/autopkgtest/testing/i386/r/r-cran-uwot/35590669/log.gz
| [3]
|
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-intervals/35575046/log.gz
| [4]
|
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-maldiquant/35575320/log.gz
| [5]
|
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-spacetime/35575371/log.gz
| [6]
|
https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-stars/35583884/log.gz
If I am not mistaken all of these were already in the Excuses list before we
made addition of the r-graphics-engine-* tag (which was taken care of for R
4.3.* already, having it may help if another change happens like that).
So it short, the vast majority of R packages is now fine. A persistent
subset is not under the testing regime of autopkgtest. Unfortunately I find
the reports a little hard to read and am hence not very efficient at
pinpointing underlying causes. Above you pointed eg at [2] for uwot, I see no
error in there :-/
Obviously, I too want my package r-base in testing and I will help. But I
feel that pinning a large Breaks list on it seems a little inefficient /
unfair if
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
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
| | src/init.c:19: R_forceSymbols(dll, TRUE);
That mechanism should not spill from one package to the next.
What we have here is that (R) packages with compiled code can (optionally)
declare in NAMESPACE whether or not 'symbols' (ie the entrypoints for the
compiled code) should be a registered symbol (to R), or (as they used to be)
strings. That is then used in the first argument to .Call() as in eg
.Call(myfunc) as opposed to .Call("myfunc"). It has small efficiency
gains. Most packages do that now.
Now, another (less frequently-used) option is in the intialization file run
at package to also say R_forceSymbols in which case the second ("string")
form is no longer allowed. Few packages do that.
So if tibble does this now, it should only affect tibble itself -- unless of
course a dependent package calls directly into the native code of tibble
(possible, but rare).
So I sum in should not spill. I could be wrong but if there were general
spillage it would affect all R use of compiled packages and it very clearly
does not. So in short, this force symbol resolution should only affect the
symbols from the one shared (per-package) library it is set for.
| Since you are building with R from unstable and tibble from testing
| (built with an older R), it chokes and works when both are new.
Not sure I agree. That should still work. Quick check in Docker (using the
r-base image I maintain) shows it does:
root@f39da83dba5a:/# dpkg -l r-base-core r-cran-tibble | tail -2
ii r-base-core4.3.1-2 amd64GNU R core of statistical
computation and graphics system
ii r-cran-tibble 3.1.8+dfsg-1 amd64GNU R Simple Data Frames
root@f39da83dba5a:/# Rscript -e 'library(tibble); print(as_tibble(mtcars))'
# A tibble: 32 × 11
mpg cyl disphp dratwt qsecvsam gear carb
1 21 6 160110 3.9 2.62 16.5 0 1 4 4
2 21 6 160110 3.9 2.88 17.0 0 1 4 4
3 22.8 4 108 93 3.85 2.32 18.6 1 1 4 1
4 21.4 6 258110 3.08 3.22 19.4 1 0 3 1
5 18.7 8 360175 3.15 3.44 17.0 0 0 3 2
6 18.1 6 225105 2.76 3.46 20.2 1 0 3 1
7 14.3 8 360245 3.21 3.57 15.8 0 0 3 4
8 24.4 4 147.62 3.69 3.19 20 1 0 4 2
9 22.8 4 141.95 3.92 3.15 22.9 1 0 4 2
10 19.2 6 168. 123 3.92 3.44 18.3 1 0 4 4
# … with 22 more rows
root@f39da83dba5a:/#
It's simpy that testing has an older one and (esp in the tidyverse) things
change quickly and packages want to be in consistent cohort.
| This attribute has got something to do with R extensions' entry
| points / dll compatibilty, but I simply do not have enough background
| with r-core to comment beyond this point, I'm afraid.
Hope the above helped a little.
Dirk
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: transition: r-base
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 to do, and their simple rebuilds now shows https://qa.debian.org/excuses.php?package=r-base has no remaining graphics bugs. This demonstrates clearly that we do not "need" a graphics api. But as I get nowhere making this argument I relented and now provide r-graphics-engine-* from r-base-core. Packages have not used it yet, of course, so the transition cannot depend on it. This of cannot resolve the remaining problems at the excuses page. It would be nice if the maintainers of the packages experiencing the breakage were looking into them. I suspect relatively simple inter-package issues. The newest BioConductor release does as always use the most recent and preceding R release, so we probably need consistent builds of BioConductor release 3.16 using the R 4.3.* version that came out just before it. And likely similar with geo-spatial stack which of then refers consistent builds of its underlying library (gdal, geos, ...) Cheers, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1040001: transition: r-base
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 current versions capabilities. Graphics device packages can then opt
into what they support using conditional code. Or they can opt into checking
and aborting on any mismatch via R_GE_checkVersionOrDie (for
'R_GraphicsEngine_*)
void R_GE_checkVersionOrDie(int version)
{
if (version != R_GE_version)
error(_("Graphics API version mismatch"));
}
Which some packages do. Note that the packages _load_ and _function_ (in a
limited sense). They "simply" do not act as a graphics device, and alert the
user to rebuild the package.
So per upstream ("R Core" for short), this is clearly on the package
side. There is no ABI/API incompatibility: R offers graphics functions new
functionality, to use it one needs a rebuild _if a package decides to stop
and die on mismatch_.
I so filed three bug reports last weekend against three such packages
requesting a simple rebuild as that is in fact all it takes. (And
missed one that was added.) These were quickly rebuilt.
And as a consequence the 'excuses' list for r-base is shrinking now just as
one could expect [3]. In particular a number of packages from the ggplot2
complex are now all green ... with the exception of s390x where eg ragg (used
often in unit tests) is awaiting a rebuild [4]. Once s390x rebuilds those
packages will turn green leading into to their dependents turning green/
So in short, in my view as maintainer, a transition is overkill and a waste
of resources, cpu cycles and otherwise. I am rather confident it will
straighten itself out. (There may still be other issues with the
BioConductor release transition but I also expect those to be package-caused
and solvable.)
So let me know what you think. If the release team thinks we must rebuild
across 1100 r-* packages (of which likely 400-500 are Architecture: any)
then I will of course work with you.
But I maintain that it is not caused by the package, and not needed, as it is
a set of client-package-local differences these packages opt-in upstream and
which are solvable with a simple rebuild of those packages. Now, I
understand that _for simplicity_ we want to use this very blunt tool. But I
am old enough to remember that we also value engineering excellence. As
there is no need for brute force, I advocate against it. No more, no less.
Cheers, Dirk
[1] For us at /usr/share/R/include/R_ext/GraphicsEngine.h
[2] In the sources at src/main/engine.c
[3] https://qa.debian.org/excuses.php?package=r-base
[4] https://buildd.debian.org/status/package.php?p=r-cran-ragg
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On 16 May 2023 at 20:13, Nilesh Patra wrote: | Uh, no. Maybe you misunderstood my suggestion. The t-p-u way was for Indeed! | r-base can continue to stay where it already is at the moment :) Yep. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On 16 May 2023 at 19:49, Nilesh Patra wrote: | On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: | > I personally prefer "1" over 2 as it is less noise (and effort). | | On second thoughts, I think sending it via testing-proposed-updates | would be a better thing to do, as this case perfectly fits the problem. | | It's be same effort in both cases (one upload + filing a bug with release team). Reading 'https://wiki.debian.org/TestingProposedUpdates' does indeed suggest that this may be one of those situations. I can easily prepare a 4.3.0-2 with that destination but would prefer if someone from the release could 'nod', maybe in reply to this email. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On 16 May 2023 at 19:25, Nilesh Patra wrote: | On Tue, May 16, 2023 at 03:01:10PM +0200, Andreas Tille wrote: | > when fixing bug #1035428 I realised test suite issues with | > | > r-cran-thematic [1] | >-> Error in `svglite_(filename, bg, width, height, pointsize, standalone, | > always_valid)`: Graphics API version mismatch | > | > r-cran-treescape [2] | > r-cran-treespace [3] | >-> error is given if lambda is outside of [0,1] --- | > `medTree(trees, -1)` did not throw an error. | > | > As far as I can guess at least the first type of error (Graphics API | > version mismatch) is caused by the fact that a new upstream version of | > r-base (4.3.0-1) was uploaded to unstable (changelog[4] says to | > experimental so it seems by accident). | | I can think of two ways: | | 1. r-cran-shiny is an arch:all package, so the package itself being | built against r-base 4.3.0 is not an issue. The issue is the | "r-base-core (>= 4.3.0-1)" that dh-r injects, which is being pulled in | the autopkgtests of its reverse-depends. | Changing that to "r-base-core (>= 4.2.2.20221110-2)" manually should do | the trick. | | Something on the lines of: | | override_dh_gencontrol: | dh_gencontrol | sed "s/r-base-core (>= 4.3.0-1)/r-base-core (>= 4.2.2.20221110-2)" -i debian/r-cran-shiny/DEBIAN/control | | Ofcourse, the hard-coding of 4.3.0-1 can be converted to some better | regular expression. Nice catch and suggestion! On 16 May 2023 at 19:27, Nilesh Patra wrote: | On Tue, May 16, 2023 at 08:26:21AM -0500, Dirk Eddelbuettel wrote: | > Note that none of this affects the release. My recommendation is temporarily | > suspend the autopkgtest in those affected packages. | | No, don't do that as they indicate a new r-base being pulled as one of | the dependencies (which would be incorrect for a package). In this case, | r-cran-shiny has a hard-dependency on r-base. | | Once that is fixed, rest of the things should be sorted out. I agree. Thanks for pointing that out. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On 16 May 2023 at 15:01, Andreas Tille wrote: | Hi, | | when fixing bug #1035428 I realised test suite issues with | | r-cran-thematic [1] |-> Error in `svglite_(filename, bg, width, height, pointsize, standalone, | always_valid)`: Graphics API version mismatch | | r-cran-treescape [2] | r-cran-treespace [3] |-> error is given if lambda is outside of [0,1] --- | `medTree(trees, -1)` did not throw an error. | | As far as I can guess at least the first type of error (Graphics API | version mismatch) is caused by the fact that a new upstream version of | r-base (4.3.0-1) was uploaded to unstable (changelog[4] says to | experimental so it seems by accident). Yes. It was very much by accident, and my bad. When the freeze hardened and I switched uploading from unstable to experimental (on March 15 per my mail folder of installer replies, and coincidentally with the R 4.2.3-1 upload), I managed to update the distribution field (often using 'C-x d' in the handy Emacs mode) in the debian/changelog file each and every time --- with the one exception of the next update of r-base to the 4.3.0 release :-/ | I wonder what might be the most sensible strategy to fix this. Since | an epoch is considered ugly I've seen some kind of | 4.3.0+really+4.2.2.20221110 | version number. However, in case of R it might not be the best idea | to use this kind of fake version in a stable release. I think we shouldn't. Apart from this test issue, the binary sits in unstable and will remain in unstable. The change is graphics format is a repeat of previous micro-API changes from upstream where Paul Murrell (who is the one taking care of the graphics device) enhances its capabilities (often in quite meaningful ways). The R Core team does not consider this a breaking change, and does recommend or mandate rebuilds of the nearly 20k CRAN packages. I happen to concur. However, when a package built with such a graphics api version 'A' is loaded by R of version 'B' (and it usually happens to us the other way) the package load simply errors out with a message. This is not fatal -- it is just a hint to rebuild the package under the R version used. I have always been of the pragmatic view that is indeed good enough. (Johannes of the back-porters team disagrees, he reminded me of a simple search for the one code line doing the check. Running that at the GitHub mirror of CRAN (which is a superset as it includes packages that once were on CRAN but are no longer) I identified ten packages of which about half or more are no longer on CRAN. For us it is likely `ragg` and `svglite`. I can dig out the details from my reply to Johannes.) Note that none of this affects the release. My recommendation is temporarily suspend the autopkgtest in those affected packages. They did their job and found the mismatch with the R 4.3.0 in unstable that shouldn't have been uploaded there. Out the about fifty package uploads I made since I switched to experimental, one went to wrong repo. That was not intentional but I think we can manage. Best, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1023731: BioC Transition blocked by new dependencies
On 21 November 2022 at 16:39, Andreas Tille wrote: | Am Mon, Nov 21, 2022 at 03:05:26PM +0100 schrieb Sebastian Ramacher: | > On 2022-11-21 15:02:16 +0100, Andreas Tille wrote: | > > Some of the BioConductor packages need new dependencies. | > > I have pushed these to new queue and set the ITP bugs as | > > blocker. | > | > As this is happening every r-bioc transition, could this be handled | > before starting the transition the next time? It could, resources and volunteers willing. BioConductor leads the upcoming release as 'devel' just like we do. There is no reason to wait apart from having to set up new processes. I now also look behind a complete r-cran-* set of 20k packages for the two Ubuntu LTS flavors (it's a longer story but it reuses RSPM / PPM packages from RStudio / posit). For that effort, I just rebuilt the 240 BioConductors pulled in from the CRAN package graph for both LTS variants. I got all that done in a few hours on Saturday (after mulling over the problem and working out a script to determine build order by number of r-bioc-* depends). "Formal packaging" in Debian proper is more work, but there is no reason not to run a test build in a container, or even upload to 'experiemental' a few weeks prior to the (well telegraphed) BioConductor release. If someone wants to run with this (and knows a little R) I would be happy to discuss my 'build order' setup script (bare and hackish at it is). Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
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 doing it conflict-free with correct new SO names and version. Yippieh! Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
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. Ack, and understood. Using 'Profiles' instead of 'Options' is clear. I applied the patch, catching one typo (just two-chars switched in the updated comments, nothing affecting functionality) and -3 is now in unstable. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
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 been a huge source of frustration to me too ... | Instead of doing that, this could also be solved with a build profile. | See https://wiki.debian.org/BuildProfileSpec and the attached patch. See | also gtk4 and libgtk-4-media-ffmpeg for an example. I can apply the patch, that is easy enough. The angle in debian/control in 'Build-Profiles: ' are on purpose? Odd syntaxt. Anyway, will give it a whirl in a bit. The builds seems to be progressing otherwise and the new SO number does its job. Thanks again for your help in getting here. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
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 looking after the transition. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
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 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 libgsl27. | | Yes, without any other requirements … a normal source-only upload as | usual. 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 :) Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
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 libgsl27. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
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 which ones go in. (I am a bit of a packrat and keep old ones around.) https://salsa.debian.org/edd/gsl/-/tree/master/debian/patches | Sorry again for all the trouble. Do you know of some way I can check for | libtool problems prior to making new releases? I think this is the 3rd time | something like this has happened No troubles at all, and good question. For what I do as an upstream author (which is mostly R related) I sometimes try to tie myself down with tests (ie wrote shell script the other day extracing the release version number and checking if NEWS has it too as I released a few stales ones at times). But libtool, while I have _seen it used_ since the 1990s, is a little above my pay grade and higher up in complexity... Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
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 dependencies Done! And big thank you both. We should soon be in better shape with 2.7.1 as libgsl27 ! Patrick: I still have two local patches in the patches. One is one 'gsl-cblas' linkage (and I have forgotten the details, but I can probably dig them up) and a simple manual page edit. We should probably fold the manual page in, and can look into that before the next release. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
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! | | Dirk, please go ahead with gsl 2.7.1 in unstable whenever you are ready. Sebastian, Maybe I am being dense here ... but it should not go first to experimental? Or because of a new SO major we do not need a transition and just wait for normal rebuilds? That would be nice indeed. Bit tied up at work but should get to this this evening. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
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. Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
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: | > | > 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 | > | > 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_ leading to a new sonumber. This was | > | > corrected in (source package) gsl upload 2.7-3 to experimental, which built | > | > well. | > | | > | What's the status of the fix upstream? Was there any progress? Otherwise | > | we're gonna repeat that with the next upstream release. | > | > Those are two distinct issues. Upstream, I think we all agreed in the thread | > also recorded in the BTS, made an omission in this release where a new soname | > was needed, but wasn't given. This happens. So now we need a new soname | > __because the ABI/API changed__. | | Yes, the ABI changed and we need a new SONAME. This would ideally be | done upstream, though. Even better would be a new release with that change. Yes or no. We could proceed with the patch based on your suggestion. That would be "lighterweight" as we would not require upstream work right now. | As far as I am aware, the bug report lacks any mail from Patrick which He did participate earlier. Some of it may have been private mail between him and myself; I'd have to check. | would currently mean that we'd have a Debian-specific SONAME. If we go | ahead with that, we will end up in on of the following cases: | | 1. Upstream bumps the SONAME as we discussed it in the bug report. | Given the changes in [1], the next release of gsl would then have a | SONAME of libgsl.so.26, but with an incompatible ABI compared to what we | would have in the archive. I didn't catch that aspect. Yes us moving to libgsl.so.26 by ourself now would make it impossible to use that soname later :-/ | 2. Upstream bumps the SONAME to a version higher than 26. (That would be my stylistic preference. If the next GSL is 2.8, why not take 28? I may be unaware of other style 'customs' here.) | (3. Upstream simply ignores the issue) | | If 1. happens, we'd be unable to sync up with upstream's SONAME (there's | a good reason why we tend to avoid Debian-specific SONAMEs). | | Patrick, what are your planes? We're all ears :) Dirk | Best | Sebastian | | [1] https://git.savannah.gnu.org/cgit/gsl.git/commit/?id=191bf01a38e590dd0df8aa571accbbd331bfee07 | | > | > That has happened before, and that is why we had transitions in the past. | | | | > | > But not all previous releases had soname changes. I have maintained GSL here | > for about 20 years and I think this is about the third transition. I would | > call that defensible. | > | > The release team does of course have a broader view, and I am always keen to | > hear your thoughts. | > | > Cheers, Dirk | > | > | Cheers | > | | > | > | > | > I would like to ask for a formal transition. As we saw with failing tests in | > | > dependent packages, binNMUs will not work for all package (but possibly | > | > "most"). | > | > | > | > Tentative ben file below. | > | > | > | > - | > | > title = "gsl 2.7 transition"; | > | > is_affected = .depends ~ /libgsl-dev/; | > | > is_good = .depends ~ "libgsl26"; | > | > is_bad = .depends ~ "libgsl25"; | > | > - | > | > | > | > Let me know if I can help otherwise. | > | > | > | > Cheers, Dirk | > | > | > | > | > | > -- | > | > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | > | > | > | | > | -- | > | Sebastian Ramacher | > | x[DELETED ATTACHMENT signature.asc, application/pgp-signature] | > | > -- | > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | > | | -- | Sebastian Ramacher | [DELETED ATTACHMENT signature.asc, application/pgp-signature] -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
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 | > 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_ leading to a new sonumber. This was | > corrected in (source package) gsl upload 2.7-3 to experimental, which built | > well. | | What's the status of the fix upstream? Was there any progress? Otherwise | we're gonna repeat that with the next upstream release. Those are two distinct issues. Upstream, I think we all agreed in the thread also recorded in the BTS, made an omission in this release where a new soname was needed, but wasn't given. This happens. So now we need a new soname __because the ABI/API changed__. That has happened before, and that is why we had transitions in the past. But not all previous releases had soname changes. I have maintained GSL here for about 20 years and I think this is about the third transition. I would call that defensible. The release team does of course have a broader view, and I am always keen to hear your thoughts. Cheers, Dirk | Cheers | | > | > I would like to ask for a formal transition. As we saw with failing tests in | > dependent packages, binNMUs will not work for all package (but possibly | > "most"). | > | > Tentative ben file below. | > | > - | > title = "gsl 2.7 transition"; | > is_affected = .depends ~ /libgsl-dev/; | > is_good = .depends ~ "libgsl26"; | > is_bad = .depends ~ "libgsl25"; | > - | > | > Let me know if I can help otherwise. | > | > Cheers, Dirk | > | > | > -- | > https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | > | | -- | Sebastian Ramacher | x[DELETED ATTACHMENT signature.asc, application/pgp-signature] -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#998192: release.debian.org: Transition for gsl-2.7 / libgsl26
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_ leading to a new sonumber. This was corrected in (source package) gsl upload 2.7-3 to experimental, which built well. I would like to ask for a formal transition. As we saw with failing tests in dependent packages, binNMUs will not work for all package (but possibly "most"). Tentative ben file below. - title = "gsl 2.7 transition"; is_affected = .depends ~ /libgsl-dev/; is_good = .depends ~ "libgsl26"; is_bad = .depends ~ "libgsl25"; - Let me know if I can help otherwise. Cheers, Dirk -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#955211: release.debian.org: Transition r-base for 4.0.0
On 31 October 2020 at 18:46, Sebastian Ramacher wrote: | On 2020-05-28 11:58:09 -0500, Dirk Eddelbuettel wrote: | > | > Thanks everybody for the help with the transition: 4.0.0-3 is now in testing. | | So let's close this one. Indeed. Thanks for catching that! Dirk | Cheers | | > | > Which is lovely as upstream is already at work with 4.0.1 which will drop on | > June 6 [1]. I'll likely make an rc upload. | > | > Special thanks to Graham for calmly pulling a few strings here and there. | > | > Cheers, Dirk | > | > | > [1] Details as always at http://developer.r-project.org/, and just to be | > plain it is of course _not_ a binary change needing an API change. | > -- | > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | > | | -- | Sebastian Ramacher | x[DELETED ATTACHMENT signature.asc, application/pgp-signature] -- https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#955211: release.debian.org: Transition r-base for 4.0.0
On 29 May 2020 at 07:51, Dylan Aïssi wrote: | Hi, | | Le jeu. 28 mai 2020 à 18:58, Dirk Eddelbuettel a écrit : | > | > Thanks everybody for the help with the transition: 4.0.0-3 is now in testing. | > | | \o/ | | Both transition trackers (r-api-4.0 and r-api-bioc-3.11) were not very | useful to determine the order to update Bioconductor packages. | Some Bioconductor packages were green in the first tracker but red in | the second one, because they were automatically rebuild without an | upgrade. | So, it was not possible to use the first tracker to follow the upgrade | order of Bioconductor packages. | And the second tracker did not consider the r-api-4.0 rebuild order, | so some packages in the first levels were not buildable until the | dependency chain was ready for r-api-4.0. | | Next time there is a transition with these two r-api virtual packages, | we should use a unique ben file for them, something like this: | | title = "r-api"; | is_affected = .depends ~ "r-api-3.5" | .depends ~ "r-api-4.0" | | .depends ~ "r-api-bioc-3.10" | .depends ~ "r-api-bioc-3.11"; | is_good = .depends ~ "r-api-4.0" | .depends ~ "r-api-bioc-3.11"; | is_bad = .depends ~ "r-api-3.5" | .depends ~ "r-api-bioc-3.10"; Good point. Probably worth trying if the next transition once again has BioC within a week (which is common). Nobody knows what will be in R 4.1.0 next year. With some luck we may get by without a transition (a la R 3.6.0). Cheers, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#955211: release.debian.org: Transition r-base for 4.0.0
Thanks everybody for the help with the transition: 4.0.0-3 is now in testing. Which is lovely as upstream is already at work with 4.0.1 which will drop on June 6 [1]. I'll likely make an rc upload. Special thanks to Graham for calmly pulling a few strings here and there. Cheers, Dirk [1] Details as always at http://developer.r-project.org/, and just to be plain it is of course _not_ a binary change needing an API change. -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#955211: release.debian.org: Transition r-base for 4.0.0
On 25 May 2020 at 09:32, Graham Inggs wrote: | Hi All | | Thanks everyone for doing all the hundreds of uploads that were needed | for this combined transition. | All rebuilds for r-api-bioc3.11 are done [1] and there's one | outstanding FTBFS on a release architecture for r-api-4.0 [2]. The r-cran-treescape build bug has been there for several days, hopefully someone can take care of this. Also, the package is archived at CRAN, we could look into retiring it. And as the issue is on ppc64el, it may be long double related: we now configure without long double support there after consultation with upstream. | Now there are a handful of autopkgtest regressions [3] that need to be | resolved before migration can happen. These issues are likely self-imposed: looking at r-cran-etm and r-cran-sp we see clean sheets at CRAN for a variety of releases: https://cloud.r-project.org/web/checks/check_results_etm.html # etm https://cloud.r-project.org/web/checks/check_results_sp.html # sp The simplest may be to fix the apparent false positive on the package side. We're almost there. Nice work everyone! | As usual, please avoid uploads unrelated to this transition, they | would likely delay it and require supplementary work from the release | managers. Updates and package changes pile up. Eventually packages need to be built and updated again. Best, Dirk | Regards | Graham | | | [1] https://release.debian.org/transitions/html/r-api-bioc-3.11.html | [2] https://release.debian.org/transitions/html/r-api-4.0.html | [3] https://qa.debian.org/excuses.php?package=r-base -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#955211: release.debian.org: Transition r-base for 4.0.0
On 4 April 2020 at 13:40, Dirk Eddelbuettel wrote: | | On 4 April 2020 at 10:15, Sebastiaan Couwenberg wrote: | | On 4/3/20 8:27 PM, Dirk Eddelbuettel wrote: | | > Can the tracker sort by | | > - maintainer | | > - binary type | | > to help ? | | | | With the attached script you can create a dd-list from the tracker. | | | | transition-dd-list.pl -u | | https://release.debian.org/transitions/html/r-api-4.0.html | | Excellent, thank you! I needed to add libmojolicious-perl but that was it. It gets me packages by maintainer. What is missing is 'binary-arch' vs 'binary-all' because, if I have this right, maintainers need to manually upload binary-all package during the now started transition. Correct? Does anybody have a helper tool? Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#955211: release.debian.org: Transition r-base for 4.0.0
On 13 May 2020 at 10:15, Graham Inggs wrote: | Control: tags -1 + confirmed | | Hi Dirk | | On Fri, 1 May 2020 at 14:51, Dirk Eddelbuettel wrote: | > Please schedule a transition for r-base. | > | > I will then upload 4.0.0-3 to unstable as soon as I get your green light. | | Please go ahead with the upload to unstable. Great -- now building. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#959133: release.debian.org: Transition for gsl
On 4 May 2020 at 09:27, Graham Inggs wrote: | Control: tags -1 + confirmed | | Hi Dirk | | On Wed, 29 Apr 2020 at 21:33, Dirk Eddelbuettel wrote: | > GNU GSL 2.6 was release last fall; the package is stable and does not move | > too much upstream. It has been in 'auto transition' for a while following my | > initial upload to experimental. Could we maybe nudge it towards transition? | | Please go ahead and upload to unstable. Will do! Thanks for the help with this. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#955211: release.debian.org: Transition r-base for 4.0.0
On 29 April 2020 at 13:23, Dirk Eddelbuettel wrote: | R 4.0.0 was released as scheduled on Friday, source packages have been in | experimental since Friday too. | | There is one build failure on ppc64el but we now know what causes it so a bug | fix from upstream should be forthcoming shortly. The bug can also be | circumvented by (on that platform only) configuring with --disable-long-double. | | As such, we're ready, so I may I would like to nudge you towards considering | a start for this transition. R is reasonably widely used language that is | very well supported in Debian, and it would be good to have this updated | upstream version be part of Debian testing and the next release. New release 4.0.0-2 also builds on ppc64el (by disabling long double support, which upstream may also make the default for this platform) and is ready. Please schedule a transition for r-base. I will then upload 4.0.0-3 to unstable as soon as I get your green light. Cheers, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#959133: release.debian.org: Transition for gsl
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition GNU GSL 2.6 was release last fall; the package is stable and does not move too much upstream. It has been in 'auto transition' for a while following my initial upload to experimental. Could we maybe nudge it towards transition? Tentative ben file (copied from https://release.debian.org/transitions/html/auto-gsl.html and edited) - title = "gsl"; is_affected = .depends ~ "libgsl25" | .depends ~ "libgsl23"; is_good = .depends ~ "libgsl25"l is_bad = .depends ~"r-api-3.5" - Let me know if I can help otherwise. Cheers, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#955211: release.debian.org: Transition r-base for 4.0.0
All, R 4.0.0 was released as scheduled on Friday, source packages have been in experimental since Friday too. There is one build failure on ppc64el but we now know what causes it so a bug fix from upstream should be forthcoming shortly. The bug can also be circumvented by (on that platform only) configuring with --disable-long-double. As such, we're ready, so I may I would like to nudge you towards considering a start for this transition. R is reasonably widely used language that is very well supported in Debian, and it would be good to have this updated upstream version be part of Debian testing and the next release. Cheers, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#955211: release.debian.org: Transition r-base for 4.0.0
On 4 April 2020 at 10:15, Sebastiaan Couwenberg wrote: | On 4/3/20 8:27 PM, Dirk Eddelbuettel wrote: | > Can the tracker sort by | > - maintainer | > - binary type | > to help ? | | With the attached script you can create a dd-list from the tracker. | | transition-dd-list.pl -u | https://release.debian.org/transitions/html/r-api-4.0.html Excellent, thank you! I needed to add libmojolicious-perl but that was it. Cheers, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#955211: release.debian.org: Transition r-base for 4.0.0
Hi Graham, On 3 April 2020 at 21:32, Graham Inggs wrote: | Hi Dirk | | On Fri, 3 Apr 2020 at 20:27, Dirk Eddelbuettel wrote: | > I am still (as always) lost by the process. Does that mean an upload to | > unstable is now ok? Or not? I am unsure what "hand shake" from the ftp / | > release team I should be waiting for. | | Please not yet. Once r-base is uploaded to unstable, no other R | package will be able to migrate to testing until r-base itself | migrates, and r-base itself will not be able to migrate until every R | package has been rebuilt successfully (or removed from testing). | | When we are ready, someone from the release team will give you the | go-ahead in reply to this bug. Indeed -- so sounds good. A human heads-up is best, and now that you reiterate it I seem to recall having received those in the past. | > Can the tracker sort by | > - maintainer | > - binary type | > to help ? | | I don't believe so. | | Besides the bioconductor packages (92 of them according to the | tracker), how much other breakage do you expect? None, ex ante, but I can't speak for all packages. Some can be behind. I happen to know that 'team dplyr' at RStudio is planning a release and I saw in (my upstream work for Rcpp) reverse-depends checking for Rcpp (new version pending at CRAN) that a few packages are currently borked. | I seem to recall upstream has some nice CI pages, would you please | link to them here? Sure. Just how we have eg bugs.debian.org/NUMBERHERE we have a general per-package page at CRAN so http://cloud.r-project.org/package=Rcpp links to Rcpp's page, and it has a link to results which has a "mechanical" URL as well albeit less clean: https://cloud.r-project.org/web/checks/check_results_Rcpp.html We can s/Rcpp/AnyPackage/ here. Note that this may need capitalization so translation back from Debian packages is 'tricky' (but we have URL info in most debian/control files now). So eg my RcppArmadillo package has https://cloud.r-project.org/web/checks/check_results_RcppArmadillo.html There are some R packages that scrabe this info on a per-maintainer basis. foghorn is one. I have a simpler function checkCRANStatus() in my dang package (not in Debian, it's just a minor grabbag of random utilities). Hth, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#955211: release.debian.org: Transition r-base for 4.0.0
Hi Graham, On 3 April 2020 at 20:07, Graham Inggs wrote: | Hi Dirk | | On Sat, 28 Mar 2020 at 15:57, Dirk Eddelbuettel wrote: | > R does change internals every now and then with the annual releases; this is | > a major one which will require rebuilds of all packages. | | I've set up a transition tracker [1] where we can see the magnitude of | the transition. Thank you. I am still (as always) lost by the process. Does that mean an upload to unstable is now ok? Or not? I am unsure what "hand shake" from the ftp / release team I should be waiting for. | Packages marked [arch:all] will need uploads by the team / maintainer, | the rest can be handled by binNMU. Can the tracker sort by - maintainer - binary type to help ? | > R 4.0.0 will be released on April 24. The upstream team always follows a | > well-publicised schedule | | >From the schedule [2]: | | * Tuesday 2020-03-24: START | * Friday 2020-03-27: GRAND-FEATURE FREEZE (4.0.0 alpha) | * Friday 2020-04-10: FEATURE FREEZE (4.0.0 beta) | * Friday 2020-04-17: CODE FREEZE (4.0.0 RC) | * Tuesday 2020-04-21: PRERELEASE | * Friday 2020-04-24: RELEASE (4.0.0) | | I read on the debian-r mailing list that a parallel transition of | Bioconductor will also be needed [3]. | Would there be any point to starting the r-base transition much before | the release of Bioconductor (2020-04-28)? I do not know. I am much less involved in matters BioC but follow R business relatively closely. It all starts with my r-base package, after that we "merely" have to walk the dependency tree. Someone with more BioC clues (Charles?) may know better if you should for new upstreams from BioC or update what is in testing -- which I would upgrade as they /will/ fail to run / install / migrate due to r-3.5 and r-4.0 tags. | Please keep this bug in replies. Sure. Cheers, Dirk | Regards | Graham | | | [1] https://release.debian.org/transitions/html/r-api-4.0.html | [2] https://developer.r-project.org | [3] https://lists.debian.org/debian-r/2020/04/msg0.html -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#955211: release.debian.org: Transition r-base for 4.0.0
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debia...@lists.debian.org R 4.0.0 will be released on April 24. The upstream team always follows a well-publicised scheduled which started yesterday with the first 'alpha' release candidate, which I uploaded to experimental [1] R does change internals every now and then with the annual releases; this is a major one which will require rebuilds of all packages. The transition will be managed jointly by R package maintainer (myself) and the Debian R Packages Team. Using the 'debian-r' list (as in the CC above) is an efficient way to reach everybody. We have managed similar transitions before with R 3.4.0 and R 3.5.0. Note that last year's main release, R 3.6.0, did *not* require a rebuild hence the r-api-3.5 entry in the ben file below. Ben file: - title = "r-base"; is_affected = .depends ~ "r-api-3.5" | .depends ~ "r-api-4.0"; is_good = .depends ~ "r-api-4.0"; is_bad = .depends ~ "r-api-3.5"; - Special shoutout to Dylan and especially Graham for double-checking required steps here. Cheers, Dirk [1] https://packages.debian.org/source/experimental/r-base -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#920804: release.debian.org: security upload for r-cran-readxl
On 30 January 2019 at 13:59, Adam D. Barratt wrote: | On 2019-01-30 13:39, Dirk Eddelbuettel wrote: | > On 30 January 2019 at 13:11, Adam D. Barratt wrote: | > | On 2019-01-29 11:53, Dirk Eddelbuettel wrote: | > ... | > | > Happy to upload once you give a green light. (System information | > | > remove as I | > | > type this on Ubuntu 18.10 ...) | > | | > | Apparently it was already uploaded. | > | | > |patches/updated-upstream-changes | 2699 | > | +++ | > | > To unstable, yes - as 1.2.9000-1. | | and to stable - the diffstat above is from our automated tooling | noticing the upload appearing in stable-new. I see. I also (while commuting in) thought this may be the diff from April... | > But Moritz asked me to also upload to | > stretch. See https://packages.debian.org/search?keywords=r-cran-readxl | | I see. For reference, when a member of the Security Team says that, they | usually mean "talk to the Release Team about uploading". Moritz and then Salvatore pointed me to the manual and the recent d-d-a post which suggest filing a bug (I did) and upload (I am trying :). | > | Aside from being big enough to be non-trivial to review, the filename | > of | > | that patch isn't ideal. If there are other upstream changes that need | > | incorporating in future, are you simply planning on appending to that | > | patch, rather than having separate patches for specific purposes? | > | > This is Debian packaging of the CRAN package readxl. It's current | > upstream | > version is in better shape. | > | > I "have to" run this fix as CVE had been issued. As Moritz (now CCed) | > suggested that this doesn't need a full blown security upload (no DOS | > here, | > just plain segfaults in R when libxls loaded) we went this route. | | That explains the size, but the filename still isn't ideal. That isn't | reject-worthy in and of itself, it just has the potential to be more | annoying to review if there's an additional update for the package in | future. Let's see if any other issues pop up when someone finds | sufficient tuits to review the full changes, rather than my initial run | over the debdiff. The changelog is more detailed. In essence, and just like in April, I updated four files dealing with xls/ole/memory. Our tools then suggested 'dpkg-source --commit' which creates the one patch. Dirk | | Regards, | | Adam -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#920804: release.debian.org: security upload for r-cran-readxl
On 30 January 2019 at 13:11, Adam D. Barratt wrote: | On 2019-01-29 11:53, Dirk Eddelbuettel wrote: | > This is a follow-up to the discussion in #919324 and subsequent emails | > with | > Moritz and Salvatore. The two CVEs are genuine and fixed, the issue | > however | > is no a full-blown denial-of-service etc so Moritz suggested a normal | > security upload. | > | > The debdiff is included below, with the distribution changed from | > stretch-security to just stretch. | > | > Happy to upload once you give a green light. (System information | > remove as I | > type this on Ubuntu 18.10 ...) | | Apparently it was already uploaded. | |patches/updated-upstream-changes | 2699 | +++ To unstable, yes - as 1.2.9000-1. But Moritz asked me to also upload to stretch. See https://packages.debian.org/search?keywords=r-cran-readxl | Aside from being big enough to be non-trivial to review, the filename of | that patch isn't ideal. If there are other upstream changes that need | incorporating in future, are you simply planning on appending to that | patch, rather than having separate patches for specific purposes? This is Debian packaging of the CRAN package readxl. It's current upstream version is in better shape. I "have to" run this fix as CVE had been issued. As Moritz (now CCed) suggested that this doesn't need a full blown security upload (no DOS here, just plain segfaults in R when libxls loaded) we went this route. | I noticed that your changelog includes a Closes: for this bug. Please | don't do that. Bugs against release.d.o for stable updates get closed by | us once the package is actually in stable (i.e. after a point release | which includes the update has been released); uploading the package is | some way from the end of the process of the fix being available for end | users. Sorry my bad. I don't security uploads to stable often and am not as smooth as I could be for lack of practice. Is there anything you need correcting so badly that we need a new upload from me? If so can you spell out please in clear detail what needs changing. Many thanks, Dirk | Regards, | | Adam -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#920804: release.debian.org: security upload for r-cran-readxl
Package: release.debian.org Severity: normal This is a follow-up to the discussion in #919324 and subsequent emails with Moritz and Salvatore. The two CVEs are genuine and fixed, the issue however is no a full-blown denial-of-service etc so Moritz suggested a normal security upload. The debdiff is included below, with the distribution changed from stretch-security to just stretch. Happy to upload once you give a green light. (System information remove as I type this on Ubuntu 18.10 ...) Dirk diff -Nru r-cran-readxl-0.1.1/debian/changelog r-cran-readxl-0.1.1/debian/changelog --- r-cran-readxl-0.1.1/debian/changelog2018-04-13 08:18:46.0 -0500 +++ r-cran-readxl-0.1.1/debian/changelog2019-01-27 09:29:50.0 -0600 @@ -1,3 +1,18 @@ +r-cran-readxl (0.1.1-1+deb9u2) stretch; urgency=high + + * src/libxls/ole.h: Updated from readxl upstream (Closes: #919324) + * libxls/xlstool.h: Idem + * ole.c: Idem + * xls.c: Idem + * xlstool.c: Idem + + * This addresses +CVE-2018-20450 +CVE-2018-20452 +with corresponding upstream patch in libxls and readxl + + -- Dirk Eddelbuettel Sun, 27 Jan 2019 09:29:50 -0600 + r-cran-readxl (0.1.1-1+deb9u1) stretch-security; urgency=high * src/endian.c: Updated from libxls upstream (Closes: #895564) diff -Nru r-cran-readxl-0.1.1/debian/patches/series r-cran-readxl-0.1.1/debian/patches/series --- r-cran-readxl-0.1.1/debian/patches/series 2018-04-13 08:18:46.0 -0500 +++ r-cran-readxl-0.1.1/debian/patches/series 2019-01-27 09:29:50.0 -0600 @@ -1 +1,2 @@ libxls_upstream +updated-upstream-changes diff -Nru r-cran-readxl-0.1.1/debian/patches/updated-upstream-changes r-cran-readxl-0.1.1/debian/patches/updated-upstream-changes --- r-cran-readxl-0.1.1/debian/patches/updated-upstream-changes 1969-12-31 18:00:00.0 -0600 +++ r-cran-readxl-0.1.1/debian/patches/updated-upstream-changes 2019-01-27 09:29:50.0 -0600 @@ -0,0 +1,2699 @@ +Description: Updated upstream changes + Bug report #919324 contains two CVE reports against libxls which are, along + with two more listed at the upstream GitHub repo, fixed in this version of + readxl via updated files from libxls. +Author: Dirk Eddelbuettel +Bug-Debian: https://bugs.debian.org/919324 + +--- +Origin: upstream, https://github.com/evanmiller/libxls, various +Bug: https://bugs.debian.org/919324 +Forwarded: not-needed +Last-Update: 2019-01-27 + +--- r-cran-readxl-0.1.1.orig/src/libxls/ole.h r-cran-readxl-0.1.1/src/libxls/ole.h +@@ -1,33 +1,36 @@ + /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * + * +- * This file is part of libxls -- A multiplatform, C/C++ library +- * for parsing Excel(TM) files. ++ * Copyright 2004 Komarov Valery ++ * Copyright 2006 Christophe Leitienne ++ * Copyright 2008-2017 David Hoerl ++ * Copyright 2013 Bob Colbert ++ * Copyright 2013-2018 Evan Miller + * +- * Redistribution and use in source and binary forms, with or without modification, are +- * permitted provided that the following conditions are met: ++ * This file is part of libxls -- A multiplatform, C/C++ library for parsing ++ * Excel(TM) files. + * +- *1. Redistributions of source code must retain the above copyright notice, this list of +- * conditions and the following disclaimer. ++ * Redistribution and use in source and binary forms, with or without ++ * modification, are permitted provided that the following conditions are met: + * +- *2. Redistributions in binary form must reproduce the above copyright notice, this list +- * of conditions and the following disclaimer in the documentation and/or other materials +- * provided with the distribution. +- * +- * THIS SOFTWARE IS PROVIDED BY David Hoerl ''AS IS'' AND ANY EXPRESS OR IMPLIED +- * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND +- * FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL David Hoerl OR +- * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +- * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR +- * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON +- * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING +- * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ++ *1. Redistributions of source code must retain the above copyright notice, ++ *this list of conditions and the following disclaimer. ++ * ++ *2. Redistributions in binary form must reproduce the above copyright ++ *notice, this list of conditions and the following disclaimer in the ++ *documentation and/or other materials provided with the distribution. ++ * ++ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ''AS ++ * IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 1 June 2018 at 18:35, Graham Inggs wrote: | On 01/06/2018 17:19, Dirk Eddelbuettel wrote: | > This is now taken care of: dbi_1.0.0-2 was just uploaded | | Thanks Dirk! | | Another weirdness I have come across in Ubuntu today is rebuilds of | r-cran-expm and r-cran-mlmrev fail with the following: | | dh_auto_install: warning: can't parse dependency @builddeps@ | Can't call method "get_deps" on an undefined value at | /usr/share/perl5/Debian/Debhelper/Buildsystem/R.pm line 49. | | Both packages have the following in debian/tests/control: | Depends: @, @builddeps@, ... | | Removing either @ or @builddeps@ fixes the build, it seems to choke on | having both. Any ideas? I have seen that too working on the PPA side for some (inofficial) packages I needed for Travis. I think it may be an old debhelper but I don't really know. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 1 June 2018 at 06:32, Dirk Eddelbuettel wrote: | | On 1 June 2018 at 12:41, Graham Inggs wrote: | | A warning: src:dbi has a hard-coded dependency on r-api-3.4 in | | debian/control, and src:wkward has the same in debian/rules. | | That was from when dh-r was borked and could not cope with srcname != pkgname. | | I can look into fixing it this morning but as I said -- conference today and | tomorrow and I am giving a tutorial in 90 minutes. This is now taken care of: dbi_1.0.0-2 was just uploaded Dirk | Dirk | | | I was unable to find any more [1][2] like these codesearch.d.o. | | | | | | [1] https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+r-api-3.4 | | [2] https://codesearch.debian.net/search?q=path%3Adebian%2Frules+r-api-3.4 | | | | -- | http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 1 June 2018 at 13:37, Emilio Pozuelo Monfort wrote: | On 01/06/18 13:32, Dirk Eddelbuettel wrote: | > | > On 1 June 2018 at 11:54, Emilio Pozuelo Monfort wrote: | > | Scheduled for cluster foreign rmpi nlme rmatrix robustbase lmtest survival lme4 | > | tseries. | > | > Why is that needed? Aren't ALL binary packages auto-rebuilt? | | Depending on your definition of auto-rebuilt... I was the one who scheduled the | rebuilds, and I picked all arch:any packages from the transition page, except | for that set. The reason is that they didn't depend on r-base-3.4 (except on | kbsd, probably because of old builds), so it seemed unnecessary to rebuild them. Strange. A lot of these are "mine" and both old and fairly central. Let's follow-up when I have a moment. Ping me if forget / get distracted. But as a "technical issue" this should have a technical solution. Dirk | Turns out they need a rebuild as you guys have pointed out, so that's why I have | scheduled the rebuilds for them now. | | Hope that is clear, let me know if it is not. | | Cheers, | Emilio -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 1 June 2018 at 12:41, Graham Inggs wrote: | A warning: src:dbi has a hard-coded dependency on r-api-3.4 in | debian/control, and src:wkward has the same in debian/rules. That was from when dh-r was borked and could not cope with srcname != pkgname. I can look into fixing it this morning but as I said -- conference today and tomorrow and I am giving a tutorial in 90 minutes. Dirk | I was unable to find any more [1][2] like these codesearch.d.o. | | | [1] https://codesearch.debian.net/search?q=path%3Adebian%2Fcontrol+r-api-3.4 | [2] https://codesearch.debian.net/search?q=path%3Adebian%2Frules+r-api-3.4 | -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 1 June 2018 at 11:54, Emilio Pozuelo Monfort wrote: | Scheduled for cluster foreign rmpi nlme rmatrix robustbase lmtest survival lme4 | tseries. Why is that needed? Aren't ALL binary packages auto-rebuilt? Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#896667: transition: r-base-3.5
On 31 May 2018 at 16:17, Emilio Pozuelo Monfort wrote: | > (Out of nerdy curiousity because we sometimes drive rebuilds of [generally | > much smaller] subsets, where is the code that "walks" the dependency graph? | > Is that in libapt by chance [as I happen to have a package getting from R to | > libapt via Rcpp] or is it another tool I could milk for this? [ We also have | > something a decade old in the cran2deb repo but that is another story ... ] | | Do you mean the one that generates | https://release.debian.org/transitions/html/r-base-3.5.html ? If so, that'd be | ben (which is packaged). Not the page in the "how do I create a table in html" sense, but the "logic" in finding out first, second, third, .. "wave". Which is probably what you meant. But when I 'apt-cache show ben' I am no longer sure. So to rephrase: given a package (or set of packages), what computes the ordered set (or "graph" in the dependency sense) of their depends (or build-depends) ? Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#896667: transition: r-base-3.5
On 31 May 2018 at 16:15, Emilio Pozuelo Monfort wrote: | Hi, | | On 31/05/18 15:45, Emilio Pozuelo Monfort wrote: | > On 31/05/18 15:09, Dirk Eddelbuettel wrote: | >> | >> Emilio, Seb, | >> | >> Can you confirm that now that we have | >> a) "green light" on the transition, and | >> b) the r-base package is in unstable | >> we should see binary: any packages being rebuilt -- which I do not yet | >> see. When will this start? | > | > I will start the rebuilds soon (i.e. later today). | | Scheduled now (it will take some time as it's 320 arch:any packages). | | By the way there was a problem with my suggested jdk change: the architecture | restriction is applied first, and then the first alternative is taken, so for | e.g. m68k, openjdk-10-jdk is taken as it's the first valid alternative for that | architecture. But we don't want jdk there at all. So there are two good options: | | default-jdk [!arm !hppa !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386] There must be something that makes this form not preferred as I had been using the "concretePackage | virtualPackage" form for many years. If we did this, I would not have to jump through hoops updating the package ... | | i.e. drop the openjdk-10-jdk alternative, or | | default-jdk [!arm !hppa !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386] | | openjdk-10-jdk [!arm !hppa !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386] ... yet the other day I needed the form with openjdk-10 (as r-cran-rjava failed with with given that "its" r-base has still used openjdk-9. So I think the second form is better. I can do a quick rebuild if you concur. | | i.e. add the architecture restriction to openjdk-10-jdk as well. | | I'd go with the former, but both should work. If you can apply one of those | changes that'd help. | | Sorry for not realising that earlier. No worries. It's just cycles :) Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#896667: transition: r-base-3.5
On 31 May 2018 at 15:45, Emilio Pozuelo Monfort wrote: | On 31/05/18 15:09, Dirk Eddelbuettel wrote: | > | > Emilio, Seb, | > | > Can you confirm that now that we have | > a) "green light" on the transition, and | > b) the r-base package is in unstable | > we should see binary: any packages being rebuilt -- which I do not yet | > see. When will this start? | | I will start the rebuilds soon (i.e. later today). Excellent! (Out of nerdy curiousity because we sometimes drive rebuilds of [generally much smaller] subsets, where is the code that "walks" the dependency graph? Is that in libapt by chance [as I happen to have a package getting from R to libapt via Rcpp] or is it another tool I could milk for this? [ We also have something a decade old in the cran2deb repo but that is another story ... ] Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#896667: transition: r-base-3.5
Emilio, Seb, Can you confirm that now that we have a) "green light" on the transition, and b) the r-base package is in unstable we should see binary: any packages being rebuilt -- which I do not yet see. When will this start? On 31 May 2018 at 05:37, Dirk Eddelbuettel wrote: | | On 31 May 2018 at 09:25, Emilio Pozuelo Monfort wrote: | | On 31/05/18 00:13, Dirk Eddelbuettel wrote: | | > | | > On 30 May 2018 at 23:40, Emilio Pozuelo Monfort wrote: | | > | curl migrated to testing today. Please go ahead with R 3.5. | | > | | > Yay!! Thank you -- and r-base_3.5.0-3 is now in incoming awaiting inclusion | | > into unstable. | | | | Cool, it's almost built everywhere now. | | | | There are a few architectures where it can't built due to openjdk though. | | I see you changed the build-dependency to: | | | | openjdk-10-jdk | default-jdk [!arm !hppa !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386] | | Yes, that was the most recent bug report on it to reflect Java 10. | | | The buildds only take into account the first alternative, but since they don't | | have openjdk-10 they can't build r-base. One option is to put the architecture | | list in the first part, e.g. by swapping the order: | | | | default-jdk [!arm !hppa !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386] | openjdk-10-jdk | | | | default-jdk defaults to openjdk-10 in most architectures, so that's fine. | | It will also help with m68k which defaults to openjdk-9 at the moment (I | | guess it will be updated once openjdk-10 is bootstrapped there). | | | | Can you update that? | | Very interesting. That had never been suggested. I will give that shot. | The r-cran-rjava package will need it too. Uploaded as r-base_3.5.0-4 We have the annual "R in Finance" conference I co-organize for its 10th year this weekend so I likely won't get to manual uploads of binary: all packages for a few days. Dirk | Dirk | | | Thanks, | | Emilio | | -- | http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#896667: transition: r-base-3.5
On 31 May 2018 at 09:25, Emilio Pozuelo Monfort wrote: | On 31/05/18 00:13, Dirk Eddelbuettel wrote: | > | > On 30 May 2018 at 23:40, Emilio Pozuelo Monfort wrote: | > | curl migrated to testing today. Please go ahead with R 3.5. | > | > Yay!! Thank you -- and r-base_3.5.0-3 is now in incoming awaiting inclusion | > into unstable. | | Cool, it's almost built everywhere now. | | There are a few architectures where it can't built due to openjdk though. | I see you changed the build-dependency to: | | openjdk-10-jdk | default-jdk [!arm !hppa !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386] Yes, that was the most recent bug report on it to reflect Java 10. | The buildds only take into account the first alternative, but since they don't | have openjdk-10 they can't build r-base. One option is to put the architecture | list in the first part, e.g. by swapping the order: | | default-jdk [!arm !hppa !kfreebsd-i386 !kfreebsd-amd64 !hurd-i386] | openjdk-10-jdk | | default-jdk defaults to openjdk-10 in most architectures, so that's fine. | It will also help with m68k which defaults to openjdk-9 at the moment (I | guess it will be updated once openjdk-10 is bootstrapped there). | | Can you update that? Very interesting. That had never been suggested. I will give that shot. The r-cran-rjava package will need it too. Dirk | Thanks, | Emilio -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#896667: transition: r-base-3.5
On 30 May 2018 at 23:40, Emilio Pozuelo Monfort wrote: | Control: tags -1 confirmed | | On 28/05/18 15:00, Emilio Pozuelo Monfort wrote: | > On 28/05/18 14:32, Dirk Eddelbuettel wrote: | >> | >> On 28 May 2018 at 14:08, Emilio Pozuelo Monfort wrote: | >> | Control: tags -1 - confirmed | >> | | >> | On 28/05/18 13:08, Emilio Pozuelo Monfort wrote: | >> | > Control: tags -1 confirmed | >> | > | >> | > On 23/04/18 13:57, Sébastien Villemot wrote: | >> | >> Package: release.debian.org | >> | >> Severity: normal | >> | >> User: release.debian@packages.debian.org | >> | >> Usertags: transition | >> | >> X-Debbugs-Cc: debia...@lists.debian.org | >> | >> | >> | >> Dear Release Team, | >> | >> | >> | >> Please schedule a transition for R 3.5, which has just been uploaded to | >> | >> experimental. | >> | >> | >> | >> Due to changes in R internals, all R extension packages must be recompiled, | >> | >> that is 573 packages (of which 260 are arch:all, and will therefore need | >> | >> sourceful uploads). | >> | >> | >> | >> The transition will be managed jointly by Dirk Eddelbuettel and the Debian R | >> | >> Packages Team¹ (which ideally should be kept in CC of replies). | >> | >> | >> | >> We have not tried to recompile the 500+ packages, but we don’t expect any major | >> | >> issue. And should some arise, we stand ready to fix them. | >> | > | >> | > Go ahead with the transition. | >> | | >> | NACK. Let's wait for the curl transition, as this would clash with that one. | >> | >> What is your expectation concerning the timeline? | >> | >> R 3.5.0 is already over one month old. It would be good to have the | >> transition going. | > | > This can go after the curl transition, which has just started. So whatever that | > takes, which will depend on whether any packages fail to build and how long it | > takes to solve them. curl was waiting for longer and is blocking other | > transitions, so that's why it went first, but after that there should be no | > blockers for R 3.5. | | curl migrated to testing today. Please go ahead with R 3.5. Yay!! Thank you -- and r-base_3.5.0-3 is now in incoming awaiting inclusion into unstable. Dirk | Emilio -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#896667: transition: r-base-3.5
On 28 May 2018 at 14:08, Emilio Pozuelo Monfort wrote: | Control: tags -1 - confirmed | | On 28/05/18 13:08, Emilio Pozuelo Monfort wrote: | > Control: tags -1 confirmed | > | > On 23/04/18 13:57, Sébastien Villemot wrote: | >> Package: release.debian.org | >> Severity: normal | >> User: release.debian@packages.debian.org | >> Usertags: transition | >> X-Debbugs-Cc: debia...@lists.debian.org | >> | >> Dear Release Team, | >> | >> Please schedule a transition for R 3.5, which has just been uploaded to | >> experimental. | >> | >> Due to changes in R internals, all R extension packages must be recompiled, | >> that is 573 packages (of which 260 are arch:all, and will therefore need | >> sourceful uploads). | >> | >> The transition will be managed jointly by Dirk Eddelbuettel and the Debian R | >> Packages Team¹ (which ideally should be kept in CC of replies). | >> | >> We have not tried to recompile the 500+ packages, but we don’t expect any major | >> issue. And should some arise, we stand ready to fix them. | > | > Go ahead with the transition. | | NACK. Let's wait for the curl transition, as this would clash with that one. What is your expectation concerning the timeline? R 3.5.0 is already over one month old. It would be good to have the transition going. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: [BUMP] r-cran-readstata13 had five weeks in NEW queue for two uploads
On 14 October 2017 at 22:00, Adam D. Barratt wrote: | On Sat, 2017-10-14 at 12:59 -0500, Dirk Eddelbuettel wrote: | > Bumping this as my mail to ftpmaster went unanswered. | > | > Could someone please remind me who to ask about the NEW Queue? It is | > causing | > me a FTBFS as I need this Build-Depends for an existing package which | > itself | > has reasonably wide-spread (for an R package) reverse dependencies. | > | | If it's in the NEW queue, the only people who can do anything about it | are by definition the FTP Team. Thanks for confirming. My email went unanswered which is why I came here. I will try ftpmasters in the future, should the need arise. Thanks for all all of you do. We could not do this without you. It is appreciated. Dirk, back to packaging though probably tomorrow -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: [BUMP] r-cran-readstata13 had five weeks in NEW queue for two uploads
On 14 October 2017 at 21:59, Chris Lamb wrote:
| Dirk Eddelbuettel wrote:
|
| > The passive-aggressive "we won't work on your package, and won't tell you
| > why" is a wee bit annoying.
|
| This is an uncharitable interpretation of the situation. There is no
| deliberate witholding of information from you or any other maintainer;
| I — and the rest of the FTP team — are simply busy people.
Ok, let me rephrase. "At times in the past" there were delays simply do you
ftpmasters now expecting (in the case of R packages) debian/README.source to
explain the (data, binary, but for R also always already documented) .rda
files.
It would be so much simpler if "we" could just read the output, if any, that
is holding things back. The new package tracker is great and shows a lot,
but in order _for us to help you_ we need to know what you want us to change.
| Anyway, I've processed your package. Please fix the missing attributions
Thank you!
| to (at least) Thomas Lumley on your next upload and, if possible, think
He is not listed in DESCRIPTION:
Authors@R: c(
person("Jan Marvin", "Garbuszus",
email = "jan.garbus...@ruhr-uni-bochum.de", role = c("aut")),
person("Sebastian", "Jeworutzki",
email="sebastian.jeworut...@ruhr-uni-bochum.de", role = c("aut", "cre")),
person("R Core Team", role="cph"),
person("Magnus Thor", "Torfason", role="ctb"),
person("Luke M.", "Olson", role="ctb"),
person("Giovanni", "Righi", role="ctb")
)
though "R Core" is, and for many years they (ie R Core) assume copyright
jointly.
Where would you want me to make the attribution? debian/copyright?
| carefully about making emotional requests on -devel in future.
I will try. And where please should I send requests to ftpmaster ?
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
[BUMP] r-cran-readstata13 had five weeks in NEW queue for two uploads
Bumping this as my mail to ftpmaster went unanswered. Could someone please remind me who to ask about the NEW Queue? It is causing me a FTBFS as I need this Build-Depends for an existing package which itself has reasonably wide-spread (for an R package) reverse dependencies. On 12 October 2017 at 06:39, Dirk Eddelbuettel wrote: | | Hi guys, | | Package r-cran-readstata13 is now a required build-dependency of another | package we had in Debian for a decade. So I prepared r-cran-readstata13 five | weeks ago, and followed up with a revision a week ago (adding README.source). | | Could you tell why the package is still in NEW and what is holding it back | from migrating to unstable? Without any information it is somewhat hard to | achieve progress here... And as a build-dependency, not providing it leaves | me no choice but to remove another set of packages from Debian as I can no | longer update the other package. Anyone who can help? The passive-aggressive "we won't work on your package, and won't tell you why" is a wee bit annoying. Dirk | | Thanks, Dirk | | -- | http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#868558: Would you please not upload new r-* packages until transition is finalised (Re: r-api-3.4)
On 12 October 2017 at 22:32, Johannes Ranke wrote: | Am Donnerstag, 12. Oktober 2017, 12:01:14 CEST schrieb Dirk Eddelbuettel: | | > So we did this 71 times, but stopped 4+ years ago. Not sure what got the | > toolchain coughing, but I guess we could try again. | | texi2dvi used to trip over ~ in path names, so for locally building backports | we used to rename the directory that the source was extracted to, substituting | "~" by "-" before building. But I don't know if that was the reason for Dirk | to change the scheme. | | It seems that this was fixed in texi2dvi upstream | | http://svn.savannah.gnu.org/viewvc/texinfo/trunk/util/texi2dvi? | r1=7199=7200 It definitely was involved as "guilty party" once, then got fixed upstream -- and it may have regressed. Worth trying again though. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#868558: Would you please not upload new r-* packages until transition is finalised (Re: r-api-3.4)
On 12 October 2017 at 17:45, Graham Inggs wrote: | Hi Dirk | | On 12/10/2017 16:37, Dirk Eddelbuettel wrote: | > And yes, the hint re 3.5 being shaky leads itself to uploading to experimental. | | Would you please consider versioning such uploads as 3.5~something | instead of 3.4.something? | | e.g. your second-to-last upload of r-base was 3.4.1.20170921-1 | I think it would have been clearer if it were versioned 3.4.2~20170921-1 | or even 3.4.2~rc1-1 | | This also allows for things like Depends: r-base-core (>= 3.4.2~) should | they ever be needed. Could do, I think, and once did. Grep'ing debian/changelog: edd@bud:~$ grep "^r-base.*\~" src/debian/R/R-3.4.2/debian/changelog | wc -l 71 edd@bud:~$ grep "^r-base.*\~" src/debian/R/R-3.4.2/debian/changelog | head r-base (3.0.1~20130512-1) unstable; urgency=low r-base (3.0.0~20130330-1) unstable; urgency=low r-base (3.0.0~20130327-1) unstable; urgency=low r-base (3.0.0~20130324-1) unstable; urgency=low r-base (2.15.3~20130327-1) unstable; urgency=low r-base (2.15.3~20130326-1) unstable; urgency=low r-base (2.15.3~20130324-1) unstable; urgency=low r-base (2.15.1~20120617-1) unstable; urgency=low r-base (2.15.0~20120323-1) unstable; urgency=low r-base (2.15.0~20120317-1) unstable; urgency=low edd@bud:~$ So we did this 71 times, but stopped 4+ years ago. Not sure what got the toolchain coughing, but I guess we could try again. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#868558: Would you please not upload new r-* packages until transition is finalised (Re: r-api-3.4)
On 12 October 2017 at 16:18, Sébastien Villemot wrote: | On Thu, Oct 12, 2017 at 09:13:54AM -0500, Dirk Eddelbuettel wrote: | > | > On 12 October 2017 at 15:58, Sébastien Villemot wrote: | > | Thanks Charles for explaining this. | > | | > | Actually the migration has already happened, thanks to the Release Team that | > | took appropriate action to mitigate the impact of the most recent uploads. | > | | > | This will soon be reflected in the tracker and various web pages. | > | | > | R-related uploads can therefore be resumed. | > | > Nice. | > | > Was there a way to read that off the (otherwise very impressive and helpful) | > tracker status page? Or was is somewhere else? | | For the moment you can only see it on the main archive database: | | $ rmadison r-base | r-base | 2.15.1-4 | oldoldstable | source, all | r-base | 3.1.1-1| oldstable-kfreebsd | source, all | r-base | 3.1.1-1+deb8u1 | oldstable | source, all | r-base | 3.3.3-1~bpo8+1 | jessie-backports | source, all | r-base | 3.3.3-1| stable | source, all | r-base | 3.4.2-1| testing| source, all | r-base | 3.4.2-1| unstable | source, all | | > This was a good dry run. Come R 3.5.0 next April we actually MUST rebuild | > all packages rather than just doing it because we can. I'll circle back | > closer to the date, the r-devel branch upstream is still a little shaky. | | Ok, looking forward to it. | | When it is ready, please follow the transition guidelines which are summarized | there: | | https://wiki.debian.org/Teams/ReleaseTeam/Transitions | | The short version of it is: please open a transition bug and wait for an ack | from the Release Team *before* uploading R 3.5 to unstable (but of course you | are free to upload to experimental sooner). Rest assurred I will definitely circle back with you and Charles :-) Debian work can still be a pleasure when you get some work done with clueful people. And yes, the hint re 3.5 being shaky leads itself to uploading to experimental. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#868558: Would you please not upload new r-* packages until transition is finalised (Re: r-api-3.4)
On 12 October 2017 at 15:58, Sébastien Villemot wrote: | Thanks Charles for explaining this. | | Actually the migration has already happened, thanks to the Release Team that | took appropriate action to mitigate the impact of the most recent uploads. | | This will soon be reflected in the tracker and various web pages. | | R-related uploads can therefore be resumed. Nice. Was there a way to read that off the (otherwise very impressive and helpful) tracker status page? Or was is somewhere else? This was a good dry run. Come R 3.5.0 next April we actually MUST rebuild all packages rather than just doing it because we can. I'll circle back closer to the date, the r-devel branch upstream is still a little shaky. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Bug#868558: Would you please not upload new r-* packages until transition is finalised (Re: r-api-3.4)
On 12 October 2017 at 14:38, Gianfranco Costamagna wrote: | Hello, | | >s/you/Seb/ to make it correct. Not my transition at all. | | who-uploads r-base | Uploads for r-base: | 3.4.2-1 to unstable: Dirk Eddelbuettel <e...@debian.org> | 3.4.1.20170921-1 to unstable: Dirk Eddelbuettel <e...@debian.org> | 3.4.1-2 to unstable: Dirk Eddelbuettel <e...@debian.org> In reverse order: 3.4.1 released in June, still handicapped by the bullshit non-bug report by Johannes that lead to all this 3.4.1.20170921 standard one-week pre-release RC build 3.4.2 released Sep 28 on the announced date after weeks of planning The "tag" you kids you badly wanted was introduced with 3.4.2, and hence as a test with the to-be-replaced-anyway 3.4.1.20170921. In short, you seem to not really know what you're talking about. But at least you make up for in volume. | yes, I would say this is *your* transition. No, I played along as maintainer of r-base when my still-simpler approach was rejected. The transition was argued for, and then handled, by other people. That is still not "my transition". Dirk | You tried your best to make it go in testing (even if you seems to be trying to hide it), and once you got | the ack you continued to do uploads, delaying it and forcing Release Team to urgent packages with zero | day delays. | | Waiting some more days would have made people happier, and things better (e.g. packages migrating with some | testing instead of forcing them). | | just my .02$ | | (I keep the opportunity to also close this shameful bug). | | G. | | [DELETED ATTACHMENT signature.asc, application/pgp-signature] -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#868558: Would you please not upload new r-* packages until transition is finalised (Re: r-api-3.4)
On 12 October 2017 at 14:26, Andreas Tille wrote: | On Thu, Oct 12, 2017 at 07:06:33AM -0500, Dirk Eddelbuettel wrote: | > | > On 12 October 2017 at 11:36, Andreas Tille wrote: | > | yesterday you uploaded | > | | > | r-cran-rcpparmadillo 0.8.100.1.0-1 | > | | > | In the interest to close the transition bug opened you opened yourself | > | > s/opened// to make it a sentence | > | > s/you/Seb/ to make it correct. Not my transition at all. | | | Debian Bug report logs - #868558 | transition: r-api-3.4 | Package: release.debian.org; Maintainer for release.debian.org is Debian Release Team <debian-release@lists.debian.org>; | Reported by: Dirk Eddelbuettel <e...@debian.org> | | | Could you please regardless whether you consider yourself involved into | the bug that lists you as reporter respect the intention of your fellow | DDs to finalise the transition and wait with uploading new r-* packages. You. Still, Don't. Get. It. I argued for several weeks for a more surgical binNMUs of 46 packages. But it was decided that we needed to force a rebuild of 500+ packages instead. I proposed the former. You talk about the latter. You don't seem to understand that they are not the same. Dirk | | Thank you | | Andreas. | | -- | http://fam-tille.de -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#868558: Would you please not upload new r-* packages until transition is finalised (Re: r-api-3.4)
On 12 October 2017 at 11:36, Andreas Tille wrote: | Hi Dirk, | | yesterday you uploaded | | r-cran-rcpparmadillo 0.8.100.1.0-1 | | In the interest to close the transition bug opened you opened yourself s/opened// to make it a sentence s/you/Seb/ to make it correct. Not my transition at all. Dirk | it would be helpful if you would not upload r-* packages as long as the | testing migration has not happened. | | Thank you | | Andreas. | | On Sat, Sep 23, 2017 at 11:58:20AM -0500, Dirk Eddelbuettel wrote: | > | > See below for upcoming R 3.4.2 "pre-release" change. | > | > I still consider this to be techically inferior and conceptually wrong and | > inadequate, but there is little else than I can do about it. | > | > May I assume that some of you who sp tiredlessly argued for it will now liase | > with the release team to get 500+ forcefully rebuilt? | > | > Dirk | > | > | > r-base (3.4.1.20170921-1) unstable; urgency=medium | > | > * Initial rc build (r73337) of R 3.4.2 expected for Sep 28 | > | > * debian/control: Package r-base-core now 'Provides: r-api-3.4' per the | > Debian Release team. I still consider this to be wrong (as there was | > no API change) but my hands are tied here. | > | > * debian/compat: Increased to 9 | > | > -- Dirk Eddelbuettel <e...@debian.org> Sat, 23 Sep 2017 11:49:56 -0500 | > | > | > -- | > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org | > | > | | -- | http://fam-tille.de -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]
On 29 September 2017 at 16:23, Andreas Tille wrote: | On Fri, Sep 29, 2017 at 09:11:41AM -0500, Dirk Eddelbuettel wrote: | > | > | rebuild against r-api-3.4 to upload r-cran-dplyr. | > | > It so happens that I (as upstream) got Rcpp 0.12.13 onto CRAN yesterday too, | > so I owe Debian a new r-cran-rcpp_0.12.13. | > | > However, I had local server issues and some other things pop so I did not get | > to this. It if holds you up, just do a NMU for 0.12.12. | | No big hurry on my side - I have sufficient other things to do until this | will hit the archive. | | > | R-cran-dplyr also needs manual upload of r-cran-pkgkitten. | > | > Man this process is so stopid as I tried to explain to everybody (release | > team in particular) and failed. | > | > That is a binary:all package (also by me as upstream) which should not have | > needed a new tag if only we'd been rational. | | Would you please stop shouting Get a life. Dirk | and just tell me whether I should NMU or | not? | | Thank you | | Andreas. | | -- | http://fam-tille.de -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]
On 29 September 2017 at 15:24, Andreas Tille wrote: | On Fri, Sep 29, 2017 at 02:37:19PM +0200, Andreas Tille wrote: | > On Fri, Sep 29, 2017 at 05:59:54AM -0500, Dirk Eddelbuettel wrote: | > > | > > dplyr just had a new upstream CRAN release 0.7.4 yesterday. Don't know about | > > the others as I am less close to BioConductor. | > | > I'll upload new version soon | | I have no idea why r-cran-rcpp was not bin-NMU-ed but I would need a I cannot comment on that. | rebuild against r-api-3.4 to upload r-cran-dplyr. It so happens that I (as upstream) got Rcpp 0.12.13 onto CRAN yesterday too, so I owe Debian a new r-cran-rcpp_0.12.13. However, I had local server issues and some other things pop so I did not get to this. It if holds you up, just do a NMU for 0.12.12. | R-cran-dplyr also needs manual upload of r-cran-pkgkitten. Man this process is so stopid as I tried to explain to everybody (release team in particular) and failed. That is a binary:all package (also by me as upstream) which should not have needed a new tag if only we'd been rational. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]
On 29 September 2017 at 15:11, Graham Inggs wrote: | On 29 September 2017 at 12:59, Dirk Eddelbuettel <e...@debian.org> wrote: | > On 29 September 2017 at 07:36, Graham Inggs wrote: | > | rgtk2 and rggobi now FTBFS on s390x, they also fail in a Buster chroot | > | on zelenka.debian.org so I don't believe it is a regression in R, but | > | the binaries will need to be removed. | > | > Can you share details? Those are big/old gtk packages. And when you mean | > binaries removed you mean for s390x only or for all? | | I didn't keep the build log from zelenka, but you can view a build log | from Ubuntu [3] by following the 's390x' link. | I mean only the s390x binaries removed. Gotcha. RGtk2 wraps the old gtk libraries, rggobi is one of the few packages (within Debian) using it. It may well be that these don't build (as RGtk is rather demanding). We could entertain removing them. But for as long as they build on the major arches may as well keep them. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]
On 29 September 2017 at 07:36, Graham Inggs wrote: | I've been working on this transition in Ubuntu and here are some of my notes: | | rgtk2 and rggobi now FTBFS on s390x, they also fail in a Buster chroot | on zelenka.debian.org so I don't believe it is a regression in R, but | the binaries will need to be removed. Can you share details? Those are big/old gtk packages. And when you mean binaries removed you mean for s390x only or for all? | | r-bioc-iranges, r-bioc-variantannotation and r-cran-dplyr need to be | updated to work with R 3.4.2. You can see from the autopkgtest dplyr just had a new upstream CRAN release 0.7.4 yesterday. Don't know about the others as I am less close to BioConductor. | results [1][2] that started failing on 2017-09-24. Unfortunately, | r-cran-dplyr 0.5.0-1 has always failed its autopkgtests, so the | results aren't useful. dplyr 0.5.0 is ridiculously outdated that it is (IMHO) probably not worth looking at. That should have become 0.6.* and 0.7.* a few times over. For what it is worth all my systems do of course have current dplyr, but I install that directly from CRAN into /usr/local. Dirk | | [1] https://ci.debian.net/packages/r/r-bioc-iranges/unstable/amd64/ | [2] https://ci.debian.net/packages/r/r-bioc-variantannotation/unstable/amd64/ -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]
On 28 September 2017 at 22:22, Andreas Tille wrote: | I wonder if we could teach dh-r to make sure that is added to arch:all | packages. I'm converting all packages I'm touching to dh-r anyway. | | At least a lintian warning might help. | | Kind regards | | Andreas (after having uploaded 4 arch:all packages and converted |two of these from cdbs to dh-r) Yes, maybe indeed. dh-r is one of those many things on the always-growing TODO list that I have not yet gotten to. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]
On 28 September 2017 at 18:53, Sébastien Villemot wrote: | On Thu, Sep 28, 2017 at 07:04:51AM -0500, Dirk Eddelbuettel wrote: | > | > On 28 September 2017 at 13:20, Sébastien Villemot wrote: | > | On Thu, Sep 28, 2017 at 12:53:10PM +0200, Graham Inggs wrote: | > | > On 28/09/2017 12:28, Sébastien Villemot wrote: | > | > > Note that there are many arch:all R packages that will need sourceful upload | > | > > (they are easy to identify on the transition tracker whose URL is above). | > | > | > | > Besides r-cran-nlp which doesn't show up in the tracker, I've found several | > | > other arch:all packages that don't depend on r-api-3, but do pick up a | > | > dependency on r-api-3.4 after a rebuild: | > | | > | This makes me wonder whether arch:all packages really need a dependency on r-api-*. | > | | > | If this value really tracks an API, as advertised, it makes sense. But if it | > | actually tracks an ABI, as in the present case, then this situation is | > | suboptimal and complicates transition. | > | | > | Maybe the best solution would therefore be to dissociate API and ABI tracking. | > | | > | Moreover, packages automatically pick up a versioned dependency on r-base-core. | > | But this should not be necessary since we now have ABI tracking. It makes | > | dependencies uselessly tight. | > | | > | Anyways, these (potential) improvements should probably wait for the next | > | transition (planned in April if I understand correctly). | > | > There transitions, and then there are transitions. Let me explain: | > | > - right now a subset of 'source: any' package needs a rebuild; here we could | > in fact discuss leaving 'source: all' out | > | > - R 3.5.0 will need a rebuild of all 'source: any' packages | > | > - In the past we rebuilds for nonAPI reasons: reorganisation of R's internal | > help system (and internal file format) was one | > | > So we may as well through the big mantle of the so-called "API" transition | > around all dependent packages. But we don't _have to_ right now. | > | > Can be argued either way. Do as you see fit. | | I now understand that we ideally need two API/ABI-like values instead of one: | | - one that is bumped when only arch:any packages need to be rebuilt | | - the other one that is bumped when both arch:any and arch:all packages should | be rebuilt | | The first value would appear in the Depends of arch:any package, but not of | arch:all ones; the second value would appear in the Depends of both arch:any | and arch:all. | | Because, for this transition and for the next one (in April), we will have to | make sourceful uploads of ~170 arch:all packages… that actually do not need to | be rebuilt. And this is very painful because it must be done manually (contrary | to rebuilds of arch:any packages that can be trigerred easily). | | If we adopted this scheme right now, that would save us a lot of work for the | April transition (but not for this one, because we first have to convert | arch:all packages to the new scheme). | | Please tell me what you think. Well, sorry, but that is your baby now. I argued _this very issue of it being different for R_ for two months or more, but nobody bought into it. You all insisted on this approach which you now find more complicate, so here it is. Your deal now. (For what it is worth, and the R / Debian itersection in particular, the RcppAPT (source) package allows you to query R's and Debian's package meta-data. That was part of my analysis so I won't repeat it. Happy to help if there are questions.) I'll happily deal with / help with technical questions, I am not that interested in managing a technical issue I argued (in vain) against for some time. Sorry, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]
On 28 September 2017 at 13:20, Sébastien Villemot wrote: | On Thu, Sep 28, 2017 at 12:53:10PM +0200, Graham Inggs wrote: | > On 28/09/2017 12:28, Sébastien Villemot wrote: | > > Note that there are many arch:all R packages that will need sourceful upload | > > (they are easy to identify on the transition tracker whose URL is above). | > | > Besides r-cran-nlp which doesn't show up in the tracker, I've found several | > other arch:all packages that don't depend on r-api-3, but do pick up a | > dependency on r-api-3.4 after a rebuild: | | This makes me wonder whether arch:all packages really need a dependency on r-api-*. | | If this value really tracks an API, as advertised, it makes sense. But if it | actually tracks an ABI, as in the present case, then this situation is | suboptimal and complicates transition. | | Maybe the best solution would therefore be to dissociate API and ABI tracking. | | Moreover, packages automatically pick up a versioned dependency on r-base-core. | But this should not be necessary since we now have ABI tracking. It makes | dependencies uselessly tight. | | Anyways, these (potential) improvements should probably wait for the next | transition (planned in April if I understand correctly). There transitions, and then there are transitions. Let me explain: - right now a subset of 'source: any' package needs a rebuild; here we could in fact discuss leaving 'source: all' out - R 3.5.0 will need a rebuild of all 'source: any' packages - In the past we rebuilds for nonAPI reasons: reorganisation of R's internal help system (and internal file format) was one So we may as well through the big mantle of the so-called "API" transition around all dependent packages. But we don't _have to_ right now. Can be argued either way. Do as you see fit. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]
On 24 September 2017 at 15:36, Sébastien Villemot wrote: | Control: reopen -1 | Control: retitle -1 transition: r-api-3.4 | Control: user release.debian@packages.debian.org | Control: usertags -1 = transition | | On Sun, Sep 10, 2017 at 04:15:00PM +, Niels Thykier wrote: | | > To be perfectly, honest, I would prefer if you did a proper ABI-like | > transition over the Breaks. At this scale, Breaks seems too fragile and | > too likely for people to get wrong. | | The latest upload of r-base, versioned 3.4.1.20170921-1, has bumped the ABI | pseudo package from "r-api-3" to "r-api-3.4", as requested. | | Please therefore schedule rebuilds as necessary. | | The ben file should look like: | | title = "r-api-3.4"; | is_affected = .depends ~ /r-api-3(\.4)?/; | is_good = .depends ~ /r-api-3\.4/; | is_bad = .depends ~ /r-api-3\b/; | | Thanks, This is somewhat the wrong bug report to attach this to as I argued (sadly, in vain) for a different approach here in #868558. Maybe #861333, retitled by Don to 'API transition of R packages' would have been more approriate. I would just have filed a new one. But then I don't know those commands so thanks for doing this. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Bug#868558: nmu: multiple r-* packages
On 11 September 2017 at 18:00, Andreas Tille wrote: | On Mon, Sep 11, 2017 at 08:55:58AM -0500, Dirk Eddelbuettel wrote: | > | > On 11 September 2017 at 15:36, Andreas Tille wrote: | > | IMHO the best way to deal with this would have been by doing a mass bug | > | filing against those packages which were in need of an upgrade. This | > | would have attracted the attention of the according maintainers directly | > | and would have led to action more quickly (at least I confirm this in my | > | case). | > | > The Policy manual advises against doing that. | | What section are you refering to? I always confuse the different manuals. The language that discourage me is here and uses 10 as an upper limit: https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#submit-many-bugs So I went the route of preparing binNMUs. In hindsight I did not get the outcome I desired, but for different reasons. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Bug#868558: nmu: multiple r-* packages
On 11 September 2017 at 15:36, Andreas Tille wrote: | IMHO the best way to deal with this would have been by doing a mass bug | filing against those packages which were in need of an upgrade. This | would have attracted the attention of the according maintainers directly | and would have led to action more quickly (at least I confirm this in my | case). The Policy manual advises against doing that. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Re: Bug#868558: nmu: multiple r-* packages
On 10 September 2017 at 16:15, Niels Thykier wrote: | To be perfectly, honest, I would prefer if you did a proper ABI-like | transition over the Breaks. At this scale, Breaks seems too fragile and | too likely for people to get wrong. I *am* -- all packages (currently) get have r-api-3: edd@bud:~$ apt-cache show r-cran-rcpp | grep r-api-3 Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libstdc++6 (>= 5.2), r-base-core (>= 3.3.1-1), r-api-3, littler, r-cran-pkgkitten edd@bud:~$ | Next April they will have r-api-4. *This case* did not warrant puzting with r-api-* and you will have to take my word for it. | > Dear debian-release: Please remove this block. | > | I respectfully decline. That's truly and madly saddening. So I will just code around you and direct users to a different repo. We have been doing that via an informal backports repo available at all CRAN mirrors anyway. It's too bad, but we all have our standards to live by. Apparently I am now rogue as far as the release teams goes. Life goes on. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
