Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Andreas Tille]

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
diff -Nru codetools-0.2-15/debian/changelog codetools-0.2-15/debian/changelog
--- codetools-0.2-15/debian/changelog   2017-09-29 17:55:11.0 +0200
+++ codetools-0.2-15/debian/changelog   2017-09-29 17:19:40.0 +0200
@@ -1,3 +1,12 @@
+codetools (0.2-15-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * That's my life: Helping out unfriendly maintainers and set at least
+debian/source/format for them and fixing very basic bugs like
+s/${shlibs:Depends}/${misc:Depends}/
+
+ -- Andreas Tille   Fri, 29 Sep 2017 17:19:40 +0200
+
 codetools (0.2-15-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru codetools-0.2-15/debian/control codetools-0.2-15/debian/control
--- codetools-0.2-15/debian/control 2017-09-29 17:55:11.0 +0200
+++ codetools-0.2-15/debian/control 2017-09-29 17:19:40.0 +0200
@@ -7,7 +7,7 @@
 
 Package: r-cran-codetools
 Architecture: all
-Depends: ${shlibs:Depends}, ${R:Depends}
+Depends: ${misc:Depends}, ${R:Depends}
 Description: GNU R package providing code analysis tools
  This package provides functions for code analysis for R.
  .
diff -Nru codetools-0.2-15/debian/source/format 
codetools-0.2-15/debian/source/format
--- codetools-0.2-15/debian/source/format   1970-01-01 01:00:00.0 
+0100
+++ codetools-0.2-15/debian/source/format   2013-09-12 10:59:15.0 
+0200
@@ -0,0 +1 @@
+3.0 (quilt)

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Andreas Tille]

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

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Dirk Eddelbuettel]

On 29 September 2017 at 16:23, Andreas Tille wrote:
| On Fri, Sep 29, 2017 at 09:11:41AM -0500, Dirk Eddelbuettel wrote:
| > 
| > | rebuild against r-api-3.4 to upload r-cran-dplyr.
| > 
| > It so happens that I (as upstream) got Rcpp 0.12.13 onto CRAN yesterday too,
| > so I owe Debian a new r-cran-rcpp_0.12.13.
| > 
| > However, I had local server issues and some other things pop so I did not 
get
| > to this.  It if holds you up, just do a NMU for 0.12.12.
| 
| No big hurry on my side - I have sufficient other things to do until this
| will hit the archive.
|  
| > | R-cran-dplyr also needs manual upload of r-cran-pkgkitten.
| > 
| > Man this process is so stopid as I tried to explain to everybody 
(release
| > team in particular) and failed.
| > 
| > That is a binary:all package (also by me as upstream) which should not have
| > needed a new tag if only we'd been rational.
| 
| Would you please stop shouting

Get a life.

Dirk

| and just tell me whether I should NMU or | not? 
| 
| Thank you
| 
|  Andreas.
| 
| -- 
| http://fam-tille.de

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

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Andreas Tille]

On Fri, Sep 29, 2017 at 09:11:41AM -0500, Dirk Eddelbuettel wrote:
> 
> | rebuild against r-api-3.4 to upload r-cran-dplyr.
> 
> It so happens that I (as upstream) got Rcpp 0.12.13 onto CRAN yesterday too,
> so I owe Debian a new r-cran-rcpp_0.12.13.
> 
> However, I had local server issues and some other things pop so I did not get
> to this.  It if holds you up, just do a NMU for 0.12.12.

No big hurry on my side - I have sufficient other things to do until this
will hit the archive.
 
> | R-cran-dplyr also needs manual upload of r-cran-pkgkitten.
> 
> Man this process is so stopid as I tried to explain to everybody (release
> team in particular) and failed.
> 
> That is a binary:all package (also by me as upstream) which should not have
> needed a new tag if only we'd been rational.

Would you please stop shouting and just tell me whether I should NMU or
not? 

