Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest
FWIW both packages are pristinely clean at CRAN with current versions: https://cran.r-project.org/web/checks/check_results_DoseFinding.html https://cloud.r-project.org/web/checks/check_results_multcomp.html These problems still seem self-imposed to me. We (maybe randomly ?) appear to be checking (maybe out-of-sync ?) permutations that upstream (ie CRAN) does not see. The whole issue is odd _because CRAN already does all the checking_ and we do not fundamentally alter packages, or R. So I still think that we could potentially save ourselves a lot of grief if we aligned more with what CRAN already does. But I said that before, and nobody seems to agree so Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest
Hi Andreas, On 19-08-2019 21:16, Andreas Tille wrote: > So the bug was first filed against r-cran-multcomp, The bug was filed against *both* packages, as I always do when it isn't totally clear from the failure to which package it belongs. > reassigned to > r-cran-dosefinding by edd, who refuses to look into these kind of issues. > where the test is OK in sid but the issue is blocking > the migration. I admit I neither have any idea how to fix this. When the test is successful in sid, it suggests that there is a combination of packages that need to migrate together to bullseye to be successful. If we want to help r-cran-multcomp migrate, it would be helpful to know the combination that is needed. Then we can figure out which package needs to grow which kind of dependency. > If its rather a matter of the bug severity downgrading it manually could > enable the migration. I have no idea whether this is the right course > of action but otherwise it looks like a deadlock for me. The migration is *not* blocked by this bug report, so severity doesn't help. The migration is blocked because the autopkgtest of r-cran-dosefinding in bullseye fails when run with the binary packages from multcomp together with a whole set of other packages deemed necessary (by britney based on package relations) from unstable. And that is the subject of this report (albeit missing the "in bullseye" part). As said, I am hoping that without doing anything, things will be all right in a couple of days. If not, r-base migration will simplify finding the issue a lot. Paul signature.asc Description: OpenPGP digital signature
Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest
Control: tags -1 help Hi Paul, On Mon, Aug 19, 2019 at 08:54:03PM +0200, Paul Gevers wrote: > Hi Andreas, > > On Mon, 19 Aug 2019 11:57:05 +0200 Andreas Tille > wrote: > > I wonder whether we can close this bug since the test is passing > > in unstable (with r-cran-multcomp 1.4-10-2). > > No, because currently it is blocking the migration of r-cran-multcomp. > Apparently r-cran-multcomp isn't making sure that the right stuff is > pulled into testing when it is testing r-cran-dosefinding. I am hoping > that r-cran migrates soon with lots of r stuff, maybe after that it is > "fixed". There is still a breaks missing somewhere I guess, but I don't > know where. So the bug was first filed against r-cran-multcomp, reassigned to r-cran-dosefinding where the test is OK in sid but the issue is blocking the migration. I admit I neither have any idea how to fix this. If its rather a matter of the bug severity downgrading it manually could enable the migration. I have no idea whether this is the right course of action but otherwise it looks like a deadlock for me. Kind regards Andreas. -- http://fam-tille.de
Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest
reassign 924514 r-cran-dosefinding thanks The relationship between 'multcomp' and 'DoseFinding' is, as seen on the upstream package for 'DoseFinding' at http://cloud.r-project.org/package=DoseFinding in its DESCRIPTION file: Suggests: numDeriv, Rsolnp, quadprog, parallel, multcomp so 'multcomp' is only suggested. Further, as one can see browsing the code (via the CRAN mirror at GitHub) at https://github.com/cran/DoseFinding there is exactly one use here (per a search for multcompin these sources) https://github.com/cran/DoseFinding/search?q=multcomp_q=multcomp and that is generation of data in one testfile. As such I will not consider myself with the bug in package 'multcomp'. I suggest the DoseFinding maintainer get in touch with its upstream. Thanks, Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest
Hi Dirk, On Fri, Mar 15, 2019 at 05:50:38AM -0500, Dirk Eddelbuettel wrote: > | > If it breaks in Suggests, you "get to keep the pieces". I do not have the > | > time to investigate what I consider to be a non-problems. Happy to help, > but > | > this is self-inflicted. > | > | In how far it is self-inflicted if some R package does not pass its test > | suite? > > It has no issues at CRAN as I stated. The package is fine. If our process > shows up errors I consider it self-inflicted. I'm sorry, but I fail to understand. What we are doing is to run the test suite shipped by upstream of DoseFinding. Am I understand you correctly that we should not run the test provided by upstream in our packages? From my point of view specifically the fact that we've found some incompatibility between package A (r-cran-dosefinding) and one of the packages its needs to run its test suite B (r-cran-multcimp) is a good reason that we are doing this. IMHO it means that there is some reason for action. This might be either fixing the code of package A or B or simply fixing the test suite of package B. My perception of Debian maintainership is to uncover this kind of issues. Kind regards Andreas. PS: I remember you once was offended since I moved a discussion about some topic about a specific issue that turned to become generic about packaging from Debian R list to debian-devel. I never understood why you were offended about this but since I see some generic problem that becomes abstracted here as well it might turn out that I do so in some future reply of mine. -- http://fam-tille.de
Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest
On 15 March 2019 at 07:49, Andreas Tille wrote: | On Thu, Mar 14, 2019 at 06:27:35AM -0500, Dirk Eddelbuettel wrote: | > | > | > No issue at CRAN for multcomp: | > | > | > | >https://cloud.r-project.org/web/checks/check_results_multcomp.html | > | > | > | > So this is likely self-inflicted at Debian. | > | | > | @Dirk: Could you please be more verbose in how far that link is a sign | > | that DoseFinding 0.9-16 works with multcomp 1.4-10. | > | > It is a table of checks across architectures and R version. None shows an issue. | > | > CRAN run reverse-depends on all package updates prior to admitting to CRAN. | > | > multcomp being on CRAN means there was no issue with its reverse depends. | | Thanks for the clarification. | | > CRAN may not check Suggests. I argued for years we should not either. | | I do not follow discussions on CRAN but I'd consider warnings about | issues with Suggests a nice feature. | | > If it breaks in Suggests, you "get to keep the pieces". I do not have the | > time to investigate what I consider to be a non-problems. Happy to help, but | > this is self-inflicted. | | In how far it is self-inflicted if some R package does not pass its test | suite? It has no issues at CRAN as I stated. The package is fine. If our process shows up errors I consider it self-inflicted. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest
On Thu, Mar 14, 2019 at 06:27:35AM -0500, Dirk Eddelbuettel wrote: > > | > No issue at CRAN for multcomp: > | > > | >https://cloud.r-project.org/web/checks/check_results_multcomp.html > | > > | > So this is likely self-inflicted at Debian. > | > | @Dirk: Could you please be more verbose in how far that link is a sign > | that DoseFinding 0.9-16 works with multcomp 1.4-10. > > It is a table of checks across architectures and R version. None shows an > issue. > > CRAN run reverse-depends on all package updates prior to admitting to CRAN. > > multcomp being on CRAN means there was no issue with its reverse depends. Thanks for the clarification. > CRAN may not check Suggests. I argued for years we should not either. I do not follow discussions on CRAN but I'd consider warnings about issues with Suggests a nice feature. > If it breaks in Suggests, you "get to keep the pieces". I do not have the > time to investigate what I consider to be a non-problems. Happy to help, but > this is self-inflicted. In how far it is self-inflicted if some R package does not pass its test suite? Kind regards Andreas. -- http://fam-tille.de
Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest
On 14 March 2019 at 11:03, Andreas Tille wrote: | Control: forwarded -1 Bjoern Bornkamp | | (@Bjoern: For the full issue please read |https://bugs.debian.org/924514 | which is probably more relevant for DoseFinding debugging | than the Debian specific things below. ) | | Hi, | | On Wed, Mar 13, 2019 at 03:58:14PM -0500, Dirk Eddelbuettel wrote: | > | > On 13 March 2019 at 21:39, Paul Gevers wrote: | > | Source: multcomp, r-cran-dosefinding | > | Control: found -1 multcomp/1.4-10-1 | > | Control: found -1 r-cran-dosefinding/0.9-16-2 | > | Severity: important | > | X-Debbugs-CC: debian...@lists.debian.org | > | User: debian...@lists.debian.org | > | Usertags: breaks needs-update | > | | > | Dear maintainers, | > | | > | With a recent upload of multcomp the autopkgtest of r-cran-dosefinding | > | fails in testing when that autopkgtest is run with the binary packages | > | of multcomp from unstable. It passes when run with only packages from | > | testing. In tabular form: | > |passfail | > | multcomp from testing1.4-10-1 | > | r-cran-dosefinding from testing0.9-16-2 | > | versioned deps [0] from testingfrom unstable | > | all others from testingfrom testing | > | > No issue at CRAN for multcomp: | > | >https://cloud.r-project.org/web/checks/check_results_multcomp.html | > | > So this is likely self-inflicted at Debian. | | @Dirk: Could you please be more verbose in how far that link is a sign | that DoseFinding 0.9-16 works with multcomp 1.4-10. It is a table of checks across architectures and R version. None shows an issue. CRAN run reverse-depends on all package updates prior to admitting to CRAN. multcomp being on CRAN means there was no issue with its reverse depends. CRAN may not check Suggests. I argued for years we should not either. If it breaks in Suggests, you "get to keep the pieces". I do not have the time to investigate what I consider to be a non-problems. Happy to help, but this is self-inflicted. Truly sorry, Dirk | @Paul: I think its not really relevant for Buster release since multcomp | will not migrate due to freeze so for the moment I will not do anthing | for the moment (may be after Buster release DoseFinding maintainers at | CRAN found a solution - otherwise we need to do something about this). | | > Also, DoseFinding only _Suggests:_ multcomp | > | >https://cloud.r-project.org/web/packages/DoseFinding/index.html | | That's correct. But due to the use in the autopkgtest and the test | script is provided in the doc directory as example for users dh-r | upgrades those Suggests to Recommends[1]. | | Kind regards | |Andreas. | | [1] https://salsa.debian.org/r-pkg-team/dh-r/blob/master/dh/R.pm#L192 | | | | | I copied some of the output at the bottom of this report. Unfortunately, | | there is no error reported, but successful runs have more output. | | | | Due to the nature of this issue, I filed this bug report against both | | packages. Can you please investigate the situation and reassign the bug | | to the right package? If needed, please change the bug's severity. | | | | More information about this bug and the reason for filing it can be found on | | https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation | | | | Paul | | | | [0] You can see what packages were added from the second line of the log | | file quoted below. The migration software adds source package from | | unstable to the list if they are needed to install packages from | | multcomp/1.4-10-1. I.e. due to versioned dependencies or breaks/conflicts. | | | | https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-dosefinding/2099783/log.gz | | | | autopkgtest [23:10:49]: test run-unit-test: [--- | | testgFit.R passed | | testplanMod.R passed | | testsDesign.R passed | | testsFitting.R passed | | testsMCPMod.R passed | | autopkgtest [23:10:55]: test run-unit-test: ---] | | | | [DELETED ATTACHMENT signature.asc, application/pgp-signature] | | | -- | http://fam-tille.de -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest
Control: forwarded -1 Bjoern Bornkamp (@Bjoern: For the full issue please read https://bugs.debian.org/924514 which is probably more relevant for DoseFinding debugging than the Debian specific things below. ) Hi, On Wed, Mar 13, 2019 at 03:58:14PM -0500, Dirk Eddelbuettel wrote: > > On 13 March 2019 at 21:39, Paul Gevers wrote: > | Source: multcomp, r-cran-dosefinding > | Control: found -1 multcomp/1.4-10-1 > | Control: found -1 r-cran-dosefinding/0.9-16-2 > | Severity: important > | X-Debbugs-CC: debian...@lists.debian.org > | User: debian...@lists.debian.org > | Usertags: breaks needs-update > | > | Dear maintainers, > | > | With a recent upload of multcomp the autopkgtest of r-cran-dosefinding > | fails in testing when that autopkgtest is run with the binary packages > | of multcomp from unstable. It passes when run with only packages from > | testing. In tabular form: > |passfail > | multcomp from testing1.4-10-1 > | r-cran-dosefinding from testing0.9-16-2 > | versioned deps [0] from testingfrom unstable > | all others from testingfrom testing > > No issue at CRAN for multcomp: > >https://cloud.r-project.org/web/checks/check_results_multcomp.html > > So this is likely self-inflicted at Debian. @Dirk: Could you please be more verbose in how far that link is a sign that DoseFinding 0.9-16 works with multcomp 1.4-10. @Paul: I think its not really relevant for Buster release since multcomp will not migrate due to freeze so for the moment I will not do anthing for the moment (may be after Buster release DoseFinding maintainers at CRAN found a solution - otherwise we need to do something about this). > Also, DoseFinding only _Suggests:_ multcomp > >https://cloud.r-project.org/web/packages/DoseFinding/index.html That's correct. But due to the use in the autopkgtest and the test script is provided in the doc directory as example for users dh-r upgrades those Suggests to Recommends[1]. Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/dh-r/blob/master/dh/R.pm#L192 | I copied some of the output at the bottom of this report. Unfortunately, | there is no error reported, but successful runs have more output. | | Due to the nature of this issue, I filed this bug report against both | packages. Can you please investigate the situation and reassign the bug | to the right package? If needed, please change the bug's severity. | | More information about this bug and the reason for filing it can be found on | https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation | | Paul | | [0] You can see what packages were added from the second line of the log | file quoted below. The migration software adds source package from | unstable to the list if they are needed to install packages from | multcomp/1.4-10-1. I.e. due to versioned dependencies or breaks/conflicts. | | https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-dosefinding/2099783/log.gz | | autopkgtest [23:10:49]: test run-unit-test: [--- | testgFit.R passed | testplanMod.R passed | testsDesign.R passed | testsFitting.R passed | testsMCPMod.R passed | autopkgtest [23:10:55]: test run-unit-test: ---] | | [DELETED ATTACHMENT signature.asc, application/pgp-signature] -- http://fam-tille.de
Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest
On 13 March 2019 at 21:39, Paul Gevers wrote: | Source: multcomp, r-cran-dosefinding | Control: found -1 multcomp/1.4-10-1 | Control: found -1 r-cran-dosefinding/0.9-16-2 | Severity: important | X-Debbugs-CC: debian...@lists.debian.org | User: debian...@lists.debian.org | Usertags: breaks needs-update | | Dear maintainers, | | With a recent upload of multcomp the autopkgtest of r-cran-dosefinding | fails in testing when that autopkgtest is run with the binary packages | of multcomp from unstable. It passes when run with only packages from | testing. In tabular form: |passfail | multcomp from testing1.4-10-1 | r-cran-dosefinding from testing0.9-16-2 | versioned deps [0] from testingfrom unstable | all others from testingfrom testing No issue at CRAN for multcomp: https://cloud.r-project.org/web/checks/check_results_multcomp.html So this is likely self-inflicted at Debian. Also, DoseFinding only _Suggests:_ multcomp https://cloud.r-project.org/web/packages/DoseFinding/index.html Dirk | I copied some of the output at the bottom of this report. Unfortunately, | there is no error reported, but successful runs have more output. | | Due to the nature of this issue, I filed this bug report against both | packages. Can you please investigate the situation and reassign the bug | to the right package? If needed, please change the bug's severity. | | More information about this bug and the reason for filing it can be found on | https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation | | Paul | | [0] You can see what packages were added from the second line of the log | file quoted below. The migration software adds source package from | unstable to the list if they are needed to install packages from | multcomp/1.4-10-1. I.e. due to versioned dependencies or breaks/conflicts. | | https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-dosefinding/2099783/log.gz | | autopkgtest [23:10:49]: test run-unit-test: [--- | testgFit.R passed | testplanMod.R passed | testsDesign.R passed | testsFitting.R passed | testsMCPMod.R passed | autopkgtest [23:10:55]: test run-unit-test: ---] | | [DELETED ATTACHMENT signature.asc, application/pgp-signature] -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest
Source: multcomp, r-cran-dosefinding Control: found -1 multcomp/1.4-10-1 Control: found -1 r-cran-dosefinding/0.9-16-2 Severity: important X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainers, With a recent upload of multcomp the autopkgtest of r-cran-dosefinding fails in testing when that autopkgtest is run with the binary packages of multcomp from unstable. It passes when run with only packages from testing. In tabular form: passfail multcomp from testing1.4-10-1 r-cran-dosefinding from testing0.9-16-2 versioned deps [0] from testingfrom unstable all others from testingfrom testing I copied some of the output at the bottom of this report. Unfortunately, there is no error reported, but successful runs have more output. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? If needed, please change the bug's severity. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [0] You can see what packages were added from the second line of the log file quoted below. The migration software adds source package from unstable to the list if they are needed to install packages from multcomp/1.4-10-1. I.e. due to versioned dependencies or breaks/conflicts. https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-dosefinding/2099783/log.gz autopkgtest [23:10:49]: test run-unit-test: [--- testgFit.R passed testplanMod.R passed testsDesign.R passed testsFitting.R passed testsMCPMod.R passed autopkgtest [23:10:55]: test run-unit-test: ---] signature.asc Description: OpenPGP digital signature
