[R-pkg-team] Processed: r-cran-tibble: autopkgtest failure with r-base (4.3.1-1)

[Sebastiaan Couwenberg]

On 6/29/23 14:41, Andreas Tille wrote:
> may be I missed your point yesterday when you said you will not file
> further bugs against r-* packages.  Was it only because your server was
> blocked from BTS server?

Yes, that got fixed today.

So I've double checked if all the packages with autopkgtest failures 
blocking r-base testing migration have bugreports.

> As I tried to express:  We try to find a sensible solution.  Simply
> adding even more bugs to the r-* packages creates work at your and our
> side and adds noise to BTS.  I do not consider this a straightforward
> way to solve the issue and recommend to stop filing such bug reports.

Without RC bugs these packages aren't going to be candidates for 
autoremoval from testing.

If the "DLL requires the use of native symbols" issues indicate an ABI 
break, that's then a good argument for a transition to get the rdeps 
rebuilt in a coordinated manner. I don't use R, or maintain any R 
packages however, so I'm staying out of that discussion.

I want to get geos (3.12.0-1) into testing, which is blocked by 
r-cran-rgeos, which in turn is blocked by r-base, which is ultimately 
blocked by these autopkgtest failures which lacked corresponding RC bugs.

I also want to get libgdal32 (3.6.4+dfsg-1) out of testing which is 
blocked by r-cran-rgdal, r-cran-sf, r-cran-terra whose testing migration 
is likewise blocked by r-base.

Now that I've ensured that the autopkgtest failures blocking this have 
RC bugs, my involvement stops.

Kind Regards,

Bas

-- 
  GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1