Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
Am Wed, May 17, 2023 at 02:07:22PM +0530 schrieb Nilesh Patra: > On Wed, May 17, 2023 at 08:58:58AM +0200, Andreas Tille wrote: > > I hope I was following developers reference about t-p-u[6] correctly > > and pushed > > I've choosen the version 1.7.4+dfsg-3~deb12u1 to match > > the requirement that the version is lower than in unstable > > I guess this should be alright. But as per devref, you may want to choose > "1.7.4+dfsg-2+deb12u1". This was my first consideration. However, the changes simply fit to 1.7.4+dfsg-3 and by using the '~' separator the "smaller version than in unstable" is fulfilled as well. I don't mind much actually - just to explain my choice. > > I wonder whether dput is working with target distribution bookworm since > > lintian throws an error. > > It probably should. There's a d/ch entry I found for argon2 package > here[7] in case that helps you. Thanks for confirming. > > Release team is in CC - do you think I should > > file a bug right now or just after an upload? > > devref says "Ask for authorization for uploading from the release > managers." > > So I suppose it makes sense to file a bug before you upload and ping > them back again once you upload as per Yepp, I'll do so and will ask what they consider the more sensible version number. > "After uploading and successful build on all platforms, contact the > release team at debian-rele...@lists.debian.org and ask them to approve > your upload." Will do so. Kind regards Andreas. > > > > > [1] > > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > > > > > [2] > > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > > > > > [3] > > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > > > > > [4] > > > > > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ > > > > [5] https://wiki.debian.org/TestingProposedUpdates > > [6] > > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u > [7] > https://tracker.debian.org/news/1429925/accepted-argon2-020171227-03deb12u1-source-into-testing-proposed-updates/ > > -- > Best, > Nilesh -- http://fam-tille.de
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On Wed, May 17, 2023 at 08:58:58AM +0200, Andreas Tille wrote: > Am Tue, May 16, 2023 at 07:49:55PM +0530 schrieb Nilesh Patra: > > On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: > > > I personally prefer "1" over 2 as it is less noise (and effort). > > > > On second thoughts, I think sending it via testing-proposed-updates > > would be a better thing to do, as this case perfectly fits the problem. > > I hope I was following developers reference about t-p-u[6] correctly > and pushed > I've choosen the version 1.7.4+dfsg-3~deb12u1 to match > the requirement that the version is lower than in unstable I guess this should be alright. But as per devref, you may want to choose "1.7.4+dfsg-2+deb12u1". > I wonder whether dput is working with target distribution bookworm since > lintian throws an error. It probably should. There's a d/ch entry I found for argon2 package here[7] in case that helps you. > Release team is in CC - do you think I should > file a bug right now or just after an upload? devref says "Ask for authorization for uploading from the release managers." So I suppose it makes sense to file a bug before you upload and ping them back again once you upload as per "After uploading and successful build on all platforms, contact the release team at debian-rele...@lists.debian.org and ask them to approve your upload." > > > > [1] > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > > > > [2] > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > > > > [3] > > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > > > > [4] > > > > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ > > > [5] https://wiki.debian.org/TestingProposedUpdates > [6] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u [7] https://tracker.debian.org/news/1429925/accepted-argon2-020171227-03deb12u1-source-into-testing-proposed-updates/ -- Best, Nilesh signature.asc Description: PGP signature
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
Hi again, Am Tue, May 16, 2023 at 07:49:55PM +0530 schrieb Nilesh Patra: > On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: > > I personally prefer "1" over 2 as it is less noise (and effort). > > On second thoughts, I think sending it via testing-proposed-updates > would be a better thing to do, as this case perfectly fits the problem. I hope I was following developers reference about t-p-u[6] correctly and pushed $ git diff HEAD^ diff --git a/debian/changelog b/debian/changelog index 21d12c3..a2b6c26 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +r-cran-shiny (1.7.4+dfsg-3~deb12u1) bookworm; urgency=medium + + * Upload to testing-proposed-updates "bookworm" due to the fact that +there was an accidental upload of a new version of r-base to unstable + + -- Andreas Tille Wed, 17 May 2023 07:56:25 +0200 + r-cran-shiny (1.7.4+dfsg-3) unstable; urgency=medium * Fix link for normalize.css to git. I've choosen the version 1.7.4+dfsg-3~deb12u1 to match the requirement that the version is lower than in unstable $ if dpkg --compare-versions 1.7.4+dfsg-3 gt 1.7.4+dfsg-3~deb12u1 ; then echo "OK" ; else echo "hmmm" ; fi OK I wonder whether dput is working with target distribution bookworm since lintian throws an error. Release team is in CC - do you think I should file a bug right now or just after an upload? Kind regards Andreas. > > > [1] > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > > > [2] > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > > > [3] > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > > > [4] > > > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ > > [5] https://wiki.debian.org/TestingProposedUpdates [6] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u -- http://fam-tille.de
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On 16 May 2023 at 20:13, Nilesh Patra wrote: | Uh, no. Maybe you misunderstood my suggestion. The t-p-u way was for Indeed! | r-base can continue to stay where it already is at the moment :) Yep. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On Tue, May 16, 2023 at 09:31:20AM -0500, Dirk Eddelbuettel wrote: > > On 16 May 2023 at 19:49, Nilesh Patra wrote: > | On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: > | > I personally prefer "1" over 2 as it is less noise (and effort). > | > | On second thoughts, I think sending it via testing-proposed-updates > | would be a better thing to do, as this case perfectly fits the problem. > | > | It's be same effort in both cases (one upload + filing a bug with release > team). > > Reading 'https://wiki.debian.org/TestingProposedUpdates' does indeed suggest > that this may be one of those situations. I can easily prepare a 4.3.0-2 > with that destination but would prefer if someone from the release could > 'nod', maybe in reply to this email. Uh, no. Maybe you misunderstood my suggestion. The t-p-u way was for r-cran-shiny not the r-base package. This is because r-cran-shiny would want to build against r-base in testing (and not unstable). Uploading a 4.3.0-2 of r-base would mean uploading a new r-base to testing without a proper transition and without re-compilation of API-incompatible graphics related packages -- that'd be quite the havoc in testing (and eventually next stable). It also violates some of the rules of t-p-u -- more details here[1] in case you are interested. r-base can continue to stay where it already is at the moment :) [1]: https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u -- Best, Nilesh signature.asc Description: PGP signature
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
Am Tue, May 16, 2023 at 07:49:55PM +0530 schrieb Nilesh Patra: > On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: > > I personally prefer "1" over 2 as it is less noise (and effort). > > On second thoughts, I think sending it via testing-proposed-updates > would be a better thing to do, as this case perfectly fits the problem. Seems to be an appropriate solution - given we should stick to smallest changes in packaging if possible. > It's be same effort in both cases (one upload + filing a bug with release > team). Since I will not manage to do so in the next 16 hours I'd be happy if someone might beat me in doing so. Otherwise I can catch up tomorrow. Thanks a lot for your hint Andreas. > > Let me know what you think. > > > > [1] > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > > > [2] > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > > > [3] > > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > > > [4] > > > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ > > [5] https://wiki.debian.org/TestingProposedUpdates > > -- > Best, > Nilesh -- http://fam-tille.de
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On 16 May 2023 at 19:49, Nilesh Patra wrote: | On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: | > I personally prefer "1" over 2 as it is less noise (and effort). | | On second thoughts, I think sending it via testing-proposed-updates | would be a better thing to do, as this case perfectly fits the problem. | | It's be same effort in both cases (one upload + filing a bug with release team). Reading 'https://wiki.debian.org/TestingProposedUpdates' does indeed suggest that this may be one of those situations. I can easily prepare a 4.3.0-2 with that destination but would prefer if someone from the release could 'nod', maybe in reply to this email. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On Tue, May 16, 2023 at 07:25:15PM +0530, Nilesh Patra wrote: > I personally prefer "1" over 2 as it is less noise (and effort). On second thoughts, I think sending it via testing-proposed-updates would be a better thing to do, as this case perfectly fits the problem. It's be same effort in both cases (one upload + filing a bug with release team). > Let me know what you think. > > [1] > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > > [2] > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > > [3] > > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > > [4] > > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ > [5] https://wiki.debian.org/TestingProposedUpdates -- Best, Nilesh signature.asc Description: PGP signature
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On 16 May 2023 at 19:25, Nilesh Patra wrote: | On Tue, May 16, 2023 at 03:01:10PM +0200, Andreas Tille wrote: | > when fixing bug #1035428 I realised test suite issues with | > | > r-cran-thematic [1] | >-> Error in `svglite_(filename, bg, width, height, pointsize, standalone, | > always_valid)`: Graphics API version mismatch | > | > r-cran-treescape [2] | > r-cran-treespace [3] | >-> error is given if lambda is outside of [0,1] --- | > `medTree(trees, -1)` did not throw an error. | > | > As far as I can guess at least the first type of error (Graphics API | > version mismatch) is caused by the fact that a new upstream version of | > r-base (4.3.0-1) was uploaded to unstable (changelog[4] says to | > experimental so it seems by accident). | | I can think of two ways: | | 1. r-cran-shiny is an arch:all package, so the package itself being | built against r-base 4.3.0 is not an issue. The issue is the | "r-base-core (>= 4.3.0-1)" that dh-r injects, which is being pulled in | the autopkgtests of its reverse-depends. | Changing that to "r-base-core (>= 4.2.2.20221110-2)" manually should do | the trick. | | Something on the lines of: | | override_dh_gencontrol: | dh_gencontrol | sed "s/r-base-core (>= 4.3.0-1)/r-base-core (>= 4.2.2.20221110-2)" -i debian/r-cran-shiny/DEBIAN/control | | Ofcourse, the hard-coding of 4.3.0-1 can be converted to some better | regular expression. Nice catch and suggestion! On 16 May 2023 at 19:27, Nilesh Patra wrote: | On Tue, May 16, 2023 at 08:26:21AM -0500, Dirk Eddelbuettel wrote: | > Note that none of this affects the release. My recommendation is temporarily | > suspend the autopkgtest in those affected packages. | | No, don't do that as they indicate a new r-base being pulled as one of | the dependencies (which would be incorrect for a package). In this case, | r-cran-shiny has a hard-dependency on r-base. | | Once that is fixed, rest of the things should be sorted out. I agree. Thanks for pointing that out. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On Tue, May 16, 2023 at 08:26:21AM -0500, Dirk Eddelbuettel wrote: > Note that none of this affects the release. My recommendation is temporarily > suspend the autopkgtest in those affected packages. No, don't do that as they indicate a new r-base being pulled as one of the dependencies (which would be incorrect for a package). In this case, r-cran-shiny has a hard-dependency on r-base. Once that is fixed, rest of the things should be sorted out. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
Hi On Tue, May 16, 2023 at 03:01:10PM +0200, Andreas Tille wrote: > when fixing bug #1035428 I realised test suite issues with > > r-cran-thematic [1] >-> Error in `svglite_(filename, bg, width, height, pointsize, standalone, > always_valid)`: Graphics API version mismatch > > r-cran-treescape [2] > r-cran-treespace [3] >-> error is given if lambda is outside of [0,1] --- > `medTree(trees, -1)` did not throw an error. > > As far as I can guess at least the first type of error (Graphics API > version mismatch) is caused by the fact that a new upstream version of > r-base (4.3.0-1) was uploaded to unstable (changelog[4] says to > experimental so it seems by accident). I can think of two ways: 1. r-cran-shiny is an arch:all package, so the package itself being built against r-base 4.3.0 is not an issue. The issue is the "r-base-core (>= 4.3.0-1)" that dh-r injects, which is being pulled in the autopkgtests of its reverse-depends. Changing that to "r-base-core (>= 4.2.2.20221110-2)" manually should do the trick. Something on the lines of: override_dh_gencontrol: dh_gencontrol sed "s/r-base-core (>= 4.3.0-1)/r-base-core (>= 4.2.2.20221110-2)" -i debian/r-cran-shiny/DEBIAN/control Ofcourse, the hard-coding of 4.3.0-1 can be converted to some better regular expression. 2. It makes a valid and strong case to use t-p-u (see here[5]) for such an upload, as it isn't a possibility to build against R in testing. You might want to ask release team about it, by filing a bug for release.d.o pseudo-package and/or asking in #debian-release on OFTC. I personally prefer "1" over 2 as it is less noise (and effort). Let me know what you think. > [1] > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz > [2] > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz > [3] > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz > [4] > https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ [5] https://wiki.debian.org/TestingProposedUpdates -- Best, Nilesh signature.asc Description: PGP signature
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
On 16 May 2023 at 15:01, Andreas Tille wrote: | Hi, | | when fixing bug #1035428 I realised test suite issues with | | r-cran-thematic [1] |-> Error in `svglite_(filename, bg, width, height, pointsize, standalone, | always_valid)`: Graphics API version mismatch | | r-cran-treescape [2] | r-cran-treespace [3] |-> error is given if lambda is outside of [0,1] --- | `medTree(trees, -1)` did not throw an error. | | As far as I can guess at least the first type of error (Graphics API | version mismatch) is caused by the fact that a new upstream version of | r-base (4.3.0-1) was uploaded to unstable (changelog[4] says to | experimental so it seems by accident). Yes. It was very much by accident, and my bad. When the freeze hardened and I switched uploading from unstable to experimental (on March 15 per my mail folder of installer replies, and coincidentally with the R 4.2.3-1 upload), I managed to update the distribution field (often using 'C-x d' in the handy Emacs mode) in the debian/changelog file each and every time --- with the one exception of the next update of r-base to the 4.3.0 release :-/ | I wonder what might be the most sensible strategy to fix this. Since | an epoch is considered ugly I've seen some kind of | 4.3.0+really+4.2.2.20221110 | version number. However, in case of R it might not be the best idea | to use this kind of fake version in a stable release. I think we shouldn't. Apart from this test issue, the binary sits in unstable and will remain in unstable. The change is graphics format is a repeat of previous micro-API changes from upstream where Paul Murrell (who is the one taking care of the graphics device) enhances its capabilities (often in quite meaningful ways). The R Core team does not consider this a breaking change, and does recommend or mandate rebuilds of the nearly 20k CRAN packages. I happen to concur. However, when a package built with such a graphics api version 'A' is loaded by R of version 'B' (and it usually happens to us the other way) the package load simply errors out with a message. This is not fatal -- it is just a hint to rebuild the package under the R version used. I have always been of the pragmatic view that is indeed good enough. (Johannes of the back-porters team disagrees, he reminded me of a simple search for the one code line doing the check. Running that at the GitHub mirror of CRAN (which is a superset as it includes packages that once were on CRAN but are no longer) I identified ten packages of which about half or more are no longer on CRAN. For us it is likely `ragg` and `svglite`. I can dig out the details from my reply to Johannes.) Note that none of this affects the release. My recommendation is temporarily suspend the autopkgtest in those affected packages. They did their job and found the mismatch with the R 4.3.0 in unstable that shouldn't have been uploaded there. Out the about fifty package uploads I made since I switched to experimental, one went to wrong repo. That was not intentional but I think we can manage. Best, Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1035428: Test suite issues due to new upstream version of r-core in unstable (Was: r-cran-shiny: broken symlink: ...)
Hi, when fixing bug #1035428 I realised test suite issues with r-cran-thematic [1] -> Error in `svglite_(filename, bg, width, height, pointsize, standalone, always_valid)`: Graphics API version mismatch r-cran-treescape [2] r-cran-treespace [3] -> error is given if lambda is outside of [0,1] --- `medTree(trees, -1)` did not throw an error. As far as I can guess at least the first type of error (Graphics API version mismatch) is caused by the fact that a new upstream version of r-base (4.3.0-1) was uploaded to unstable (changelog[4] says to experimental so it seems by accident). I wonder what might be the most sensible strategy to fix this. Since an epoch is considered ugly I've seen some kind of 4.3.0+really+4.2.2.20221110 version number. However, in case of R it might not be the best idea to use this kind of fake version in a stable release. Kind regards Andreas. [1] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-thematic/33619891/log.gz [2] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treescape/33619892/log.gz [3] https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-treespace/33619893/log.gz [4] https://tracker.debian.org/news/1429562/accepted-r-base-430-1-source-into-unstable/ -- http://fam-tille.de
