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 <edd@debian.org>

Date: Sun, 16 Jul 2017 15:42:02 UTC

Severity: normal

Tags: confirmed

Done: Gianfranco Costamagna <locutusofborg@debian.org>

Bug is archived. No further changes may be made.

Forwarded to https://release.debian.org/transitions/html/r-base-3.4.html

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox

Report forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Sun, 16 Jul 2017 15:42:04 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
New Bug report received and forwarded. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sun, 16 Jul 2017 15:42:05 GMT) (full text, mbox, link).

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

Package: release.debian.org
User: release.debian.org@packages.debian.org
Usertags: binnmu
Severity: normal

R 3.4.0, which was released in April, made one subtle breaking change
affecting how (optional) compiled code in contributed package is loaded,
affecting the older two of the three (plus one internal) available
mechanisms:  .C() and .Fortran().  Packages still load and run parts of
their code, they just can no longer access this compiled code---unless
rebuilt. 

This has been discussed in #86133 at https://bugs.debian.org/861333

I have now prepared a fine-grained set of packages requiring a NMU, narrowing
the actual set of required rebuilds down from an unconditional 514 packages
(all reverse depends of r-base-core) to 92 packages meeting all requirements.

  nmu r-bioc-makecdfenv_1.50.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-multtest_2.30.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-edger_3.14.0+dfsg-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-boolnet_2.1.3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-tikzdevice_0.10-1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-logspline_2.1.9-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-genabel_1.8-0-1+b1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-lhs_0.14-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-limma_3.30.8+dfsg-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-coin_1.1-3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-other-iwrlars_0.9-5-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-mnp_2.6-4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-msm_1.6.4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-fields_8.10-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-desolve_1.14-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-adephylo_1.1-10-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-dosefinding_0.9-15-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-deldir_0.1-12-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-rniftilib_0.0-35.r79-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-data.table_1.10.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-qtl_1.40-8-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-preprocesscore_1.36.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-contfrac_1.1-10-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-glmnet_2.0-5-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-bitops_1.0-6-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-sp_1:1.2-4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-spc_1:0.5.3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-snpstats_1.24.0+dfsg-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-tgp_2.4-14-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-brglm_0.5-9-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-cmprsk_2.2-7-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-affy_1.52.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-ncdf4_1.15-1+b2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-treescape_1.10.18-6 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-rbgl_1.50.0+dfsg1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-rtracklayer_1.34.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-hexbin_1.27.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-princurve_1.1-12-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-mapproj_1.2-4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-blockmodeling_0.1.8-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-hdf5_1.6.10-4+b1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-pscl_1.4.9-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-ade4_1.7-5-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-vgam_1.0-3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-adegenet_2.0.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-mixtools_1.0.4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-phylobase_0.8.2-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-amelia_1.7.4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-spam_1.4-0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-medadherence_1.03-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-biobase_2.34.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-surveillance_1.13.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-randomfieldsutils_0.3.15-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-deal_1:1.2-37-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-hilbertvis_1.32.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-rcurl_1.95-4.8-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-other-mott-happy.hbrem_2.4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-mcmcpack_1.3-8-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-spatstat_1.48-0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-vegan_2.4-2-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-haplo.stats_1.7.7-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-bayesm_3.0-2-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-expm_0.999-0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-dnacopy_1.48.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-phangorn_2.1.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-maptools_1:0.8-41+dfsg-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-mlbench_2.1-1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-affyio_1.44.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-graph_1.52.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-polycub_0.5-2-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-deseq2_1.14.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-pbivnorm_0.6.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-caret_6.0-73+dfsg1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-biovizbase_1.22.0-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-nnls_1.4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-goftest_1.0-3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-igraph_1.0.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-maps_3.1.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-eco_3.1-7-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-catools_1.17.1-1+b1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-randomfields_3.1.36-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-erm_0.15-7-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-etm_0.6-2-3 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-randomforest_4.6-12-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-evd_2.3-2-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-raschsampler_0.8-8-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-bioc-genefilter_1.56.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-mcmc_0.9-4-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-spdep_0.6-9-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-gam_1.14-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-other-amsmercury_1.3.0-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
  nmu r-cran-gsl_1.9-10.3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
   
I have provided extensive details of how I derived this set in this vignette:
  
  http://eddelbuettel.github.io/rcppapt/binnmuAfterR340.html

Its code is part of the (still somewhat unpolished but fully working for a
subset of apt's functionality) package RcppAPT at

  https://github.com/eddelbuettel/rcppapt

The package interfaces `libapt-pkg`; the package sources also contain the
vignette source and should allow anyone to replicate the analysis (modulo the
one step where I take advantage of having access to fully expanded CRAN
mirror to grep through a subset of packages, see the write-up for more).

I hope the write-up in the vignette provides sufficient detail.

If you have questions please to not hesitate to contact me directly, or
follow-up at either this ticket, or the r-base-core ticket #86133, or on the
r-sig-debian mailing list.

Many thanks in advance for your help with this.

Cheers, Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Sat, 29 Jul 2017 14:12:03 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sat, 29 Jul 2017 14:12:03 GMT) (full text, mbox, link).

Message #10 received at 868558@bugs.debian.org (full text, mbox, reply):

Dear release team,

On 16 July 2017 at 10:40, Dirk Eddelbuettel wrote:
| 
| Package: release.debian.org
| User: release.debian.org@packages.debian.org
| Usertags: binnmu
| Severity: normal
| 
| R 3.4.0, which was released in April, made one subtle breaking change
| affecting how (optional) compiled code in contributed package is loaded,
| affecting the older two of the three (plus one internal) available
| mechanisms:  .C() and .Fortran().  Packages still load and run parts of
| their code, they just can no longer access this compiled code---unless
| rebuilt. 
| 
| This has been discussed in #86133 at https://bugs.debian.org/861333
| 
| I have now prepared a fine-grained set of packages requiring a NMU, narrowing
| the actual set of required rebuilds down from an unconditional 514 packages
| (all reverse depends of r-base-core) to 92 packages meeting all requirements.
| 
|   nmu r-bioc-makecdfenv_1.50.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-bioc-multtest_2.30.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-bioc-edger_3.14.0+dfsg-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-boolnet_2.1.3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-tikzdevice_0.10-1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-logspline_2.1.9-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-genabel_1.8-0-1+b1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-lhs_0.14-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-bioc-limma_3.30.8+dfsg-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-coin_1.1-3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-other-iwrlars_0.9-5-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-mnp_2.6-4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-msm_1.6.4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-fields_8.10-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-desolve_1.14-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-adephylo_1.1-10-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-dosefinding_0.9-15-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-deldir_0.1-12-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-rniftilib_0.0-35.r79-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-data.table_1.10.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-qtl_1.40-8-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-bioc-preprocesscore_1.36.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-contfrac_1.1-10-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-glmnet_2.0-5-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-bitops_1.0-6-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-sp_1:1.2-4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-spc_1:0.5.3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-bioc-snpstats_1.24.0+dfsg-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-tgp_2.4-14-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-brglm_0.5-9-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-cmprsk_2.2-7-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-bioc-affy_1.52.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-ncdf4_1.15-1+b2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-treescape_1.10.18-6 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-bioc-rbgl_1.50.0+dfsg1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-bioc-rtracklayer_1.34.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-hexbin_1.27.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-princurve_1.1-12-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-mapproj_1.2-4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-blockmodeling_0.1.8-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-hdf5_1.6.10-4+b1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-pscl_1.4.9-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-ade4_1.7-5-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-vgam_1.0-3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-adegenet_2.0.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-mixtools_1.0.4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-phylobase_0.8.2-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-amelia_1.7.4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-spam_1.4-0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-medadherence_1.03-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-bioc-biobase_2.34.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-surveillance_1.13.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-randomfieldsutils_0.3.15-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-deal_1:1.2-37-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-bioc-hilbertvis_1.32.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-rcurl_1.95-4.8-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-other-mott-happy.hbrem_2.4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-mcmcpack_1.3-8-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-spatstat_1.48-0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-vegan_2.4-2-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-haplo.stats_1.7.7-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-bayesm_3.0-2-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-expm_0.999-0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-bioc-dnacopy_1.48.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-phangorn_2.1.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-maptools_1:0.8-41+dfsg-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-mlbench_2.1-1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-bioc-affyio_1.44.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-bioc-graph_1.52.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-polycub_0.5-2-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-bioc-deseq2_1.14.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-pbivnorm_0.6.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-caret_6.0-73+dfsg1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-bioc-biovizbase_1.22.0-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-nnls_1.4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-goftest_1.0-3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-igraph_1.0.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-maps_3.1.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-eco_3.1-7-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-catools_1.17.1-1+b1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-randomfields_3.1.36-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-erm_0.15-7-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-etm_0.6-2-3 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-randomforest_4.6-12-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-evd_2.3-2-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-raschsampler_0.8-8-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-bioc-genefilter_1.56.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-mcmc_0.9-4-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-spdep_0.6-9-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-gam_1.14-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-other-amsmercury_1.3.0-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|   nmu r-cran-gsl_1.9-10.3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
|    
| I have provided extensive details of how I derived this set in this vignette:
|   
|   http://eddelbuettel.github.io/rcppapt/binnmuAfterR340.html
| 
| Its code is part of the (still somewhat unpolished but fully working for a
| subset of apt's functionality) package RcppAPT at
| 
|   https://github.com/eddelbuettel/rcppapt
| 
| The package interfaces `libapt-pkg`; the package sources also contain the
| vignette source and should allow anyone to replicate the analysis (modulo the
| one step where I take advantage of having access to fully expanded CRAN
| mirror to grep through a subset of packages, see the write-up for more).
| 
| I hope the write-up in the vignette provides sufficient detail.
| 
| If you have questions please to not hesitate to contact me directly, or
| follow-up at either this ticket, or the r-base-core ticket #86133, or on the
| r-sig-debian mailing list.
| 
| Many thanks in advance for your help with this.

Any comment or update from your end on this bug report?  The r-base package
is still blocked from migration to testing because of #861333, and this will
address this.

Cheers,  Dirk


| 
| Cheers, Dirk
| 
| -- 
| http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Sun, 06 Aug 2017 13:18:05 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sun, 06 Aug 2017 13:18:05 GMT) (full text, mbox, link).

Message #15 received at 868558@bugs.debian.org (full text, mbox, reply):

Dear release team,

I have a follow-up.  Kurt Hornik (CC'ed as a courtesy) of the R Core team,
and also an avid Debian user, pointed out another suitable test (of checking
whether the (optional) C-level registration had actually been done in
package).  With that, the set of packages to NMU halfes from 92 to 46.

The complete analysis has been updated in the GitHub repo of the underlying R
package interfacing libapt; the visible version of the vignette has been
updated at the same URL as before:

   http://eddelbuettel.github.io/rcppapt/binnmuAfterR340.html

The updated set of NMUs follows below, and is also available raw at

   https://raw.githubusercontent.com/eddelbuettel/rcppapt/master/inst/scripts/debian-packages/nmuList.txt

Thanks also to Chris Lamb for suggesting I look into reducing the set further
which, given Kurt's suggestion, was indeed feasible.

Let's get these 46 packages rebuilt so that r-base 3.4.1 can migrate to
testing.

Thanks,  Dirk

nmu r-cran-coin_1.1-3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-mnp_2.6-4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-fields_8.10-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-desolve_1.14-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-deldir_0.1-12-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-rniftilib_0.0-35.r79-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-data.table_1.10.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-qtl_1.40-8-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-contfrac_1.1-10-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-glmnet_2.0-5-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-sp_1:1.2-4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-brglm_0.5-9-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-ncdf4_1.15-1+b2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-treescape_1.10.18-6 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-mapproj_1.2-4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-blockmodeling_0.1.8-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-hdf5_1.6.10-4+b1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-ade4_1.7-5-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-vgam_1.0-3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-mixtools_1.0.4-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-phylobase_0.8.2-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-spam_1.4-0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-medadherence_1.03-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-surveillance_1.13.0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-randomfieldsutils_0.3.15-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-rcurl_1.95-4.8-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-mcmcpack_1.3-8-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-spatstat_1.48-0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-vegan_2.4-2-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-bayesm_3.0-2-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-expm_0.999-0-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-phangorn_2.1.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-maptools_1:0.8-41+dfsg-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-caret_6.0-73+dfsg1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-goftest_1.0-3-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-igraph_1.0.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-maps_3.1.1-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-eco_3.1-7-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-randomfields_3.1.36-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-mcmc_0.9-4-2 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-spdep_0.6-9-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'
nmu r-cran-gam_1.14-1 . ANY . -m 'Rebuild against R 3.4.*, see #861333'



-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 10 Aug 2017 13:45:05 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Beckmann <anbe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 10 Aug 2017 13:45:05 GMT) (full text, mbox, link).