Thank you

 Andreas.

-- 
http://fam-tille.de

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Dirk Eddelbuettel]

On 29 September 2017 at 15:24, Andreas Tille wrote:
| On Fri, Sep 29, 2017 at 02:37:19PM +0200, Andreas Tille wrote:
| > On Fri, Sep 29, 2017 at 05:59:54AM -0500, Dirk Eddelbuettel wrote:
| > > 
| > > dplyr just had a new upstream CRAN release 0.7.4 yesterday. Don't know 
about
| > > the others as I am less close to BioConductor.
| > 
| > I'll upload new version soon
| 
| I have no idea why r-cran-rcpp was not bin-NMU-ed but I would need a

I cannot comment on that.

| rebuild against r-api-3.4 to upload r-cran-dplyr.

It so happens that I (as upstream) got Rcpp 0.12.13 onto CRAN yesterday too,
so I owe Debian a new r-cran-rcpp_0.12.13.

However, I had local server issues and some other things pop so I did not get
to this.  It if holds you up, just do a NMU for 0.12.12.

| R-cran-dplyr also needs manual upload of r-cran-pkgkitten.

Man this process is so stopid as I tried to explain to everybody (release
team in particular) and failed.

That is a binary:all package (also by me as upstream) which should not have
needed a new tag if only we'd been rational.

Dirk

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

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Dirk Eddelbuettel]

On 29 September 2017 at 15:11, Graham Inggs wrote:
| On 29 September 2017 at 12:59, Dirk Eddelbuettel  wrote:
| > On 29 September 2017 at 07:36, Graham Inggs wrote:
| > | rgtk2 and rggobi now FTBFS on s390x, they also fail in a Buster chroot
| > | on zelenka.debian.org so I don't believe it is a regression in R, but
| > | the binaries will need to be removed.
| >
| > Can you share details? Those are big/old gtk packages.  And when you mean
| > binaries removed you mean for s390x only or for all?
| 
| I didn't keep the build log from zelenka, but you can view a build log
| from Ubuntu [3] by following the 's390x' link.
| I mean only the s390x binaries removed.

Gotcha.

RGtk2 wraps the old gtk libraries, rggobi is one of the few packages (within
Debian) using it.   It may well be that these don't build (as RGtk is rather
demanding).  We could entertain removing them.  But for as long as they build
on the major arches may as well keep them.

Dirk

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

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Andreas Tille]

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

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Graham Inggs]

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

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Andreas Tille]

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

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Dirk Eddelbuettel]

On 29 September 2017 at 07:36, Graham Inggs wrote:
| I've been working on this transition in Ubuntu and here are some of my notes:
| 
| rgtk2 and rggobi now FTBFS on s390x, they also fail in a Buster chroot
| on zelenka.debian.org so I don't believe it is a regression in R, but
| the binaries will need to be removed.

Can you share details? Those are big/old gtk packages.  And when you mean
binaries removed you mean for s390x only or for all?
| 
| r-bioc-iranges, r-bioc-variantannotation and r-cran-dplyr need to be
| updated to work with R 3.4.2.  You can see from the autopkgtest

dplyr just had a new upstream CRAN release 0.7.4 yesterday. Don't know about
the others as I am less close to BioConductor.

| results [1][2] that started failing on 2017-09-24.  Unfortunately,
| r-cran-dplyr 0.5.0-1 has always failed its autopkgtests, so the
| results aren't useful.

dplyr 0.5.0 is ridiculously outdated that it is (IMHO) probably not worth
looking at. That should have become 0.6.* and 0.7.* a few times over.

For what it is worth all my systems do of course have current dplyr, but I
install that directly from CRAN into /usr/local.

Dirk

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

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

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Graham Inggs]

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/

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Dirk Eddelbuettel]

