Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386
Hi All Just a quick update. On Sun, 23 Jul 2023 at 15:07, Graham Inggs wrote: > For what it's worth, r-cran-afex[1] and r-cran-mertools[2] **are** > passing in unstable. So perhaps whatever package fixed this condition > has been uploaded, but not yet migrated. Since rmatrix 1.6-0-1 migrated, these tests are now passing on i386 and no longer blocking the migrating of lme4. > Yet r-cran-mlmrev[3] still seems to have the timeout issue in unstable. The timeout of r-cran-mlmrev's autopkgtests on i386 is the last blocker for lme4, so I will allow lme4 to migrate and (attempt) to clone this bug to r-cran-mlmrev. As Dirk wrote: On Sun, 23 Jul 2023 at 16:32, Dirk Eddelbuettel wrote: > So if it were me I'd just skip that test file on i386 and move on. Maybe this is the sane option, but CC'ing the i386 porters (Hi Adrian!) anyway. Regards Graham
Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386
On 23 July 2023 at 11:03, Dirk Eddelbuettel wrote: | Note that the mlmRev authors / maintainers are the same as / a subset of the | lme4 authors. They may have an idea. | | https://cran.r-project.org/package=mlmRev I just ran `R CMD check mlmRev_*tar.gz` on my amd64 (under Ubuntu 23.04), it ran fine but also took a moment. In parallel I am also running it in a i386 Docker container for Debian unstable and that seems slow esp on the second file tests/lmerTest.R So if it were me I'd just skip that test file on i386 and move on. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386
On 23 July 2023 at 15:07, Graham Inggs wrote: | Hi | | On Sun, 23 Jul 2023 at 13:11, Nilesh Patra wrote: | > How do you conclude that? | > The versions of affected packages are same in unstable and testing. They | > fail in i386 with a newer version of lme4. | | For what it's worth, r-cran-afex[1] and r-cran-mertools[2] **are** | passing in unstable. Ah. So maybe I did look at that... | So perhaps whatever package fixed this condition has been uploaded, but not | yet migrated. | | Yet r-cran-mlmrev[3] still seems to have the timeout issue in unstable. Note that the mlmRev authors / maintainers are the same as / a subset of the lme4 authors. They may have an idea. https://cran.r-project.org/package=mlmRev Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386
Hi, On 23-07-2023 15:51, Dirk Eddelbuettel wrote: But if you all think we are better auto-removing lme4 over i386 fails _of packages using it_ as opposed to fails in itself then I cannot stop you. As I mentioned already, we can't even do that easily because lme4 is currently a key package, and key packages are not autoremoved [1]. Paul [1] https://release.debian.org/key-packages.html OpenPGP_signature Description: OpenPGP digital signature
Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386
Hi On Sun, 23 Jul 2023 at 13:11, Nilesh Patra wrote: > How do you conclude that? > The versions of affected packages are same in unstable and testing. They > fail in i386 with a newer version of lme4. For what it's worth, r-cran-afex[1] and r-cran-mertools[2] **are** passing in unstable. So perhaps whatever package fixed this condition has been uploaded, but not yet migrated. Yet r-cran-mlmrev[3] still seems to have the timeout issue in unstable. Regards Graham [1] https://ci.debian.net/packages/r/r-cran-afex/unstable/i386/ [2] https://ci.debian.net/packages/r/r-cran-mertools/unstable/i386/ [3] https://ci.debian.net/packages/r/r-cran-mlmrev/unstable/i386/
Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386
On 23 July 2023 at 18:42, Nilesh Patra wrote: | On Sun, 23 Jul 2023 07:15:09 -0500 Dirk Eddelbuettel wrote | > Is this is not an example of a release manager override? The affectect | > packages all work together in unstable and could migrate. | | How do you conclude that? | The versions of affected packages are same in unstable and testing. They | fail in i386 with a newer version of lme4. Sorry, my fault. I was wrong here so thanks for the correction. I looked at the bottom of one of those logs, saw a PASS and missed the FAIL preceding it. Still, it is a self-imposed problem by Debian. At some point we managed to let go of m68k too. But if you all think we are better auto-removing lme4 over i386 fails _of packages using it_ as opposed to fails in itself then I cannot stop you. That does not mean I concur with the decision. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386
On Sun, 23 Jul 2023 07:15:09 -0500 Dirk Eddelbuettel wrote > Is this is not an example of a release manager override? The affectect > packages all work together in unstable and could migrate. How do you conclude that? The versions of affected packages are same in unstable and testing. They fail in i386 with a newer version of lme4. Best, Nilesh signature.asc Description: PGP signature
Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386
Paul, Is this is not an example of a release manager override? The affectect packages all work together in unstable and could migrate. Dirk -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386
Hi Dirk, On 22-07-2023 23:14, Dirk Eddelbuettel wrote: It could be an issue as simple as CRAN (and upstream) no longer checking on i386 though it usually does not fail there. This is what I suspected, but it needs to be resolved in Debian by somebody, somehow. lme4 is a key package, removing it from i386 isn't going to be easy if at all possible. If you don't want to investigate yourself, maybe contact the i386 porter (bunk) and ask his help. Another option is to file bugs for your reverse dependencies if you believe they are at fault. At least r-cran-mlmrev isn't a key package so with an RC bug filed against it, it will be autoremoved in due time. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386
On 22 July 2023 at 21:45, Paul Gevers wrote: | Source: lme4 | Version: 1.1-31-1 | Severity: serious | Control: close -1 1.1-34-1 | X-Debbugs-CC: debia...@lists.debian.org | Tags: sid trixie | User: release.debian@packages.debian.org | Usertags: out-of-sync | | Dear maintainer(s), | | The Release Team considers packages that are out-of-sync between testing | and unstable for more than 30 days as having a Release Critical bug in | testing [1]. Your package src:lme4 has been trying to migrate for 32 | days [2]. Hence, I am filing this bug. | | The version in unstable causes 3 autopkgtest failures when tested in | testing, all on i386. The failures are due to autopkgtest timeout after | 2:47 h, while normally these tests run in minutes, so this suggests the | tests hang. In unstable, r-cran-afex and r-cran-mertools pass (so this | is probably a (set of) package(s) in unstable that also needs to migrate | together with lme4), but r-cran-mlmrev also times out in unstable. | | If a package is out of sync between unstable and testing for a longer | period, this usually means that bugs in the package in testing cannot be | fixed via unstable. Additionally, blocked packages can have impact on | other packages, which makes preparing for the release more difficult. | Finally, it often exposes issues with the package and/or | its (reverse-)dependencies. We expect maintainers to fix issues that | hamper the migration of their package in a timely manner. | | This bug will trigger auto-removal when appropriate. As with all new | bugs, there will be at least 30 days before the package is auto-removed. | | I have immediately closed this bug with the version in unstable, so if | that version or a later version migrates, this bug will no longer affect | testing. I have also tagged this bug to only affect sid and trixie, so | it doesn't affect (old-)stable. | | If you believe your package is unable to migrate to testing due to | issues beyond your control, don't hesitate to contact the Release Team. The lme4 package is in fine standing at CRAN https://cloud.r-project.org/web/checks/check_results_lme4.html and build everywhere on Debian (see this and other links) https://cloud.r-project.org/web/checks/check_results_lme4.html If three other packages (that I have nothing to do with) fail in _their autopkgtests_ may I suggest you talk to the maintainers of _those packages_? lme4 is _core_ package, written and maintained by current and former R Core members. It is one of the most widely used and watched packages around. This is most likely an issue of shooting the messenger as the root cause with be with those other packages. It could be an issue as simple as CRAN (and upstream) no longer checking on i386 though it usually does not fail there. Dirk | Paul | | [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html | [2] https://qa.debian.org/excuses.php?package=lme4 | x[DELETED ATTACHMENT OpenPGP_signature, application/pgp-signature] -- dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386
Source: lme4 Version: 1.1-31-1 Severity: serious Control: close -1 1.1-34-1 X-Debbugs-CC: debia...@lists.debian.org Tags: sid trixie User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:lme4 has been trying to migrate for 32 days [2]. Hence, I am filing this bug. The version in unstable causes 3 autopkgtest failures when tested in testing, all on i386. The failures are due to autopkgtest timeout after 2:47 h, while normally these tests run in minutes, so this suggests the tests hang. In unstable, r-cran-afex and r-cran-mertools pass (so this is probably a (set of) package(s) in unstable that also needs to migrate together with lme4), but r-cran-mlmrev also times out in unstable. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=lme4 OpenPGP_signature Description: OpenPGP digital signature