Message #20 received at 868558@bugs.debian.org (full text, mbox, reply):

On Sun, 6 Aug 2017 08:15:17 -0500 Dirk Eddelbuettel <edd@debian.org> wrote:
> Let's get these 46 packages rebuilt so that r-base 3.4.1 can migrate to
> testing.

Disclaimer: I don't know anything about R or the R packaging.

Isn't it possible to use some virtual r-abi-WHATEVER package(s) to make
such transitions easier to spot and manage in the future? S.t. it can be
described in a ben file instead of manually compiling a list of binNMUs.
(Ideally such a thing should be in place before performing a "last
round" of manual binNMUs).

Andreas

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 10 Aug 2017 17:06:03 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 10 Aug 2017 17:06:03 GMT) (full text, mbox, link).

Message #25 received at 868558@bugs.debian.org (full text, mbox, reply):

Hi Andreas,

On 10 August 2017 at 15:36, Andreas Beckmann wrote:
| On Sun, 6 Aug 2017 08:15:17 -0500 Dirk Eddelbuettel <edd@debian.org> wrote:
| > Let's get these 46 packages rebuilt so that r-base 3.4.1 can migrate to
| > testing.
| 
| Disclaimer: I don't know anything about R or the R packaging.

No worries.
| 
| Isn't it possible to use some virtual r-abi-WHATEVER package(s) to make
| such transitions easier to spot and manage in the future? S.t. it can be
| described in a ben file instead of manually compiling a list of binNMUs.
| (Ideally such a thing should be in place before performing a "last
| round" of manual binNMUs).

Absolutely. We _have_ that now. [1]  The r-base-core package provides it, and
each package depends on it.  Witness:

   edd@bud:~$ apt-cache show r-base-core | grep Provides | head -1
   Provides: r-api-3, r-base-latex, r-cran-rcompgen, r-gnome
   edd@bud:~$ apt-cache show r-cran-digest | grep r-api-
   Depends: libc6 (>= 2.14), r-base-core (>= 3.3.1-1), r-api-3
   edd@bud:~$ 

But the whole point of my bug report, and write up, is that

   46

out of 516 package need a rebuild.

So I continue to argue [2] that we should rebuild these 46, not force all 516.

Happy to discuss in detail in person in a video conf or call ...

Dirk


[1] Disclaimer: I resisted this a little, but it is the right thing to
do. And we *will* need it next spring when R 3.5.0 *will* bring ABI changes.

[2] http://eddelbuettel.github.io/rcppapt/binnmuAfterR340.html

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Message #30 received at 868558@bugs.debian.org (full text, mbox, reply):

Dear release team,

Gentle poke.  We still need this set of NMUs to get R 3.4.1 into testing.

"Ask me anything" -- What (if anything) is missing?  How can I help?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 25 Aug 2017 22:15:02 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 25 Aug 2017 22:15:02 GMT) (full text, mbox, link).

Message #35 received at 868558@bugs.debian.org (full text, mbox, reply):

severity 868558 serious
quit

On 19 August 2017 at 13:14, Dirk Eddelbuettel wrote:
| 
| Dear release team,
| 
| Gentle poke.  We still need this set of NMUs to get R 3.4.1 into testing.
| 
| "Ask me anything" -- What (if anything) is missing?  How can I help?

Setting severity to 'serious' which is what the one for r-base is tagged with
at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861333

I need your help here, and have not really heard from anyone.  Now that the
release and debconf are in the past, can we _please_ get to this?

Dirk

| 
| Dirk
| 
| -- 
| http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Severity set to 'serious' from 'normal' Request was from Dirk Eddelbuettel <edd@debian.org> to control@bugs.debian.org. (Fri, 25 Aug 2017 22:15:04 GMT) (full text, mbox, link).

Acknowledgement sent to Niels Thykier <niels@thykier.net>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sat, 26 Aug 2017 07:42:03 GMT) (full text, mbox, link).

Message #42 received at 868558@bugs.debian.org (full text, mbox, reply):

Dirk Eddelbuettel:
> [...]
> On 19 August 2017 at 13:14, Dirk Eddelbuettel wrote:
> | 
> | Dear release team,
> | 

Hi,

Sorry for the slow up take on our part.

> | Gentle poke.  We still need this set of NMUs to get R 3.4.1 into testing.
> | 
> | "Ask me anything" -- What (if anything) is missing?  How can I help?
> 

Before I schedule these binNMUs, then I need to understand if partial
upgrades will be handled correctly.  Notably, this case suggests that
they will not be.

If someone was to upgrade R and (for the sake of the example) a rebuilt
r-cran-logspline, what will ensure that the rest of the affected R
packages are upgraded (or removed)?

In a regular ABI bump, everything is rebuilt against a new ABI package
and the old one is (eventually) removed.  As I understand it, we are not
doing that here (nor a variant of it), so you would have to use "Breaks"
to ensure this property holds.  But while Breaks on binNMU versions is
possible, it can give you headaches if binNMU versions are not in sync
between architectures.

 * Once the above is clarified/resolved, then we can start binNMUs.

> Setting severity to 'serious' which is what the one for r-base is tagged with
> at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861333
> 

Generally, most release.d.o bug does not use severity so it does not
really affect anything (except it splits our bug ordering up, and
somebody will probably show up and fix that eventually).

Thanks,
~Niels

Message #47 received at 868558@bugs.debian.org (full text, mbox, reply):

Hi Niels et al,

On 26 August 2017 at 07:22, Niels Thykier wrote:
| Dirk Eddelbuettel:
| > [...]
| > On 19 August 2017 at 13:14, Dirk Eddelbuettel wrote:
| > | 
| > | Dear release team,
| > | 
| 
| Hi,
| 
| Sorry for the slow up take on our part.

No worries. Releases and Debconfs have a habit of getting in the way :)

So thanks for getting back to me.  It will be good to get to this.
| 
| > | Gentle poke.  We still need this set of NMUs to get R 3.4.1 into testing.
| > | 
| > | "Ask me anything" -- What (if anything) is missing?  How can I help?
| > 
| 
| Before I schedule these binNMUs, then I need to understand if partial
| upgrades will be handled correctly.  Notably, this case suggests that
| they will not be.

"this case" ?  Can you detail?  I am not following.
 
| If someone was to upgrade R and (for the sake of the example) a rebuilt
| r-cran-logspline, what will ensure that the rest of the affected R
| packages are upgraded (or removed)?

They do not need to as this is NOT an API breakage.  See it rather as a
garden-variety bug on the part of R Core. "They" have an issue affecting a
subset of dyn.loaded modules (not all, just those using .C() or .Fortran())
where the now-required changes messes things up.

This only affects isolotated calls within a package, not across-package
relationships.

It does not require 'dependent rebuilds' as it does not affect other
packages.

In sum, I am _really fairly certain_ that we "just" need these 40+ NMUs.
 
| In a regular ABI bump, everything is rebuilt against a new ABI package
| and the old one is (eventually) removed.  As I understand it, we are not
| doing that here (nor a variant of it), so you would have to use "Breaks"
| to ensure this property holds.  But while Breaks on binNMU versions is
| possible, it can give you headaches if binNMU versions are not in sync
| between architectures.

We _will_ need an ABI nump next spring when real internals change with R as
they gave two or three times in the 15+ years I maintained it.

Not this time.
 
|  * Once the above is clarified/resolved, then we can start binNMUs.

Ok.

I can try to demonstrate the "no we don't" argument by trying to see if I can
recreate the initial bug report on spatial in a testing session, then reinstall
just that (R) package locally (directly from R) where it should work.  I
should have time for that later.  Let me know if it would help.
 
| > Setting severity to 'serious' which is what the one for r-base is tagged with
| > at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861333
| > 
| 
| Generally, most release.d.o bug does not use severity so it does not
| really affect anything (except it splits our bug ordering up, and
| somebody will probably show up and fix that eventually).

Ok. Feel free to set it back.  It was mostly a device to get your attention :)

Best,  Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Message #52 received at 868558@bugs.debian.org (full text, mbox, reply):

So I tried that -- and I cannot currently tickle the bug:

 -- r-cran-spatial (from the initial bug report) was long rebuilt by me
 
 -- r-cran-logspline (which you mentioned) is actually no longer on my
    refined (shorter) list, no issues there

 -- r-cran-data.table (on my list) is a false positive, the one grep()
    find is actually in commented-out code (but hey, the maintainer is a
    slacker too as the package had two updates not reflected yet...)
    
 -- r-cran-rcurl just works too, there is one .C() call in getCurlInfo()
    and it all passes as well.

In short I can NOT currently reproduce the issue on Debian unstable.

So this may be a huge nothingburger (and another reason not to enforce an
API-tag rebuild over 500+ packages).

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Severity set to 'normal' from 'serious' Request was from "Adam D. Barratt" <adsb@coccia.debian.org> to control@bugs.debian.org. (Sun, 27 Aug 2017 18:57:07 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 01 Sep 2017 09:45:04 GMT) (full text, mbox, link).

Acknowledgement sent to Emilio Pozuelo Monfort <pochu@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 01 Sep 2017 09:45:04 GMT) (full text, mbox, link).

Message #59 received at 868558@bugs.debian.org (full text, mbox, reply):

Hi Dirk,

On 26/08/17 14:29, Dirk Eddelbuettel wrote:
> 
> So I tried that -- and I cannot currently tickle the bug:
> 
>  -- r-cran-spatial (from the initial bug report) was long rebuilt by me
>  
>  -- r-cran-logspline (which you mentioned) is actually no longer on my
>     refined (shorter) list, no issues there
> 
>  -- r-cran-data.table (on my list) is a false positive, the one grep()
>     find is actually in commented-out code (but hey, the maintainer is a
>     slacker too as the package had two updates not reflected yet...)
>     
>  -- r-cran-rcurl just works too, there is one .C() call in getCurlInfo()
>     and it all passes as well.
> 
> In short I can NOT currently reproduce the issue on Debian unstable.
> 
> So this may be a huge nothingburger (and another reason not to enforce an
> API-tag rebuild over 500+ packages).

What Niels meant is whether having an old, non-rebuilt R module with the new
r-base works, and whether having a new, rebuilt R module with the old r-base
works. Is that so? Sorry if you already answered this, but it's not clear to me
and I'm not familiar with R at all so it's possible that I missed it.

From your initial post, you say that the new R breaks loading optional code with
two of the available mechanisms. That seems to imply that having a non-rebuilt
module with the new R 3.4 would break (some things). Right?

Thanks,
Emilio

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 01 Sep 2017 11:27:07 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 01 Sep 2017 11:27:07 GMT) (full text, mbox, link).

Message #64 received at 868558@bugs.debian.org (full text, mbox, reply):

Emilio,

Thanks for your follow-up.  I will try to get to each point.

On 1 September 2017 at 11:42, Emilio Pozuelo Monfort wrote:
| What Niels meant is whether having an old, non-rebuilt R module with the new
| r-base works, 

Yes, in general, and here in this case.

| and whether having a new, rebuilt R module with the old r-base

Yes.

(You get a warning when you run, say, R 3.3.3 and load a module built with R
3.4.1: "foo was built with R 3.4.1".  But it is harmless. It still works.)

| works. Is that so? Sorry if you already answered this, but it's not clear to me
| and I'm not familiar with R at all so it's possible that I missed it.

I am.

(20 year R user; package developer; contributor; R Foundation Board member)

| >From your initial post, you say that the new R breaks loading optional code with
| two of the available mechanisms. 

Allow me to repeat and stress:

  From R (< 3.4.0) to R (>= 3.4.0) the mechanism to use dynamically-loadable
  modules via .C() and .Fortran() changed, and requires a rebuild for the
  __subset of packages have loadable modules__ and the __subset of those
  packages actually using .C() and .Fortran() and not .Call()__ and the
  __subset of those package actually deploying the (before-than optional)
  registration mechanism.

It is a subset of a subset of a subset that is affected,

I identified the subset and asked the release team for 46 binNMUs.

| That seems to imply that having a non-rebuilt module with the new R 3.4 would break (some things). Right?