On 28 September 2017 at 22:22, Andreas Tille wrote:
| I wonder if we could teach dh-r to make sure that is added to arch:all
| packages.  I'm converting all packages I'm touching to dh-r anyway.
| 
| At least a lintian warning might help.
| 
| Kind regards
| 
|   Andreas (after having uploaded 4 arch:all packages and converted
|two of these from cdbs to dh-r)

Yes, maybe indeed. dh-r is one of those many things on the always-growing
TODO list that I have not yet gotten to.

Dirk

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

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Dirk Eddelbuettel]

On 28 September 2017 at 18:53, Sébastien Villemot wrote:
| On Thu, Sep 28, 2017 at 07:04:51AM -0500, Dirk Eddelbuettel wrote:
| > 
| > On 28 September 2017 at 13:20, Sébastien Villemot wrote:
| > | On Thu, Sep 28, 2017 at 12:53:10PM +0200, Graham Inggs wrote:
| > | > On 28/09/2017 12:28, Sébastien Villemot wrote:
| > | > > Note that there are many arch:all R packages that will need sourceful 
upload
| > | > > (they are easy to identify on the transition tracker whose URL is 
above).
| > | > 
| > | > Besides r-cran-nlp which doesn't show up in the tracker, I've found 
several
| > | > other arch:all packages that don't depend on r-api-3, but do pick up a
| > | > dependency on r-api-3.4 after a rebuild:
| > | 
| > | This makes me wonder whether arch:all packages really need a dependency 
on r-api-*.
| > | 
| > | If this value really tracks an API, as advertised, it makes sense. But if 
it
| > | actually tracks an ABI, as in the present case, then this situation is
| > | suboptimal and complicates transition.
| > | 
| > | Maybe the best solution would therefore be to dissociate API and ABI 
tracking.
| > | 
| > | Moreover, packages automatically pick up a versioned dependency on 
r-base-core.
| > | But this should not be necessary since we now have ABI tracking. It makes
| > | dependencies uselessly tight.
| > | 
| > | Anyways, these (potential) improvements should probably wait for the next
| > | transition (planned in April if I understand correctly).
| > 
| > There transitions, and then there are transitions.  Let me explain:
| > 
| > - right now a subset of 'source: any' package needs a rebuild; here we could
| >   in fact discuss leaving 'source: all' out
| > 
| > - R 3.5.0 will need a rebuild of all 'source: any' packages
| > 
| > - In the past we rebuilds for nonAPI reasons: reorganisation of R's internal
| >   help system (and internal file format) was one
| > 
| > So we may as well through the big mantle of the so-called "API" transition
| > around all dependent packages.  But we don't _have to_ right now.
| > 
| > Can be argued either way. Do as you see fit.
| 
| I now understand that we ideally need two API/ABI-like values instead of one:
| 
| - one that is bumped when only arch:any packages need to be rebuilt
| 
| - the other one that is bumped when both arch:any and arch:all packages should
|   be rebuilt
| 
| The first value would appear in the Depends of arch:any package, but not of
| arch:all ones; the second value would appear in the Depends of both arch:any
| and arch:all.
| 
| Because, for this transition and for the next one (in April), we will have to
| make sourceful uploads of ~170 arch:all packages… that actually do not need to
| be rebuilt. And this is very painful because it must be done manually 
(contrary
| to rebuilds of arch:any packages that can be trigerred easily).
| 
| If we adopted this scheme right now, that would save us a lot of work for the
| April transition (but not for this one, because we first have to convert
| arch:all packages to the new scheme).
| 
| Please tell me what you think.

Well, sorry, but that is your baby now. I argued _this very issue of it being
different for R_ for two months or more, but nobody bought into it.

You all insisted on this approach which you now find more complicate, so here
it is.  Your deal now.

(For what it is worth, and the R / Debian itersection in particular, the
RcppAPT (source) package allows you to query R's and Debian's package
meta-data.  That was part of my analysis so I won't repeat it.  Happy to help
if there are questions.)

