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

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