I do not think so.  And I am not aware of a bug report anywhere (here in
Debian or the wider R community) seeing it.

This issue is not an ABI/API change.  We very likely will get one of those in
April with R 3.5.0.  And as it stands, we'll all just wait for that. 

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 01 Sep 2017 11:54:05 GMT) (full text, mbox, link).

Message #69 received at 868558@bugs.debian.org (full text, mbox, reply):

On 01/09/17 13:25, Dirk Eddelbuettel wrote:
> 
> Emilio,
> 
> Thanks for your follow-up.  I will try to get to each point.
> 
> On 1 September 2017 at 11:42, Emilio Pozuelo Monfort wrote:
> | What Niels meant is whether having an old, non-rebuilt R module with the new
> | r-base works, 
> 
> Yes, in general, and here in this case.

Then I don't understand why these binNMUs are needed.

From #861333 OP:

"With current R, R packages built for Debian before the upload of R
3.3.3.20170413-1
on 14 April that use .C or .Fortran do no work properly, because the functions
calling .C or .Fortran do not find the compiled objects."

That tells me that if you upgrade R but don't upgrade some modules, those will
(partially) break. Hence we need either an ABI bump, or versioned breaks against
the affected modules in r-base.

Cheers,
Emilio

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 01 Sep 2017 12:33:03 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 01 Sep 2017 12:33:03 GMT) (full text, mbox, link).

Message #74 received at 868558@bugs.debian.org (full text, mbox, reply):

On 1 September 2017 at 13:52, Emilio Pozuelo Monfort wrote:
| On 01/09/17 13:25, Dirk Eddelbuettel wrote:
| > 
| > Emilio,
| > 
| > Thanks for your follow-up.  I will try to get to each point.
| > 
| > On 1 September 2017 at 11:42, Emilio Pozuelo Monfort wrote:
| > | What Niels meant is whether having an old, non-rebuilt R module with the new
| > | r-base works, 
| > 
| > Yes, in general, and here in this case.
| 
| Then I don't understand why these binNMUs are needed.
| 
| >From #861333 OP:
| 
| "With current R, R packages built for Debian before the upload of R
| 3.3.3.20170413-1
| on 14 April that use .C or .Fortran do no work properly, because the functions
| calling .C or .Fortran do not find the compiled objects."
| 
| That tells me that if you upgrade R but don't upgrade some modules, those will
| (partially) break. Hence we need either an ABI bump, or versioned breaks against
| the affected modules in r-base.

The Bug:

   - package foo contains .C() or .Fortran and registers it
   - it is built with R 3.3.* (or any R before R 3.4.0)
   - you upgrade to R 3.4.0 tries to load that function in foo

Not a bug:

   - any other use case including staying at R 3.3.3 and using
     a package from R 3.4.0 (not that you could with Debian because all
     r-cran-* packages already impose a >= on the R that built it).

Dirk
      

| 
| Cheers,
| Emilio

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Message #79 received at 868558@bugs.debian.org (full text, mbox, reply):

On 2 September 2017 at 14:57, Steve Cotton wrote:
| On Thu, Aug 10, 2017 at 12:03:06PM -0500, Dirk Eddelbuettel wrote:
| > But the whole point of my bug report, and write up, is that
| > 
| >    46
| > 
| > out of 516 package need a rebuild.
| > 
| > So I continue to argue [2] that we should rebuild these 46, not force all 516.
| 
| If I may ask, "why?".

Because R 3.4.1 is blocked from entering testing.

"Our priorities are our users".

I personally do not care [1] but _I_ have been asked by R Core (as their
usual contact person for things Debian, which some of them use) why the
current R is still on in testing.

I am only trying to help...
 
| When you find yourself sending this to the debian-devel mailing
| list ...
| 
| > - I filed it on July 16.
| > - I followed up on July 29.
| > - I followed up on August 6.
| > - I answered a question on August 10.
| > - I followed up on August 19.
| > - I answered a question on August 26, and followed up on August 26.
| >
| > I am at wits end.
| > 
| > Dirk
| 
| ... please, consider the price it's having on your sanity.

An email every couple of weeks is nothing. If you want to question my sanity,
look at my github commits, my CRAN uploads and my r-cran-* uploads. You'd
have a much better point.
| 
| It seems that the whole set of R packages is 0.5GB of binaries.
| By comparison, a minor bugfix in texlive-bin results in a 1GB
| download for anyone who's installed it from Unstable.

What's the point?  I am not talking about texlive. I am talking about a
perfectly modular problem that is solvable.

But I am done here it seems.  No point talking to windmills.

Dirk

[1] We have active backports at CRAN for the actual 'r-base' packages, and I
happen to install all of CRAN I use in /usr/local/lib/R/site-library to have
a faster update cadence.  So I *personally* do not care.  But I want my users
to have it in testing if they want it.  Seemingly we can't have that.

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Acknowledgement sent to Steve Cotton <steve@s.cotton.clara.co.uk>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sat, 02 Sep 2017 13:30:03 GMT) (full text, mbox, link).

Message #84 received at 868558@bugs.debian.org (full text, mbox, reply):

On Thu, Aug 10, 2017 at 12:03:06PM -0500, Dirk Eddelbuettel wrote:
> But the whole point of my bug report, and write up, is that
> 
>    46
> 
> out of 516 package need a rebuild.
> 
> So I continue to argue [2] that we should rebuild these 46, not force all 516.

If I may ask, "why?".

When you find yourself sending this to the debian-devel mailing
list ...

> - I filed it on July 16.
> - I followed up on July 29.
> - I followed up on August 6.
> - I answered a question on August 10.
> - I followed up on August 19.
> - I answered a question on August 26, and followed up on August 26.
>
> I am at wits end.
> 
> Dirk

... please, consider the price it's having on your sanity.

It seems that the whole set of R packages is 0.5GB of binaries.
By comparison, a minor bugfix in texlive-bin results in a 1GB
download for anyone who's installed it from Unstable.

Regards,
Steve

Message #89 received at 868558@bugs.debian.org (full text, mbox, reply):

On Sat, Sep 02, 2017 at 08:20:00AM -0500, Dirk Eddelbuettel wrote:
> On 2 September 2017 at 14:57, Steve Cotton wrote:
> | On Thu, Aug 10, 2017 at 12:03:06PM -0500, Dirk Eddelbuettel wrote:
> | > So I continue to argue [2] that we should rebuild these 46, not force all 516.
> | 
> | If I may ask, "why?".
> 
> Because R 3.4.1 is blocked from entering testing.

I should have been more specific with my question.

If I may ask, "why do you want to spend the developer time to rebuild only 46
packages, when there's already an infrastructure that does it for you, at the
cost of rebuilding all 516"?

Regards,
Steve

Message #94 received at 868558@bugs.debian.org (full text, mbox, reply):

On 2 September 2017 at 19:23, Steve Cotton wrote:
| If I may ask, "why do you want to spend the developer time to rebuild only 46
| packages, when there's already an infrastructure that does it for you, at the
| cost of rebuilding all 516"?

Because in my 20+ years with Debian, we generally opted for the technically
correct solution rather than what one may call the nuclear option.

I still happen to believe in proper engineering, which is why I went through
the trouble of finely documenting what is needed here:

    http://eddelbuettel.github.io/rcppapt/binnmuAfterR340.html

The change in R is still not an abi change but simple a (in hindsight) less
than perfect implementation requiring a small subset (less than 10%) of
packages to be rebuilt. 

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 08 Sep 2017 15:27:02 GMT) (full text, mbox, link).

Message #99 received at 868558@bugs.debian.org (full text, mbox, reply):

On 01/09/17 14:28, Dirk Eddelbuettel wrote:
> 
> On 1 September 2017 at 13:52, Emilio Pozuelo Monfort wrote:
> | On 01/09/17 13:25, Dirk Eddelbuettel wrote:
> | > 
> | > Emilio,
> | > 
> | > Thanks for your follow-up.  I will try to get to each point.
> | > 
> | > On 1 September 2017 at 11:42, Emilio Pozuelo Monfort wrote:
> | > | What Niels meant is whether having an old, non-rebuilt R module with the new
> | > | r-base works, 
> | > 
> | > Yes, in general, and here in this case.
> | 
> | Then I don't understand why these binNMUs are needed.
> | 
> | >From #861333 OP:
> | 
> | "With current R, R packages built for Debian before the upload of R
> | 3.3.3.20170413-1
> | on 14 April that use .C or .Fortran do no work properly, because the functions
> | calling .C or .Fortran do not find the compiled objects."
> | 
> | That tells me that if you upgrade R but don't upgrade some modules, those will
> | (partially) break. Hence we need either an ABI bump, or versioned breaks against
> | the affected modules in r-base.
> 
> The Bug:
> 
>    - package foo contains .C() or .Fortran and registers it
>    - it is built with R 3.3.* (or any R before R 3.4.0)
>    - you upgrade to R 3.4.0 tries to load that function in foo
> 
> Not a bug:
> 
>    - any other use case including staying at R 3.3.3 and using
>      a package from R 3.4.0 (not that you could with Debian because all
>      r-cran-* packages already impose a >= on the R that built it).

The problem is that you can end up with r-bioc-makecdfenv_1.50.0-1 (i.e. before
the rebuild) and r-base_3.4.1-2, because nothing prevents that combination.

Emilio

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 08 Sep 2017 17:33:03 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 08 Sep 2017 17:33:03 GMT) (full text, mbox, link).

Message #104 received at 868558@bugs.debian.org (full text, mbox, reply):

On 8 September 2017 at 17:23, Emilio Pozuelo Monfort wrote:
| On 01/09/17 14:28, Dirk Eddelbuettel wrote:
| > 
| > On 1 September 2017 at 13:52, Emilio Pozuelo Monfort wrote:
| > | On 01/09/17 13:25, Dirk Eddelbuettel wrote:
| > | > 
| > | > Emilio,
| > | > 
| > | > Thanks for your follow-up.  I will try to get to each point.
| > | > 
| > | > On 1 September 2017 at 11:42, Emilio Pozuelo Monfort wrote:
| > | > | What Niels meant is whether having an old, non-rebuilt R module with the new
| > | > | r-base works, 
| > | > 
| > | > Yes, in general, and here in this case.
| > | 
| > | Then I don't understand why these binNMUs are needed.
| > | 
| > | >From #861333 OP:
| > | 
| > | "With current R, R packages built for Debian before the upload of R
| > | 3.3.3.20170413-1
| > | on 14 April that use .C or .Fortran do no work properly, because the functions
| > | calling .C or .Fortran do not find the compiled objects."
| > | 
| > | That tells me that if you upgrade R but don't upgrade some modules, those will
| > | (partially) break. Hence we need either an ABI bump, or versioned breaks against
| > | the affected modules in r-base.
| > 
| > The Bug:
| > 
| >    - package foo contains .C() or .Fortran and registers it
| >    - it is built with R 3.3.* (or any R before R 3.4.0)
| >    - you upgrade to R 3.4.0 tries to load that function in foo
| > 
| > Not a bug:
| > 
| >    - any other use case including staying at R 3.3.3 and using
| >      a package from R 3.4.0 (not that you could with Debian because all
| >      r-cran-* packages already impose a >= on the R that built it).
| 
| The problem is that you can end up with r-bioc-makecdfenv_1.50.0-1 (i.e. before
| the rebuild) and r-base_3.4.1-2, because nothing prevents that combination.

You may misunderstand.  Only packages that

  - have compiled code (ie arch: any, and a src/ directory)
  - use .C() and .Fortran()
  - actually use the up until recently optional registration
  - have been built with R (<< 3.4.0)

have issues.  My detailed write up goes through this.

In othre words what you describe may be a complete non-issue.

Dirk, traveling

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 08 Sep 2017 18:03:03 GMT) (full text, mbox, link).

Acknowledgement sent to Sébastien Villemot <sebastien@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 08 Sep 2017 18:03:03 GMT) (full text, mbox, link).

Message #109 received at 868558@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi Dirk and others,

On Fri, Sep 08, 2017 at 12:29:25PM -0500, Dirk Eddelbuettel wrote:

> | The problem is that you can end up with r-bioc-makecdfenv_1.50.0-1 (i.e. before
> | the rebuild) and r-base_3.4.1-2, because nothing prevents that combination.
> 
> You may misunderstand.  Only packages that
> 
>   - have compiled code (ie arch: any, and a src/ directory)
>   - use .C() and .Fortran()
>   - actually use the up until recently optional registration
>   - have been built with R (<< 3.4.0)