I'll happily deal with / help with technical questions, I am not that
interested in managing a technical issue I argued (in vain) against for some
time.

Sorry, Dirk

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

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Andreas Tille]

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

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Sébastien Villemot]

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
Description: PGP signature

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Dirk Eddelbuettel]

On 28 September 2017 at 13:20, Sébastien Villemot wrote:
| On Thu, Sep 28, 2017 at 12:53:10PM +0200, Graham Inggs wrote:
| > On 28/09/2017 12:28, Sébastien Villemot wrote:
| > > Note that there are many arch:all R packages that will need sourceful 
upload
| > > (they are easy to identify on the transition tracker whose URL is above).
| > 
| > Besides r-cran-nlp which doesn't show up in the tracker, I've found several
| > other arch:all packages that don't depend on r-api-3, but do pick up a
| > dependency on r-api-3.4 after a rebuild:
| 
| This makes me wonder whether arch:all packages really need a dependency on 
r-api-*.
| 
| If this value really tracks an API, as advertised, it makes sense. But if it
| actually tracks an ABI, as in the present case, then this situation is
| suboptimal and complicates transition.
| 
| Maybe the best solution would therefore be to dissociate API and ABI tracking.
| 
| Moreover, packages automatically pick up a versioned dependency on 
r-base-core.
| But this should not be necessary since we now have ABI tracking. It makes
| dependencies uselessly tight.
| 
| Anyways, these (potential) improvements should probably wait for the next
| transition (planned in April if I understand correctly).

There transitions, and then there are transitions.  Let me explain:

- right now a subset of 'source: any' package needs a rebuild; here we could
  in fact discuss leaving 'source: all' out

- R 3.5.0 will need a rebuild of all 'source: any' packages

- In the past we rebuilds for nonAPI reasons: reorganisation of R's internal
  help system (and internal file format) was one

So we may as well through the big mantle of the so-called "API" transition
around all dependent packages.  But we don't _have to_ right now.

Can be argued either way. Do as you see fit.

Dirk

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

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Sébastien Villemot]

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
Description: PGP signature

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Graham Inggs]

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.

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Sébastien Villemot]

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
Description: PGP signature

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Graham Inggs]

On 24 September 2017 at 15:36, Sébastien Villemot  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?

Processed: Re: Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Debian Bug Tracking System]

Processing control commands:

> forwarded -1 https://release.debian.org/transitions/html/r-base-3.4.html
Bug #868558 [release.debian.org] transition: r-api-3.4
Set Bug forwarded-to-address to 
'https://release.debian.org/transitions/html/r-base-3.4.html'.
> tags -1 confirmed
Bug #868558 [release.debian.org] transition: r-api-3.4
Added tag(s) confirmed.

-- 
868558: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868558
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Emilio Pozuelo Monfort]

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@packages.debian.org
> Control: usertags -1 = transition
> 
> On Sun, Sep 10, 2017 at 04:15:00PM +, Niels Thykier wrote:
> 
>> To be perfectly, honest, I would prefer if you did a proper ABI-like
>> transition over the Breaks.  At this scale, Breaks seems too fragile and
>> too likely for people to get wrong.
> 
> The latest upload of r-base, versioned 3.4.1.20170921-1, has bumped the ABI
> pseudo package from "r-api-3" to "r-api-3.4", as requested.
> 
> Please therefore schedule rebuilds as necessary.

Will do so.

Cheers,
Emilio

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Dirk Eddelbuettel]