The point made by the Release Team is that packages that fulfill these 4
criterias may still be installed on system where R has been upgraded to 3.4.

Such a bad combination can happen if a user does a partial upgrade from stretch
to (upcoming) buster, by upgrading R core but not the CRAN packages fulfilling
the 4 criterias. In that case the user ends up with a broken system (in the
sense that those non-upgraded CRAN packages are not functional).

I understand that this situation is not going to happen very often, but it may
happen, and the Release Team wants to prevent this by introducing a Breaks
relationship.

Of course, please correct me if I am wrong.

Cheers,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 08 Sep 2017 20:51:04 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 08 Sep 2017 20:51:04 GMT) (full text, mbox, link).

Message #114 received at 868558@bugs.debian.org (full text, mbox, reply):

On 8 September 2017 at 20:01, Sébastien Villemot wrote:
| Hi Dirk and others,
| 
| On Fri, Sep 08, 2017 at 12:29:25PM -0500, Dirk Eddelbuettel wrote:
| 
| > | The problem is that you can end up with r-bioc-makecdfenv_1.50.0-1 (i.e. before
| > | the rebuild) and r-base_3.4.1-2, because nothing prevents that combination.
| > 
| > You may misunderstand.  Only packages that
| > 
| >   - have compiled code (ie arch: any, and a src/ directory)
| >   - use .C() and .Fortran()
| >   - actually use the up until recently optional registration
| >   - have been built with R (<< 3.4.0)
| 
| The point made by the Release Team is that packages that fulfill these 4
| criterias may still be installed on system where R has been upgraded to 3.4.

Which is why we want to update all such packages, hence my 'please NMU'
request to the release team.
 
| Such a bad combination can happen if a user does a partial upgrade from stretch
| to (upcoming) buster, by upgrading R core but not the CRAN packages fulfilling
| the 4 criterias. In that case the user ends up with a broken system (in the
| sense that those non-upgraded CRAN packages are not functional).
| 
| I understand that this situation is not going to happen very often, but it may
| happen, and the Release Team wants to prevent this by introducing a Breaks
| relationship.
| 
| Of course, please correct me if I am wrong.

I still maintain that this is a useless "academic" consideration.  If users
want to corrupt their systems by only upgrading one package I will not stop
them.  They can simply fix them by also upgrading the package left behind.

I aim for 'apt-get dist-upgrade' doing the right thing for them. It will
automate this.

Dirk
| 
| Cheers,
| 
| -- 
| ⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
| ⣾⠁⢠⠒⠀⣿⡁  Debian Developer
| ⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
| ⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org
| [DELETED ATTACHMENT signature.asc, application/pgp-signature]

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 08 Sep 2017 23:33:02 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Beckmann <anbe@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 08 Sep 2017 23:33:02 GMT) (full text, mbox, link).

Message #119 received at 868558@bugs.debian.org (full text, mbox, reply):

On 2017-09-08 22:49, Dirk Eddelbuettel wrote:
> I still maintain that this is a useless "academic" consideration.  If users
> want to corrupt their systems by only upgrading one package I will not stop
> them.  They can simply fix them by also upgrading the package left behind.

If the package dependencies are not strict enough and allow known broken 
package combinations to be installed (without any --force switch), it's 
our fault, not the user.

> I aim for 'apt-get dist-upgrade' doing the right thing for them. It will
> automate this.

Users running testing or sid are much more likely to perform partial
upgrades.
Or imagine someone backporting r-base 3.4.1 to stretch ... Breaks will
really help here.

But let's get back on the topic.

I think a similar example to what you want to achive is #874413 + 
#873791. This is a ABI break in python (some internal module was 
removed), which requires a bunch of binNMUs. In addition to this, there 
were Breaks added in some core python packages (e.g. libpython2.7-
stdlib) against all the packages that used the removed ABI.

Since you already compiled a minimal list of affected packages (that 
need to be binNMUed), you just need to add appropriately versioned 
Breaks against all of them in r-base-core (or whichever package better 
fits this). 

These Breaks can be removed on the next r ABI bump.

For the 42 packages listed in message #15 (even if you said there were 
46) this would be ... hmm, wait, only 4 of the versions listed there
are actually in sid, so the NMU list does not look too useful:

$ rmadison  -s unstable,stable r-cran-hdf5  r-cran-spam r-cran-spatstat r-cran-surveillance
r-cran-hdf5         | 1.6.10-4      | stable     | source
r-cran-hdf5         | 1.6.10-4      | unstable   | source
r-cran-hdf5         | 1.6.10-4+b1   | stable     | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
r-cran-hdf5         | 1.6.10-4+b1   | unstable   | amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
r-cran-spam         | 1.4-0-1       | stable     | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
r-cran-spam         | 1.4-0-1       | unstable   | source, amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
r-cran-spatstat     | 1.48-0-1      | stable     | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
r-cran-spatstat     | 1.48-0-1      | unstable   | source, amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
r-cran-surveillance | 1.13.0-1      | stable     | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
r-cran-surveillance | 1.13.0-1      | unstable   | source, amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x


Anyway, these are the Breaks for the list from comment #15:

$ sort r-nmu-list | tr _ \  | awk 'BEGIN {print "Breaks:"} {print " " $2 " (<= " $3 "), "}'

Breaks:
 r-cran-ade4 (<= 1.7-5-1), 
 r-cran-bayesm (<= 3.0-2-2), 
 r-cran-blockmodeling (<= 0.1.8-1), 
 r-cran-brglm (<= 0.5-9-1), 
 r-cran-caret (<= 6.0-73+dfsg1-1), 
 r-cran-coin (<= 1.1-3-1), 
 r-cran-contfrac (<= 1.1-10-1), 
 r-cran-data.table (<= 1.10.0-1), 
 r-cran-deldir (<= 0.1-12-1), 
 r-cran-desolve (<= 1.14-1), 
 r-cran-eco (<= 3.1-7-1), 
 r-cran-expm (<= 0.999-0-1), 
 r-cran-fields (<= 8.10-1), 
 r-cran-gam (<= 1.14-1), 
 r-cran-glmnet (<= 2.0-5-1), 
 r-cran-goftest (<= 1.0-3-1), 
 r-cran-hdf5 (<= 1.6.10-4+b1), 
 r-cran-igraph (<= 1.0.1-1), 
 r-cran-mapproj (<= 1.2-4-1), 
 r-cran-maps (<= 3.1.1-1), 
 r-cran-maptools (<= 1:0.8-41+dfsg-1), 
 r-cran-mcmc (<= 0.9-4-2), 
 r-cran-mcmcpack (<= 1.3-8-1), 
 r-cran-medadherence (<= 1.03-2), 
 r-cran-mixtools (<= 1.0.4-1), 
 r-cran-mnp (<= 2.6-4-1), 
 r-cran-ncdf4 (<= 1.15-1+b2), 
 r-cran-phangorn (<= 2.1.1-1), 
 r-cran-phylobase (<= 0.8.2-1), 
 r-cran-qtl (<= 1.40-8-1), 
 r-cran-randomfields (<= 3.1.36-1), 
 r-cran-randomfieldsutils (<= 0.3.15-1), 
 r-cran-rcurl (<= 1.95-4.8-2), 
 r-cran-rniftilib (<= 0.0-35.r79-2), 
 r-cran-sp (<= 1:1.2-4-1), 
 r-cran-spam (<= 1.4-0-1), 
 r-cran-spatstat (<= 1.48-0-1), 
 r-cran-spdep (<= 0.6-9-1), 
 r-cran-surveillance (<= 1.13.0-1), 
 r-cran-treescape (<= 1.10.18-6), 
 r-cran-vegan (<= 2.4-2-1), 
 r-cran-vgam (<= 1.0-3-1),

Also note that the nmu commands for the packages that already were 
binNMUed are wrong: you need the source version there, so no +bX suffix.


Andreas

Message #124 received at 868558@bugs.debian.org (full text, mbox, reply):

On 9 September 2017 at 01:31, Andreas Beckmann wrote:
| On 2017-09-08 22:49, Dirk Eddelbuettel wrote:
| > I still maintain that this is a useless "academic" consideration.  If users
| > want to corrupt their systems by only upgrading one package I will not stop
| > them.  They can simply fix them by also upgrading the package left behind.
| 
| If the package dependencies are not strict enough and allow known broken 
| package combinations to be installed (without any --force switch), it's 
| our fault, not the user.
| 
| > I aim for 'apt-get dist-upgrade' doing the right thing for them. It will
| > automate this.
| 
| Users running testing or sid are much more likely to perform partial
| upgrades.
| Or imagine someone backporting r-base 3.4.1 to stretch ... Breaks will
| really help here.
| 
| But let's get back on the topic.
| 
| I think a similar example to what you want to achive is #874413 + 
| #873791. This is a ABI break in python (some internal module was 
| removed), which requires a bunch of binNMUs. In addition to this, there 
| were Breaks added in some core python packages (e.g. libpython2.7-
| stdlib) against all the packages that used the removed ABI.
| 
| Since you already compiled a minimal list of affected packages (that 
| need to be binNMUed), you just need to add appropriately versioned 
| Breaks against all of them in r-base-core (or whichever package better 
| fits this). 
| 
| These Breaks can be removed on the next r ABI bump.
| 
| For the 42 packages listed in message #15 (even if you said there were 
| 46) this would be ... hmm, wait, only 4 of the versions listed there
| are actually in sid, so the NMU list does not look too useful:
| 
| $ rmadison  -s unstable,stable r-cran-hdf5  r-cran-spam r-cran-spatstat r-cran-surveillance
| r-cran-hdf5         | 1.6.10-4      | stable     | source
| r-cran-hdf5         | 1.6.10-4      | unstable   | source
| r-cran-hdf5         | 1.6.10-4+b1   | stable     | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
| r-cran-hdf5         | 1.6.10-4+b1   | unstable   | amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
| r-cran-spam         | 1.4-0-1       | stable     | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
| r-cran-spam         | 1.4-0-1       | unstable   | source, amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
| r-cran-spatstat     | 1.48-0-1      | stable     | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
| r-cran-spatstat     | 1.48-0-1      | unstable   | source, amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
| r-cran-surveillance | 1.13.0-1      | stable     | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
| r-cran-surveillance | 1.13.0-1      | unstable   | source, amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x
| 
| 
| Anyway, these are the Breaks for the list from comment #15:
| 
| $ sort r-nmu-list | tr _ \  | awk 'BEGIN {print "Breaks:"} {print " " $2 " (<= " $3 "), "}'
| 
| Breaks:
|  r-cran-ade4 (<= 1.7-5-1), 
|  r-cran-bayesm (<= 3.0-2-2), 
|  r-cran-blockmodeling (<= 0.1.8-1), 
|  r-cran-brglm (<= 0.5-9-1), 
|  r-cran-caret (<= 6.0-73+dfsg1-1), 
|  r-cran-coin (<= 1.1-3-1), 
|  r-cran-contfrac (<= 1.1-10-1), 
|  r-cran-data.table (<= 1.10.0-1), 
|  r-cran-deldir (<= 0.1-12-1), 
|  r-cran-desolve (<= 1.14-1), 
|  r-cran-eco (<= 3.1-7-1), 
|  r-cran-expm (<= 0.999-0-1), 
|  r-cran-fields (<= 8.10-1), 
|  r-cran-gam (<= 1.14-1), 
|  r-cran-glmnet (<= 2.0-5-1), 
|  r-cran-goftest (<= 1.0-3-1), 
|  r-cran-hdf5 (<= 1.6.10-4+b1), 
|  r-cran-igraph (<= 1.0.1-1), 
|  r-cran-mapproj (<= 1.2-4-1), 
|  r-cran-maps (<= 3.1.1-1), 
|  r-cran-maptools (<= 1:0.8-41+dfsg-1), 
|  r-cran-mcmc (<= 0.9-4-2), 
|  r-cran-mcmcpack (<= 1.3-8-1), 
|  r-cran-medadherence (<= 1.03-2), 
|  r-cran-mixtools (<= 1.0.4-1), 
|  r-cran-mnp (<= 2.6-4-1), 
|  r-cran-ncdf4 (<= 1.15-1+b2), 
|  r-cran-phangorn (<= 2.1.1-1), 
|  r-cran-phylobase (<= 0.8.2-1), 
|  r-cran-qtl (<= 1.40-8-1), 
|  r-cran-randomfields (<= 3.1.36-1), 
|  r-cran-randomfieldsutils (<= 0.3.15-1), 
|  r-cran-rcurl (<= 1.95-4.8-2), 
|  r-cran-rniftilib (<= 0.0-35.r79-2), 
|  r-cran-sp (<= 1:1.2-4-1), 
|  r-cran-spam (<= 1.4-0-1), 
|  r-cran-spatstat (<= 1.48-0-1), 
|  r-cran-spdep (<= 0.6-9-1), 
|  r-cran-surveillance (<= 1.13.0-1), 
|  r-cran-treescape (<= 1.10.18-6), 
|  r-cran-vegan (<= 2.4-2-1), 
|  r-cran-vgam (<= 1.0-3-1),

That is madness, and AFAIUI also wrong (as you miss the package which might
have been in the list, but aren't as they may have gotten upgraded by now).

I do not plan to add this to r-base-core.  We already waited five month since
April, what are another seven til the next release of R.

Dirk
 
| Also note that the nmu commands for the packages that already were 
| binNMUed are wrong: you need the source version there, so no +bX suffix.
| 
| 
| Andreas

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Message #129 received at 868558@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Control: tags -1 wontfix

Dirk Eddelbuettel:
> 
> On 9 September 2017 at 01:31, Andreas Beckmann wrote:
> | On 2017-09-08 22:49, Dirk Eddelbuettel wrote:
> | > I still maintain that this is a useless "academic" consideration.  If users
> | > want to corrupt their systems by only upgrading one package I will not stop
> | > them.  They can simply fix them by also upgrading the package left behind.
> | 
> | If the package dependencies are not strict enough and allow known broken 
> | package combinations to be installed (without any --force switch), it's 
> | our fault, not the user.
> | 
> | > I aim for 'apt-get dist-upgrade' doing the right thing for them. It will
> | > automate this.
> | 
> | Users running testing or sid are much more likely to perform partial
> | upgrades.
> | Or imagine someone backporting r-base 3.4.1 to stretch ... Breaks will
> | really help here.
> | 
> | But let's get back on the topic.
> | 
> | I think a similar example to what you want to achive is #874413 + 
> | #873791. This is a ABI break in python (some internal module was 
> | removed), which requires a bunch of binNMUs. In addition to this, there 
> | were Breaks added in some core python packages (e.g. libpython2.7-
> | stdlib) against all the packages that used the removed ABI.
> | 
> | [...]
> 

Hi,

Thanks to Sébastien and Andreas for explaining the issue.

> That is madness, and AFAIUI also wrong (as you miss the package which might
> have been in the list, but aren't as they may have gotten upgraded by now).
> 

I appreciate that the Breaks-list is fragile; even more so at this scale
plus it needs to filter on binNMU versions (which can differ between
architectures).  However, we will need a solution for the "partial
upgrades" issue before r-base can migrate.

You may not like the "partial upgrades must work" principle or how it is
implemented, but please keep in mind that we (as a distribution and our
users) rely on it in many areas to ensure that every thing works as
intended.

> I do not plan to add this to r-base-core.  We already waited five month since
> April, what are another seven til the next release of R.
> 
> Dirk
>  
> [...]

That is fine.  Then (to my knowledge) your only option is an "ABI bump".
 Until one of these solutions is applied, this bug is "wontfix" and
r-base is blocked from migrating to testing.

Thanks,
~Niels

[signature.asc (application/pgp-signature, attachment)]

Added tag(s) wontfix. Request was from Niels Thykier <niels@thykier.net> to 868558-submit@bugs.debian.org. (Sat, 09 Sep 2017 07:03:03 GMT) (full text, mbox, link).

Message #136 received at 868558@bugs.debian.org (full text, mbox, reply):

On 9 September 2017 at 06:44, Niels Thykier wrote:
| Thanks to Sébastien and Andreas for explaining the issue.

Well, was it "explained" ?  They both raised and stressed a hypothetical
issue: That "there might be siutations where a partial upgrade breaks"

We don't actually know whether this holds.  This R 3.4.* change was not a
full-fledged ABI change.

| That is fine.  Then (to my knowledge) your only option is an "ABI bump".

I still disagree, for this case.

We will likely need one for anticipated internal R changes by R 3.5.0.

|  Until one of these solutions is applied, this bug is "wontfix" and
| r-base is blocked from migrating to testing.

I think this is a dissservice to our users.

Consider another data point.  It so happens that we have informal backports
for both Debian and Ubuntu at all the CRAN mirrors:

   https://cloud.r-project.org/bin/linux/debian/
   https://cloud.r-project.org/bin/linux/ubuntu/README.html

I am not aware of anything breaking there either.

So I think this is blown out of proportion regarding the _potential_ partial
upgrade issue.  We just don't know if it really applies.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Acknowledgement sent to Sébastien Villemot <sebastien@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sat, 09 Sep 2017 12:15:03 GMT) (full text, mbox, link).

Message #141 received at 868558@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Sat, Sep 09, 2017 at 06:48:12AM -0500, Dirk Eddelbuettel wrote:
> 
> On 9 September 2017 at 06:44, Niels Thykier wrote:
> | Thanks to Sébastien and Andreas for explaining the issue.
> 
> Well, was it "explained" ?  They both raised and stressed a hypothetical
> issue: That "there might be siutations where a partial upgrade breaks"
> 
> We don't actually know whether this holds.  This R 3.4.* change was not a
> full-fledged ABI change.

I made the following experiment:

- started from a minimal stretch chroot
- installed r-base and r-cran-spatial
- upgraded r-base to the version from sid (but not r-cran-spatial)
- ran the example described in #861333:

  $ R -e "library(spatial); example(surf.gls)"

then I get a crash with the error message "object 'VR_frset' not found".

So this confirms that partial upgrades are indeed broken.

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org

[signature.asc (application/pgp-signature, inline)]

Reply sent to Andreas Tille <tille@debian.org>:
You have taken responsibility. (Sat, 09 Sep 2017 13:39:08 GMT) (full text, mbox, link).

Notification sent to Dirk Eddelbuettel <edd@debian.org>:
Bug acknowledged by developer. (Sat, 09 Sep 2017 13:39:08 GMT) (full text, mbox, link).

Message #146 received at 868558-done@bugs.debian.org (full text, mbox, reply):

Hi,

I hereby closing this bug since all affected packages were
manually uploaded.

Kind regards and thanks for your work as release team

    Andreas.

-- 
http://fam-tille.de

Message #151 received at 868558@bugs.debian.org (full text, mbox, reply):

On 9 September 2017 at 14:12, Sébastien Villemot wrote:
| On Sat, Sep 09, 2017 at 06:48:12AM -0500, Dirk Eddelbuettel wrote:
| > 
| > On 9 September 2017 at 06:44, Niels Thykier wrote:
| > | Thanks to Sébastien and Andreas for explaining the issue.
| > 
| > Well, was it "explained" ?  They both raised and stressed a hypothetical
| > issue: That "there might be siutations where a partial upgrade breaks"
| > 
| > We don't actually know whether this holds.  This R 3.4.* change was not a
| > full-fledged ABI change.
| 
| I made the following experiment:
| 
| - started from a minimal stretch chroot
| - installed r-base and r-cran-spatial
| - upgraded r-base to the version from sid (but not r-cran-spatial)

Come one. That's the situation of EVERY known bug in testing fixed in unstable.
You explicitly chose to NOT get the fix, to then state it wasn't fixed.

I am waiting for you to also enforce use of 'rm -i' over 'rm'.

I am done. This way too dogmatic for my taste. I feel sorry about the users
who will not get access to current, updated and bug free version of R because
of this.  A wrong decision.

Dirk

| - ran the example described in #861333:
| 
|   $ R -e "library(spatial); example(surf.gls)"
| 
| then I get a crash with the error message "object 'VR_frset' not found".
| 
| So this confirms that partial upgrades are indeed broken.
| 
| Best,
| 
| -- 
| ⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
| ⣾⠁⢠⠒⠀⣿⡁  Debian Developer
| ⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
| ⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org
| [DELETED ATTACHMENT signature.asc, application/pgp-signature]

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Message #156 received at 868558@bugs.debian.org (full text, mbox, reply):

On 9 September 2017 at 15:38, Andreas Tille wrote:
| I hereby closing this bug since all affected packages were
| manually uploaded.

I really, really appreciate that.

In your view, can we / shall we also close the underlying

    https://bugs.debian.org/861333

which started this?   As I understand you correctly, all identified packages
should by now have been rebuilt, so R should be free to migrate to testing.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Acknowledgement sent to Sébastien Villemot <sebastien@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sat, 09 Sep 2017 14:21:03 GMT) (full text, mbox, link).

Message #161 received at 868558@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Sat, Sep 09, 2017 at 08:53:49AM -0500, Dirk Eddelbuettel wrote:
> On 9 September 2017 at 14:12, Sébastien Villemot wrote:
> | On Sat, Sep 09, 2017 at 06:48:12AM -0500, Dirk Eddelbuettel wrote:
> | > 
> | > On 9 September 2017 at 06:44, Niels Thykier wrote:
> | > | Thanks to Sébastien and Andreas for explaining the issue.
> | > 
> | > Well, was it "explained" ?  They both raised and stressed a hypothetical
> | > issue: That "there might be siutations where a partial upgrade breaks"
> | > 
> | > We don't actually know whether this holds.  This R 3.4.* change was not a
> | > full-fledged ABI change.
> | 
> | I made the following experiment:
> | 
> | - started from a minimal stretch chroot
> | - installed r-base and r-cran-spatial
> | - upgraded r-base to the version from sid (but not r-cran-spatial)
> 
> Come one. That's the situation of EVERY known bug in testing fixed in
> unstable.

No it’s not the same. In the present case, (partially-)upgrading to unstable
*introduces* a bug.

> I am done. This way too dogmatic for my taste. I feel sorry about the users
> who will not get access to current, updated and bug free version of R because
> of this.  A wrong decision.

I don’t want to argue about the soundness of this technical requirement. I am
just interested in having this issue sorted out, since I am a R user and
package maintainer.

As already stated in <20170906144810.f663j3gykjcxocds@villemot.name>, I am
willing to help by generating the correct list of Breaks that, if incorporated
in the debian/control of r-base, would solve the issue.

But since I do not want to waste my time, I first need to be sure that you would
accept such a patch.

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org

[signature.asc (application/pgp-signature, inline)]

Message #166 received at 868558@bugs.debian.org (full text, mbox, reply):

On 9 September 2017 at 16:18, Sébastien Villemot wrote:
| But since I do not want to waste my time, I first need to be sure that you would
| accept such a patch.

Re-read

 http://eddelbuettel.github.io/rcppapt/binnmuAfterR340.html

and construct (using R and my RcppAPT packages) the set of packages that

 - are reverse depends of r-base-core in Debian (just over 500+ iirc)
 - have a src/ directory, ie are Archicture: any 
 - have .C or .Fortran calls below R/
 - use dynamic symbol registration 
 - but ignore whether they have been rebuilt

so it would differ from my analysis.  I reckon that you would end up with
maybe 100 to 150 (a guess) packages for which you would need a Breaks:
declaration.

Now I, as maintainer of r-base, feel that I would not serve my users with the
added fragility of 100+ breaks statements.

But you are of course free to create a locally patched package for local
tests and users.  We know how quickly a local apt repo can be created.  As
having this functionality seems rather important to you (while I remain more
than sceptical) I suggest you work on that in such a local package.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Acknowledgement sent to Sébastien Villemot <sebastien@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sat, 09 Sep 2017 14:51:03 GMT) (full text, mbox, link).

Message #171 received at 868558@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Sat, Sep 09, 2017 at 09:39:37AM -0500, Dirk Eddelbuettel wrote:
> 
> On 9 September 2017 at 16:18, Sébastien Villemot wrote:
> | But since I do not want to waste my time, I first need to be sure that you would
> | accept such a patch.
> 
> Re-read
> 
>  http://eddelbuettel.github.io/rcppapt/binnmuAfterR340.html
> 
> and construct (using R and my RcppAPT packages) the set of packages that
> 
>  - are reverse depends of r-base-core in Debian (just over 500+ iirc)
>  - have a src/ directory, ie are Archicture: any 
>  - have .C or .Fortran calls below R/
>  - use dynamic symbol registration 
>  - but ignore whether they have been rebuilt
> 
> so it would differ from my analysis.  I reckon that you would end up with
> maybe 100 to 150 (a guess) packages for which you would need a Breaks:
> declaration.