On 24 September 2017 at 15:36, Sébastien Villemot wrote:
| Control: reopen -1
| Control: retitle -1 transition: r-api-3.4
| Control: user release.debian@packages.debian.org
| Control: usertags -1 = transition
| 
| On Sun, Sep 10, 2017 at 04:15:00PM +, Niels Thykier wrote:
| 
| > To be perfectly, honest, I would prefer if you did a proper ABI-like
| > transition over the Breaks.  At this scale, Breaks seems too fragile and
| > too likely for people to get wrong.
| 
| The latest upload of r-base, versioned 3.4.1.20170921-1, has bumped the ABI
| pseudo package from "r-api-3" to "r-api-3.4", as requested.
| 
| Please therefore schedule rebuilds as necessary.
| 
| The ben file should look like:
| 
| title = "r-api-3.4";
| is_affected = .depends ~ /r-api-3(\.4)?/;
| is_good = .depends ~ /r-api-3\.4/;
| is_bad = .depends ~ /r-api-3\b/;
| 
| Thanks,

This is somewhat the wrong bug report to attach this to as I argued (sadly,
in vain) for a different approach here in #868558. Maybe #861333, retitled by
Don to 'API transition of R packages' would have been more approriate.

I would just have filed a new one.  But then I don't know those commands so
thanks for doing this.

Dirk

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

Processed (with 2 errors): transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Debian Bug Tracking System]

Processing control commands:

> reopen -1
Bug #868558 {Done: Andreas Tille } [release.debian.org] nmu: 
multiple r-* packages
Bug reopened
Ignoring request to alter fixed versions of bug #868558 to the same values 
previously set
> retitle -1 transition: r-api-3.4
Bug #868558 [release.debian.org] nmu: multiple r-* packages
Changed Bug title to 'transition: r-api-3.4' from 'nmu: multiple r-* packages'.
> user release.debian@packages.debian.org
Unknown command or malformed arguments to command.

> usertags -1 = transition
Unknown command or malformed arguments to command.


-- 
868558: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868558
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]

[Sébastien Villemot]

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

On Sun, Sep 10, 2017 at 04:15:00PM +, Niels Thykier wrote:

> To be perfectly, honest, I would prefer if you did a proper ABI-like
> transition over the Breaks.  At this scale, Breaks seems too fragile and
> too likely for people to get wrong.

The latest upload of r-base, versioned 3.4.1.20170921-1, has bumped the ABI
pseudo package from "r-api-3" to "r-api-3.4", as requested.

Please therefore schedule rebuilds as necessary.

The ben file should look like:

title = "r-api-3.4";
is_affected = .depends ~ /r-api-3(\.4)?/;
is_good = .depends ~ /r-api-3\.4/;
is_bad = .depends ~ /r-api-3\b/;

Thanks,

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


signature.asc
Description: PGP signature

Re: Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

On 11 September 2017 at 18:00, Andreas Tille wrote:
| On Mon, Sep 11, 2017 at 08:55:58AM -0500, Dirk Eddelbuettel wrote:
| > 
| > On 11 September 2017 at 15:36, Andreas Tille wrote:
| > | IMHO the best way to deal with this would have been by doing a mass bug
| > | filing against those packages which were in need of an upgrade.  This
| > | would have attracted the attention of the according maintainers directly
| > | and would have led to action more quickly (at least I confirm this in my
| > | case).
| > 
| > The Policy manual advises against doing that.
| 
| What section are you refering to?

I always confuse the different manuals.  The language that discourage me is
here and uses 10 as an upper limit:

https://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#submit-many-bugs

So I went the route of preparing binNMUs. In hindsight I did not get the
outcome I desired, but for different reasons.

Dirk

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

Re: Bug#868558: nmu: multiple r-* packages

[Andreas Tille]

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

Re: Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

On 11 September 2017 at 15:36, Andreas Tille wrote:
| IMHO the best way to deal with this would have been by doing a mass bug
| filing against those packages which were in need of an upgrade.  This
| would have attracted the attention of the according maintainers directly
| and would have led to action more quickly (at least I confirm this in my
| case).

The Policy manual advises against doing that.

Dirk

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

Re: Bug#868558: nmu: multiple r-* packages

[Andreas Tille]

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

Re: Bug#868558: nmu: multiple r-* packages

[Niels Thykier]

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
Description: OpenPGP digital signature