Thanks for the pointers and for the explanation. Indeed the list will be quite
long, keeping in mind that some packages may appear several times with
architecture qualifiers if version numbers differ across architectures (due for
example to different binNMU version suffixes).

> Now I, as maintainer of r-base, feel that I would not serve my users with the
> added fragility of 100+ breaks statements.
> 
> But you are of course free to create a locally patched package for local
> tests and users.  We know how quickly a local apt repo can be created.  As
> having this functionality seems rather important to you (while I remain more
> than sceptical) I suggest you work on that in such a local package.

Well, I am interested in having this fixed in Debian, not in a local package or
repository. So I understand from your message that I cannot help.

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org

[signature.asc (application/pgp-signature, inline)]

Acknowledgement sent to Andreas Tille <tille@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sat, 09 Sep 2017 17:33:10 GMT) (full text, mbox, link).

Message #176 received at 868558@bugs.debian.org (full text, mbox, reply):

Hi Dirk,

On Sat, Sep 09, 2017 at 08:56:28AM -0500, Dirk Eddelbuettel wrote:
> I really, really appreciate that.
> 
> In your view, can we / shall we also close the underlying
> 
>     https://bugs.debian.org/861333
> 
> which started this?   As I understand you correctly, all identified packages
> should by now have been rebuilt, so R should be free to migrate to testing.

I would have waitet 4 days to enable the rebuild packages getting
permission to enter testing but since you have closed the other bug
now I think there is no real harm done if these will follow the main
R packages some days later.

Kind regards

      Andreas.

-- 
http://fam-tille.de

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Sun, 10 Sep 2017 09:24:03 GMT) (full text, mbox, link).

Acknowledgement sent to Emilio Pozuelo Monfort <pochu@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sun, 10 Sep 2017 09:24:03 GMT) (full text, mbox, link).

Message #181 received at 868558@bugs.debian.org (full text, mbox, reply):

On 09/09/17 13:48, Dirk Eddelbuettel wrote:
> 
> On 9 September 2017 at 06:44, Niels Thykier wrote:
> | Thanks to Sébastien and Andreas for explaining the issue.
> 
> Well, was it "explained" ?  They both raised and stressed a hypothetical
> issue: That "there might be siutations where a partial upgrade breaks"
> 
> We don't actually know whether this holds.  This R 3.4.* change was not a
> full-fledged ABI change.
> 
> | That is fine.  Then (to my knowledge) your only option is an "ABI bump".
> 
> I still disagree, for this case.
> 
> We will likely need one for anticipated internal R changes by R 3.5.0.
> 
> |  Until one of these solutions is applied, this bug is "wontfix" and
> | r-base is blocked from migrating to testing.
> 
> I think this is a dissservice to our users.

The only disservice here is that you refuse to prevent users from getting broken
systems due to this ABI break. This is particularly surprising given the simple
fix (adding breaks) and that Sébastien is offering you a patch.

This is no different from someone breaking a shared library ABI, say libfoo0,
and then asking for rebuilds of the rdeps, and refusing to bump the SONAME,
rename the package or add breaks against the non-rebuilt rdeps. That would be
unacceptable, and so is your case.

As it was pointed out, look at the recent Python extension ABI break that was
quickly fixed by adding Breaks and scheduling a bunch of binNMUs.

Cheers,
Emilio

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Sun, 10 Sep 2017 15:45:02 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sun, 10 Sep 2017 15:45:02 GMT) (full text, mbox, link).

Message #186 received at 868558@bugs.debian.org (full text, mbox, reply):

On 10 September 2017 at 11:20, Emilio Pozuelo Monfort wrote:
| On 09/09/17 13:48, Dirk Eddelbuettel wrote:
| > 
| > On 9 September 2017 at 06:44, Niels Thykier wrote:
| > | Thanks to Sébastien and Andreas for explaining the issue.
| > 
| > Well, was it "explained" ?  They both raised and stressed a hypothetical
| > issue: That "there might be siutations where a partial upgrade breaks"
| > 
| > We don't actually know whether this holds.  This R 3.4.* change was not a
| > full-fledged ABI change.
| > 
| > | That is fine.  Then (to my knowledge) your only option is an "ABI bump".
| > 
| > I still disagree, for this case.
| > 
| > We will likely need one for anticipated internal R changes by R 3.5.0.
| > 
| > |  Until one of these solutions is applied, this bug is "wontfix" and
| > | r-base is blocked from migrating to testing.
| > 
| > I think this is a dissservice to our users.
| 
| The only disservice here is that you refuse to prevent users from getting broken
| systems due to this ABI break. This is particularly surprising given the simple
| fix (adding breaks) and that Sébastien is offering you a patch.

That is just not true.

Someone would have to intentionally try to (and I must use quotes here)
"break" their system by intentionally upgrading only r-base(-core).  If and
when (which will still be unlikely) a call does not get resolved the affected
user would do what every R users knows: "rebuild the package", in this case
upgrade the package too.  Case closed.

It is hair-brained anyway as users typically upgrade in buld: apt-get dist-upgrade.

And to be brutally honest: most users I know compile CRAN packages from CRAN
directly into /usr/local/lib/R so this whole dance about the r-cran-*
packages is somewhat irrelevant, and clearly irrational.

I understand the release loves BREAKS but it does not solve a problem that
needs solving here.  You create a problem by aggrandising what is more or
less a non-issue so that you can then come and tell us BREAKS solves
everything.

Now:

  Excuse for r-base

  Migration status: BLOCKED: Needs an approval (either due to a freeze, the source suite or a manual hint)
  64 days old (needed 5 days)
  Not touching package due to block request by nthykier (please contact debian-release if update is needed)
  Piuparts tested OK - https://piuparts.debian.org/sid/source/r/r-base.html
  Not considered

Dear debian-release:  Please remove this block.

| 
| This is no different from someone breaking a shared library ABI, say libfoo0,
| and then asking for rebuilds of the rdeps, and refusing to bump the SONAME,
| rename the package or add breaks against the non-rebuilt rdeps. That would be
| unacceptable, and so is your case.
| 
| As it was pointed out, look at the recent Python extension ABI break that was
| quickly fixed by adding Breaks and scheduling a bunch of binNMUs.

That is a different issue. I have no time for apples-oranges discussions. We
has no ABI break.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Sun, 10 Sep 2017 16:21:03 GMT) (full text, mbox, link).

Acknowledgement sent to Niels Thykier <niels@thykier.net>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sun, 10 Sep 2017 16:21:03 GMT) (full text, mbox, link).

Message #191 received at 868558@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Dirk Eddelbuettel:
> 
> On 10 September 2017 at 11:20, Emilio Pozuelo Monfort wrote:
> | On 09/09/17 13:48, Dirk Eddelbuettel wrote:
> | > 
> | > On 9 September 2017 at 06:44, Niels Thykier wrote:
> | > | Thanks to Sébastien and Andreas for explaining the issue.
> | > 
> | > Well, was it "explained" ?  They both raised and stressed a hypothetical
> | > issue: That "there might be siutations where a partial upgrade breaks"
> | > 
> | > We don't actually know whether this holds.  This R 3.4.* change was not a
> | > full-fledged ABI change.
> | > 
> | > | That is fine.  Then (to my knowledge) your only option is an "ABI bump".
> | > 
> | > I still disagree, for this case.
> | > 
> | > We will likely need one for anticipated internal R changes by R 3.5.0.
> | > 
> | > |  Until one of these solutions is applied, this bug is "wontfix" and
> | > | r-base is blocked from migrating to testing.
> | > 
> | > I think this is a dissservice to our users.
> | 
> | The only disservice here is that you refuse to prevent users from getting broken
> | systems due to this ABI break. This is particularly surprising given the simple
> | fix (adding breaks) and that Sébastien is offering you a patch.
> 
> That is just not true.
> 

No; it is true.  It is a breakage.

> Someone would have to intentionally try to (and I must use quotes here)
> "break" their system by intentionally upgrading only r-base(-core).  If and
> when (which will still be unlikely) a call does not get resolved the affected
> user would do what every R users knows: "rebuild the package", in this case
> upgrade the package too.  Case closed.
> 

No; because the package relationships do not ensure partial upgrade
safety, britney can (and will) migrate the packages to testing out of
order.  Concretely, since all rdeps have recently been rebuilt, they
will have to wait 5 days while r-base will migrate immediately.

In this scenario, the users will "break" their systems even with a
regular "apt-get dist-upgrade" while applying every upgrade available to
them.

And no, this is not just a question of "waiting 5 days".  Even then
Britney will not enforce that they migrate at the same time (and how
could she, when no one informed her of the proper relations)

> [...]
> 
> I understand the release loves BREAKS but it does not solve a problem that
> needs solving here.

I am sorry you feel that way and that you refuse to acknowledge this as
a problem.  However, it is a real issue and it will cause pain and grief
for users and the release team.

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.

> Now:
> 
>   Excuse for r-base
> 
>   Migration status: BLOCKED: Needs an approval (either due to a freeze, the source suite or a manual hint)
>   64 days old (needed 5 days)
>   Not touching package due to block request by nthykier (please contact debian-release if update is needed)
>   Piuparts tested OK - https://piuparts.debian.org/sid/source/r/r-base.html
>   Not considered
> 
> Dear debian-release:  Please remove this block.
> 

I respectfully decline.

I have instated this block as a release manager (a delegated position),
who is responsible for the contents for the testing suite including the
migration rules.
  If you want this block lifted, please implement a proper ABI-like
transition OR the Breaks.  You have my preference, but I will accept
either solution.  (Technically, I will also accept a revert of r-base,
but I doubt this is interesting to you)

If you feel this is unjust, you are welcome to appeal this according to
the rules of the constitution.  If memory serves, your only option is to
propose a GR (but I could be wrong; please consult the Debian secretary).

> | 
> | This is no different from someone breaking a shared library ABI, say libfoo0,
> | and then asking for rebuilds of the rdeps, and refusing to bump the SONAME,
> | rename the package or add breaks against the non-rebuilt rdeps. That would be
> | unacceptable, and so is your case.
> | 
> | As it was pointed out, look at the recent Python extension ABI break that was
> | quickly fixed by adding Breaks and scheduling a bunch of binNMUs.
> 
> That is a different issue. I have no time for apples-oranges discussions. We
> has no ABI break.
> 
> Dirk
> 

It may be apples-oranges to you; for me it is not.  Your proposed
migration *will* break things because no tooling can sanely ensure that
the users will receive a self-contained consistent selection of r-packages.

Thanks,
~Niels

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Sun, 10 Sep 2017 18:21:05 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sun, 10 Sep 2017 18:21:05 GMT) (full text, mbox, link).

Message #196 received at 868558@bugs.debian.org (full text, mbox, reply):

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 | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Mon, 11 Sep 2017 06:21:05 GMT) (full text, mbox, link).

Acknowledgement sent to Niels Thykier <niels@thykier.net>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Mon, 11 Sep 2017 06:21:05 GMT) (full text, mbox, link).

Message #201 received at 868558@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Dirk Eddelbuettel:
> 
> On 10 September 2017 at 16:15, Niels Thykier wrote:
> [...]> |
> Next April they will have r-api-4.

Ok.  If the r-api-4 bump in April works like I think it does, then that
will also resolve this problem as a side-effect.  So in worst case, we
can do a regular transition of r-base in April and I will be happy to
remove these block hints at that point (assuming the situation has not
been resolved prior to this).

> *This case* did not warrant puzting with
> r-api-* and you will have to take my word for it.
> 

This part seems to be the entire basis of our disagreement.  I admit
that I cannot grant you a leeway here as it is one of the most basic
things in our job description - keep testing working smoothly.

From our perspective, if it breaks reverse dependencies that has not
been rebuild, then it *does* warrant bumping $SOMETHING.  Usually
regular package name, sometimes a virtual -abi or -api package.  This is
to ensure britney migrate things in the correct order and ensures that
users cannot end up with two packages that do not work together.
  This approach does end up requiring more packages to be rebuilt than
what is theoretically necessary.  But that is generally a non-issue
(provided the reverse dependencies are "arch:any" packages so they can
be binNMUed).

If you need the "r-api-*" package to stay in sync with an upstream API
number or it is for arch:all packages, then please consider introducing
a separate package (e.g. r-abi) that can be bumped independently and
have .C (etc.) using code depend on that as well.  Unfortunately, this
newly created package cannot be used in this case (it has to exists
prior to the breakage), so it is only suitable for future problems.

> | > 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.
> 

Ok.  Again, I am truly sorry you feel that way.  But that is your choice
and you are welcome to do that.

> 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
> 

You are welcome to define yourself as "rogue", but please keep in mind
that it is a "self-inflicted" label.  We do not label you any different
than any other Debian contributor.  Likewise, our requirements to you
are the same as to all other Debian contributors.

 * If you change your mind, we will be happy to assist you with the
   transition (provided it fits in the freeze schedule).

 * We are also happy to work with delegates on your behalf if you prefer
   that.  Our requirements will be the same to all contributors so they
   will receive the same instructions.

 * We can wait until the r-api-4 bump in April if you prefer that.

Thanks,
~Niels

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Mon, 11 Sep 2017 13:39:02 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Tille <tille@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Mon, 11 Sep 2017 13:39:02 GMT) (full text, mbox, link).

Message #206 received at 868558@bugs.debian.org (full text, mbox, reply):

Hi,

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).

Kind regards

      Andreas.

-- 
http://fam-tille.de

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Mon, 11 Sep 2017 14:00:06 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Mon, 11 Sep 2017 14:00:06 GMT) (full text, mbox, link).

Message #211 received at 868558@bugs.debian.org (full text, mbox, reply):

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 | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Mon, 11 Sep 2017 16:03:02 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Tille <tille@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Mon, 11 Sep 2017 16:03:02 GMT) (full text, mbox, link).

Message #216 received at 868558@bugs.debian.org (full text, mbox, reply):

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?

Kind regards

    Andreas.

-- 
http://fam-tille.de

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Mon, 11 Sep 2017 16:15:08 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Mon, 11 Sep 2017 16:15:08 GMT) (full text, mbox, link).

Message #221 received at 868558@bugs.debian.org (full text, mbox, reply):

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 | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Mon, 11 Sep 2017 16:27:05 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Tille <tille@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Mon, 11 Sep 2017 16:27:05 GMT) (full text, mbox, link).

Message #226 received at 868558@bugs.debian.org (full text, mbox, reply):

On Mon, Sep 11, 2017 at 11:12:24AM -0500, Dirk Eddelbuettel wrote:
> 
> 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.

This paragraph describes exactly what you are supposed to do to do a
_M_ass _B_ug _F_iling (MBF) and there are several examples on
debian-devel.

Kind regards

      Andreas.

-- 
http://fam-tille.de

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Mon, 11 Sep 2017 16:33:03 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Mon, 11 Sep 2017 16:33:03 GMT) (full text, mbox, link).

Message #231 received at 868558@bugs.debian.org (full text, mbox, reply):

On 11 September 2017 at 18:25, Andreas Tille wrote:
| On Mon, Sep 11, 2017 at 11:12:24AM -0500, Dirk Eddelbuettel wrote:
| > 
| > 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.
| 
| This paragraph describes exactly what you are supposed to do to do a
| _M_ass _B_ug _F_iling (MBF) and there are several examples on
| debian-devel.

   Reporting a great number of bugs for the same problem on a great number of
   different packages — i.e., more than 10 — is a deprecated practice.

I read that as "please don't spam >= 10 at once".  So I didn't.

It's moot now anyway.  Can we stop the thread?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Sun, 24 Sep 2017 13:39:02 GMT) (full text, mbox, link).

Acknowledgement sent to Sébastien Villemot <sebastien@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sun, 24 Sep 2017 13:39:02 GMT) (full text, mbox, link).

Message #236 received at 868558@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Control: reopen -1
Control: retitle -1 transition: r-api-3.4
Control: user release.debian.org@packages.debian.org
Control: usertags -1 = transition

On Sun, Sep 10, 2017 at 04:15:00PM +0000, 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,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org

[signature.asc (application/pgp-signature, inline)]

Bug reopened Request was from Sébastien Villemot <sebastien@debian.org> to 868558-submit@bugs.debian.org. (Sun, 24 Sep 2017 13:39:02 GMT) (full text, mbox, link).

Changed Bug title to 'transition: r-api-3.4' from 'nmu: multiple r-* packages'. Request was from Sébastien Villemot <sebastien@debian.org> to 868558-submit@bugs.debian.org. (Sun, 24 Sep 2017 13:39:03 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Sun, 24 Sep 2017 14:09:05 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Sun, 24 Sep 2017 14:09:05 GMT) (full text, mbox, link).

Message #245 received at 868558@bugs.debian.org (full text, mbox, reply):

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.org@packages.debian.org
| Control: usertags -1 = transition
| 
| On Sun, Sep 10, 2017 at 04:15:00PM +0000, 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 | edd@debian.org

Removed tag(s) wontfix. Request was from Sébastien Villemot <sebastien@debian.org> to control@bugs.debian.org. (Mon, 25 Sep 2017 06:36:03 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Wed, 27 Sep 2017 22:36:02 GMT) (full text, mbox, link).

Acknowledgement sent to Emilio Pozuelo Monfort <pochu@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Wed, 27 Sep 2017 22:36:03 GMT) (full text, mbox, link).

Message #252 received at 868558@bugs.debian.org (full text, mbox, reply):

Control: forwarded -1 https://release.debian.org/transitions/html/r-base-3.4.html
Control: tags -1 confirmed

On 24/09/17 15:36, Sébastien Villemot wrote:
> Control: reopen -1
> Control: retitle -1 transition: r-api-3.4
> Control: user release.debian.org@packages.debian.org
> Control: usertags -1 = transition
> 
> On Sun, Sep 10, 2017 at 04:15:00PM +0000, 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.

Will do so.

Cheers,
Emilio

Set Bug forwarded-to-address to 'https://release.debian.org/transitions/html/r-base-3.4.html'. Request was from Emilio Pozuelo Monfort <pochu@debian.org> to 868558-submit@bugs.debian.org. (Wed, 27 Sep 2017 22:36:03 GMT) (full text, mbox, link).

Added tag(s) confirmed. Request was from Emilio Pozuelo Monfort <pochu@debian.org> to 868558-submit@bugs.debian.org. (Wed, 27 Sep 2017 22:36:03 GMT) (full text, mbox, link).

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 28 Sep 2017 00:51:03 GMT) (full text, mbox, link).

Acknowledgement sent to Graham Inggs <ginggs@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 28 Sep 2017 00:51:03 GMT) (full text, mbox, link).

Message #261 received at 868558@bugs.debian.org (full text, mbox, reply):

On 24 September 2017 at 15:36, Sébastien Villemot <sebastien@debian.org> wrote:
> 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/;

I had some trouble with this in Ubuntu until Stefano Rivera suggested:
is_bad = .depends ~ /r-api-3(,|$)/;

Interesting thing is that r-cran-nlp doesn't show up in the Debian tracker.
It must have missed a binNMU to pick up a dependency on 'r-api-3' in
the first place.
I wonder if there are other packages like this.

Maybe we need 'r-base-core' in is_affected as well?

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 28 Sep 2017 10:30:03 GMT) (full text, mbox, link).

Acknowledgement sent to Sébastien Villemot <sebastien@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 28 Sep 2017 10:30:03 GMT) (full text, mbox, link).

Message #266 received at 868558@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Thu, Sep 28, 2017 at 12:33:39AM +0200, Emilio Pozuelo Monfort wrote:
> Control: forwarded -1 https://release.debian.org/transitions/html/r-base-3.4.html
> Control: tags -1 confirmed
> 
> On 24/09/17 15:36, Sébastien Villemot wrote:

> > 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.
> 
> Will do so.

Thanks.

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).

Most of them are maintained by either Dirk, Debian Med or Debian Science.

I am going to take care of those maintained by the Debian Science Team.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 28 Sep 2017 10:57:05 GMT) (full text, mbox, link).

Message #271 received at 868558@bugs.debian.org (full text, mbox, reply):

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:

dichromat
r-cran-combinat
r-cran-epitools
r-cran-g.data
r-cran-genetics
r-cran-gmaps
r-cran-hwriter
r-cran-inline
r-cran-labeling
r-cran-mfilter
r-cran-misctools
r-cran-tcltk2
r-cran-tensor
r-cran-wdi
r-omegahat-xmlrpc
rcolorbrewer

Then there is permute and scatterplot3d, which don't pick up a 
dependency on r-api-3.4, and I'm not sure if they should.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 28 Sep 2017 11:24:03 GMT) (full text, mbox, link).

Acknowledgement sent to Sébastien Villemot <sebastien@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 28 Sep 2017 11:24:03 GMT) (full text, mbox, link).

Message #276 received at 868558@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

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).

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 28 Sep 2017 12:06:02 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 28 Sep 2017 12:06:03 GMT) (full text, mbox, link).

Message #281 received at 868558@bugs.debian.org (full text, mbox, reply):

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 | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 28 Sep 2017 16:57:06 GMT) (full text, mbox, link).

Acknowledgement sent to Sébastien Villemot <sebastien@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 28 Sep 2017 16:57:06 GMT) (full text, mbox, link).

Message #286 received at 868558@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

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.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 28 Sep 2017 20:36:09 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Tille <tille@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 28 Sep 2017 20:36:09 GMT) (full text, mbox, link).

Message #291 received at 868558@bugs.debian.org (full text, mbox, reply):

On Thu, Sep 28, 2017 at 06:53:26PM +0200, Sébastien Villemot wrote:
> On Thu, Sep 28, 2017 at 07:04:51AM -0500, Dirk Eddelbuettel wrote:
> 
> 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.

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)


-- 
http://fam-tille.de

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 29 Sep 2017 02:54:02 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 29 Sep 2017 02:54:02 GMT) (full text, mbox, link).

Message #296 received at 868558@bugs.debian.org (full text, mbox, reply):

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 | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 29 Sep 2017 02:54:04 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 29 Sep 2017 02:54:04 GMT) (full text, mbox, link).

Message #301 received at 868558@bugs.debian.org (full text, mbox, reply):

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 | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 29 Sep 2017 05:39:03 GMT) (full text, mbox, link).

Acknowledgement sent to Graham Inggs <ginggs@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 29 Sep 2017 05:39:03 GMT) (full text, mbox, link).

Message #306 received at 868558@bugs.debian.org (full text, mbox, reply):

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.

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
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.


[1] https://ci.debian.net/packages/r/r-bioc-iranges/unstable/amd64/
[2] https://ci.debian.net/packages/r/r-bioc-variantannotation/unstable/amd64/

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 29 Sep 2017 11:03:05 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 29 Sep 2017 11:03:05 GMT) (full text, mbox, link).

Message #311 received at 868558@bugs.debian.org (full text, mbox, reply):

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 | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 29 Sep 2017 12:39:03 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Tille <tille@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 29 Sep 2017 12:39:03 GMT) (full text, mbox, link).

Message #316 received at 868558@bugs.debian.org (full text, mbox, reply):

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

      Andreas. 

-- 
http://fam-tille.de

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 29 Sep 2017 13:15:05 GMT) (full text, mbox, link).

Acknowledgement sent to Graham Inggs <ginggs@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 29 Sep 2017 13:15:05 GMT) (full text, mbox, link).

Message #321 received at 868558@bugs.debian.org (full text, mbox, reply):

On 29 September 2017 at 12:59, Dirk Eddelbuettel <edd@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.

> | 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.

To be clear, the packages I mentioned all built against the new R, it
is only the autopkgtests that fail, and fixing them is not a
requirement for completing the transition in Debian.  In fact, the
Debian autopkgtest results [1][2] I linked to previously only tell us
that the test dependencies became unsatisfiable when the transition
started.  The test failures I'm seeing in Ubuntu [3][4], may or may
not appear in Debian once these packages become installable and the
tests can be run again.

I would greatly appreciate any hints on how to find the cause of them:

IRanges RUnit Tests - 91 test functions, 2 errors, 0 failures
ERROR in test_AtomicList_general: Error in match.arg(method) : 'arg'
must be of length 1
ERROR in test_AtomicList_numerical: Error in match.arg(method) : 'arg'
must be of length 1

VariantAnnotation RUnit Tests - 80 test functions, 1 error, 0 failures
ERROR in test_VRanges_vcf: Error in match.arg(method) : 'arg' must be
of length 1

> | [1] https://ci.debian.net/packages/r/r-bioc-iranges/unstable/amd64/
> | [2] https://ci.debian.net/packages/r/r-bioc-variantannotation/unstable/amd64/