Re: Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

On 10 September 2017 at 16:15, Niels Thykier wrote:
| To be perfectly, honest, I would prefer if you did a proper ABI-like
| transition over the Breaks.  At this scale, Breaks seems too fragile and
| too likely for people to get wrong.

I *am* -- all packages (currently) get have r-api-3:

  edd@bud:~$ apt-cache show r-cran-rcpp | grep r-api-3
  Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libstdc++6 (>= 5.2), 
r-base-core (>= 3.3.1-1), r-api-3, littler, r-cran-pkgkitten
  edd@bud:~$ 
|
Next April they will have r-api-4.  *This case* did not warrant puzting with
r-api-* and you will have to take my word for it.

| > Dear debian-release:  Please remove this block.
| > 
| I respectfully decline.

That's truly and madly saddening. So I will just code around you and direct
users to a different repo.  We have been doing that via an informal backports
repo available at all CRAN mirrors anyway.

It's too bad, but we all have our standards to live by.

Apparently I am now rogue as far as the release teams goes. Life goes on.

Dirk

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

Re: Bug#868558: nmu: multiple r-* packages

[Niels Thykier]

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
Description: OpenPGP digital signature

Re: Bug#868558: nmu: multiple r-* packages

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

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

Bug#868558: nmu: multiple r-* packages

[Emilio Pozuelo Monfort]

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

Bug#868558: nmu: multiple r-* packages

[Sébastien Villemot]

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
Description: PGP signature

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

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

Bug#868558: nmu: multiple r-* packages

[Sébastien Villemot]

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.f663j3gykjcxo...@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
Description: PGP signature

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

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

Bug#868558: nmu: multiple r-* packages

[Sébastien Villemot]

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
Description: PGP signature

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

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

Bug#868558: nmu: multiple r-* packages

[Niels Thykier]

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
Description: OpenPGP digital signature

Processed: Re: Bug#868558: nmu: multiple r-* packages

[Debian Bug Tracking System]

Processing control commands:

> tags -1 wontfix
Bug #868558 [release.debian.org] nmu: multiple r-* packages
Added tag(s) wontfix.

-- 
868558: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868558
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#868558: nmu: multiple r-* packages

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

Bug#868558: nmu: multiple r-* packages

[Andreas Beckmann]

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

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

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

Bug#868558: nmu: multiple r-* packages

[Sébastien Villemot]

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
Description: PGP signature

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

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

Bug#868558: nmu: multiple r-* packages

[Emilio Pozuelo Monfort]

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

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

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

Bug#868558: nmu: multiple r-* packages

[Steve Cotton]

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

Bug#868558: nmu: multiple r-* packages

[Steve Cotton]

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

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

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

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

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

Bug#868558: nmu: multiple r-* packages

[Emilio Pozuelo Monfort]

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

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

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

Bug#868558: nmu: multiple r-* packages

[Emilio Pozuelo Monfort]

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

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

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

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

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

Bug#868558: nmu: multiple r-* packages

[Niels Thykier]

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

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

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

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

Processed: Re: Bug#868558: nmu: multiple r-* packages

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 868558 serious
Bug #868558 [release.debian.org] nmu: multiple r-* packages
Severity set to 'serious' from 'normal'
> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
868558: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868558
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

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

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

Hi Andreas,

On 10 August 2017 at 15:36, Andreas Beckmann wrote:
| On Sun, 6 Aug 2017 08:15:17 -0500 Dirk Eddelbuettel  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 | e...@debian.org

Bug#868558: nmu: multiple r-* packages

[Andreas Beckmann]

On Sun, 6 Aug 2017 08:15:17 -0500 Dirk Eddelbuettel  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

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

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

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

Dear release team,

On 16 July 2017 at 10:40, Dirk Eddelbuettel wrote:
| 
| Package: release.debian.org
| User: release.debian@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 

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

Package: release.debian.org
User: release.debian@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