[3] https://launchpad.net/ubuntu/+source/rgtk2/2.20.33-1build1
[4] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/r/r-bioc-iranges/20170928_193643_fa35d@/log.gz
[5] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/r/r-bioc-variantannotation/20170929_044514_9ee50@/log.gz

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 29 Sep 2017 13:27:03 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Tille <tille@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 29 Sep 2017 13:27:03 GMT) (full text, mbox, link).

Message #326 received at 868558@bugs.debian.org (full text, mbox, reply):

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
rebuild against r-api-3.4 to upload r-cran-dplyr.  R-cran-dplyr also
needs manual upload of r-cran-pkgkitten.

Graham, just for your information:  The issue with test suite was solved
in SVN but I somehow missed to upload.  Sorry.

Kind regards

      Andreas.

-- 
http://fam-tille.de

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 29 Sep 2017 14:15:02 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 29 Sep 2017 14:15:02 GMT) (full text, mbox, link).

Message #331 received at 868558@bugs.debian.org (full text, mbox, reply):

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 stooooopid 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 | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 29 Sep 2017 14:15:04 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 29 Sep 2017 14:15:04 GMT) (full text, mbox, link).

Message #336 received at 868558@bugs.debian.org (full text, mbox, reply):

On 29 September 2017 at 15:11, Graham Inggs wrote:
| On 29 September 2017 at 12:59, Dirk Eddelbuettel <edd@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 | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 29 Sep 2017 14:27:05 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Tille <tille@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 29 Sep 2017 14:27:05 GMT) (full text, mbox, link).

Message #341 received at 868558@bugs.debian.org (full text, mbox, reply):

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 stooooopid 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 and just tell me whether I should NMU or
not? 

Thank you

     Andreas.

-- 
http://fam-tille.de

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 29 Sep 2017 14:54:03 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 29 Sep 2017 14:54:03 GMT) (full text, mbox, link).

Message #346 received at 868558@bugs.debian.org (full text, mbox, reply):

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 stooooopid 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 | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 29 Sep 2017 16:00:06 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Tille <tille@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 29 Sep 2017 16:00:06 GMT) (full text, mbox, link).

Message #351 received at 868558@bugs.debian.org (full text, mbox, reply):

On Fri, Sep 29, 2017 at 09:11:41AM -0500, Dirk Eddelbuettel wrote:
> 
> 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.
> 

-- 
http://fam-tille.de

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Fri, 29 Sep 2017 16:06:03 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Tille <tille@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Fri, 29 Sep 2017 16:06:03 GMT) (full text, mbox, link).

Message #356 received at 868558@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Fri, Sep 29, 2017 at 09:11:41AM -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.

It was not that easy to find out - the attached debdiff I just uploaded
solved that issue.  If you read it and think your package is not worth
an upload I cannot comment on that.  I left other easy QA things for you
since it was only an NMU.

I repeat my honest plea to stop your rudeness to your fellow Debian
developers.  We know that there are in Free Software development who are
at the same time competent and rude.  I'd love if this place could
remain a welcoming place where people are competent an kind to each
other.

Thank you

     Andreas.

-- 
http://fam-tille.de

[codetools_0.2-15-1.1.debdiff (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Mon, 09 Oct 2017 10:03:03 GMT) (full text, mbox, link).

Acknowledgement sent to Sébastien Villemot <sebastien@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Mon, 09 Oct 2017 10:03:03 GMT) (full text, mbox, link).

Message #361 received at 868558@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Hi,

Here is a status update about the r-base 3.4 transition.

All packages have been recompiled against R 3.4, and almost all of them have
reached the required age before testing migration becomes possible.

There are still a couple of blockers, given by britney's output (in the second
autohint):

    * amd64: r-cran-maldiquantforeign, r-cran-readbrukerflexdata, r-cran-vcdextra
    * i386: r-cran-maldiquantforeign, r-cran-readbrukerflexdata, r-cran-vcdextra
    * armel: r-cran-knitr

The reasons are as follows:
- r-cran-vcdextra is too young (I had to upload it yesterday because of
  #878010)
- r-cran-readbrukerflexdata is too young (it was uploaded with urgency=low)
- r-cran-maldiquantforeign depends on the previous one
- r-cran-knitr was uninstallable on armel, because node.js is no longer
  available on that arch. I made a new upload of r-cran-knitr that makes the
  package FTBFS on armel, and I filed an RM removal for armel (#878062) (I
  asked for fast processing on #-ftp)

So we're almost there (and a couple of age-days or testing-RM could help finish
it faster, but of course it's up to the Release Team).

In the meantime, please everyone refrain from making any R-related upload, that
would only delay the transition.

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 12 Oct 2017 09:39:02 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Tille <tille@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 12 Oct 2017 09:39:02 GMT) (full text, mbox, link).

Message #366 received at 868558@bugs.debian.org (full text, mbox, reply):

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
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 <edd@debian.org>  Sat, 23 Sep 2017 11:49:56 -0500
> 
> 
> -- 
> http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org
> 
> 

-- 
http://fam-tille.de

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 12 Oct 2017 12:09:03 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 12 Oct 2017 12:09:03 GMT) (full text, mbox, link).

Message #371 received at 868558@bugs.debian.org (full text, mbox, reply):

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 <edd@debian.org>  Sat, 23 Sep 2017 11:49:56 -0500
| > 
| > 
| > -- 
| > http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org
| > 
| > 
| 
| -- 
| http://fam-tille.de

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 12 Oct 2017 12:30:05 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Tille <tille@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 12 Oct 2017 12:30:05 GMT) (full text, mbox, link).

Message #376 received at 868558@bugs.debian.org (full text, mbox, reply):

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 <edd@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.

Thank you

      Andreas.

-- 
http://fam-tille.de

Reply sent to Gianfranco Costamagna <locutusofborg@debian.org>:
You have taken responsibility. (Thu, 12 Oct 2017 12:42:06 GMT) (full text, mbox, link).

Notification sent to Dirk Eddelbuettel <edd@debian.org>:
Bug acknowledged by developer. (Thu, 12 Oct 2017 12:42:06 GMT) (full text, mbox, link).

Message #381 received at 868558-done@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

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 <edd@debian.org>
3.4.1.20170921-1 to unstable: Dirk Eddelbuettel <edd@debian.org>
3.4.1-2 to unstable: Dirk Eddelbuettel <edd@debian.org>

yes, I would say this is *your* transition.
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.

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 12 Oct 2017 12:45:02 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 12 Oct 2017 12:45:03 GMT) (full text, mbox, link).

Message #386 received at 868558@bugs.debian.org (full text, mbox, reply):

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 <edd@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 | edd@debian.org

Message #387 received at 868558-done@bugs.debian.org (full text, mbox, reply):

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 <edd@debian.org>
| 3.4.1.20170921-1 to unstable: Dirk Eddelbuettel <edd@debian.org>
| 3.4.1-2 to unstable: Dirk Eddelbuettel <edd@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 | edd@debian.org

Message #388 received at 868558-done@bugs.debian.org (full text, mbox, reply):

Hello Dirk,

>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.
>
>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".


I did play *no* role in this transition, so the "you" can't really be referred
to me :)

but reading this bug report (with zero knowledge on the topic) seems to bring the
idea that the whole world (at least the part participating in this thread), has a different
opinion than you.

Not sure who is correct, if you or the rest of the world, and honestly I don't care.
Uploading stuff when the transition is finishing is just useless and disturbing for
everybody.

If you care about your end users you should care about making r-base migrate, not
trying to make things harder for Release Team.

thanks for understanding,

(I refrained many times from taking part in this discussion, and I won't take part anymore from this post,
you are taking everything personally, and I really don't care about who is right and who is wrong,
I care about buster and nothing more)

G.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 12 Oct 2017 13:48:03 GMT) (full text, mbox, link).

Acknowledgement sent to Charles Plessy <plessy@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 12 Oct 2017 13:48:03 GMT) (full text, mbox, link).

Message #393 received at 868558@bugs.debian.org (full text, mbox, reply):

Hi Dirk and everybody

the point is that r-base and all the other packages will only migrate to
testing when all of them will be ready at the same time.  Packages need
5 days to migrate to Testing and each upload resets the counter, thus
blocking the migration of all.  Therefore, a break of 5 days without
uploads is needed if we want to see the r-* packages in Testing.

Note that according to the package tracker, r-base will be part of
another transition soon.  So it may be best to do the 5-day break before
it starts.

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 12 Oct 2017 13:57:03 GMT) (full text, mbox, link).

Acknowledgement sent to Andreas Tille <tille@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 12 Oct 2017 13:57:03 GMT) (full text, mbox, link).

Message #398 received at 868558@bugs.debian.org (full text, mbox, reply):

On Thu, Oct 12, 2017 at 07:41:35AM -0500, Dirk Eddelbuettel wrote:
> 
> | > | 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.
> ...
>
> You. Still, Don't. Get. It.

s/You. Still, Don't. Get. It/You still don't get it/	to make it a sentence
s/You/I/						to make it correct

For those readers here who were able and willing to get the message to
delay r-* uploads:  The transition bug is done and it should be fine to
start uploading those packages again.

Thanks to the release team and those who worked on this for their
cooperation

      Andreas.

-- 
http://fam-tille.de

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 12 Oct 2017 14:00:03 GMT) (full text, mbox, link).

Acknowledgement sent to Sébastien Villemot <sebastien@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 12 Oct 2017 14:00:03 GMT) (full text, mbox, link).

Message #403 received at 868558@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Thu, Oct 12, 2017 at 10:40:00PM +0900, Charles Plessy wrote:

> the point is that r-base and all the other packages will only migrate to
> testing when all of them will be ready at the same time.  Packages need
> 5 days to migrate to Testing and each upload resets the counter, thus
> blocking the migration of all.  Therefore, a break of 5 days without
> uploads is needed if we want to see the r-* packages in Testing.

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.

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 12 Oct 2017 14:15:03 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 12 Oct 2017 14:15:03 GMT) (full text, mbox, link).

Message #408 received at 868558@bugs.debian.org (full text, mbox, reply):

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 | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 12 Oct 2017 14:21:03 GMT) (full text, mbox, link).

Acknowledgement sent to Sébastien Villemot <sebastien@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 12 Oct 2017 14:21:03 GMT) (full text, mbox, link).

Message #413 received at 868558@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

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).

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄⠀⠀⠀⠀  http://www.debian.org

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 12 Oct 2017 14:39:03 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 12 Oct 2017 14:39:03 GMT) (full text, mbox, link).

Message #418 received at 868558@bugs.debian.org (full text, mbox, reply):

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 | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 12 Oct 2017 15:48:03 GMT) (full text, mbox, link).

Message #423 received at 868558@bugs.debian.org (full text, mbox, reply):

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.

Regards
Graham

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 12 Oct 2017 17:03:02 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 12 Oct 2017 17:03:02 GMT) (full text, mbox, link).

Message #428 received at 868558@bugs.debian.org (full text, mbox, reply):

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 | edd@debian.org

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 12 Oct 2017 18:18:02 GMT) (full text, mbox, link).

Message #433 received at 868558@bugs.debian.org (full text, mbox, reply):

On 12 October 2017 at 19:01, Dirk Eddelbuettel <edd@debian.org> wrote:
> 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.

That would be great, thanks!

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 12 Oct 2017 20:42:03 GMT) (full text, mbox, link).

Acknowledgement sent to Johannes Ranke <johannes.ranke@jrwb.de>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 12 Oct 2017 20:42:03 GMT) (full text, mbox, link).

Message #438 received at 868558@bugs.debian.org (full text, mbox, reply):

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&r2=7200

Johannes

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Release Team <debian-release@lists.debian.org>:
Bug#868558; Package release.debian.org. (Thu, 12 Oct 2017 21:33:03 GMT) (full text, mbox, link).

Acknowledgement sent to Dirk Eddelbuettel <edd@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Release Team <debian-release@lists.debian.org>. (Thu, 12 Oct 2017 21:33:03 GMT) (full text, mbox, link).

Message #443 received at 868558@bugs.debian.org (full text, mbox, reply):

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&r2=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 | edd@debian.org

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 10 Nov 2017 07:29:46 GMT) (full text, mbox, link).

Send a report that this bug log contains spam.

Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Oct 15 14:36:30 2020; Machine Name: bembo

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Debian Bug report logs - #868558 transition: r-api-3.4

Debian Bug report logs - #868558
transition: r-api-3.4