Bug#951821: gegl: FTBFS on arm*/mips* architectures; testing migration blocked
Version: 0.4.22-3 On Sat, 22 Feb 2020 at 00:23:13 -0500, Boyuan Yang wrote: > The latest upload of package gegl was made on 2019-11-21 and it never migrated > to Debian Testing. [...] > Looking into the current status, it fails to build on all ARM and MIPS > architectures. This appears to have been resolved by the changes I made in 0.4.22-2 and -3. smcv
Bug#951821: gegl: FTBFS on arm*/mips* architectures; testing migration blocked
On Sat, 22 Feb 2020 at 00:23:13 -0500, Boyuan Yang wrote: > Looking into the current status, it fails to build on all ARM and MIPS > architectures. The reasons are mostly timeout in tests. Please make some > investigation and consider increasing the timeout limit or ignore test errors > during building. I recently uploaded gegl_0.4.22-2 which increases the timeout on slower architectures. This reveals that there were several different failure modes: - Some tests were genuinely just slow. Previously, they often timed out on the slower machines; now they pass. - gegl:simple / backend-file sometimes times out with no output, especially on the arm* family (but an upstream bug report suggests that this can also happen on x86_64). I've opened a separate FTBFS bug #954197 to represent this. - The "tests/compositions/reference/rgbe-save.hdr" step in gegl:compositions / compositions_without_opencl fails on mipsel (only): the composed image differs from the reference. I've opened a separate FTBFS bug #954196 to represent this. - gegl:simple / buffer-sharing failing on Hurd appears to be Hurd-specific. We already had #892238 (non-RC). - gegl:ff-load-save / ff-load-save fails on ia64, which appears to be because examples/frame-counter segfaults. I am reluctant to ignore test failures on arm* and mips*, because those are precisely the sort of architectures where we claim that packages work, but due to their much smaller number of users, automated tests are our only actual evidence that those packages really do work. On Thu, 12 Mar 2020 at 15:36:20 -0400, Boyuan Yang wrote: > On Sun, 23 Feb 2020 00:05:54 +0100 Andreas Henriksson > wrote: > > I'm disabling parallel tests via 'dh_auto_test --no-parallel' now > > but it seems there are more test failures on the archs where > > the build failed previously. > > Any progress on it? If it still takes much time, I suggest we force single- > thread build first and investigate later since the current FTBFS is blocking > many packages. Forcing serial testing was already done since 2020-02-22, in 0.4.22-1. smcv
Bug#951821: gegl: FTBFS on arm*/mips* architectures; testing migration blocked
X-Debbugs-CC: andr...@fatal.se Hi Andreas, On Sun, 23 Feb 2020 00:05:54 +0100 Andreas Henriksson wrote: > On Sat, Feb 22, 2020 at 06:23:36PM +0100, Andreas Henriksson wrote: > > On Sat, Feb 22, 2020 at 05:21:08PM +0100, Andreas Henriksson wrote: > > > Hello Boyuan Yang, > > > > > > Thanks for your bug report. > > > > > > On Sat, Feb 22, 2020 at 12:23:13AM -0500, Boyuan Yang wrote: > > > > Source: gegl > > > > Version: 0.4.18-2 > > > > Severity: serious > > > > Justification: out-of-sync unstable-to-testing > > > > X-Debbugs-CC: jbi...@debian.org > > > [...] > > > > FWIW I might have noticed that the problem is possibly related > > to building on a single core machine rather than an arch- or > > machinespeed-specific problem. > > > > Atleast using MESON_TESTTHREADS=1 when running the test-suite makes > > the gegl:simple / backend-file timeout for me. > > Oh, SORRY! Actually it's the opposite. When running the tests in > parallel the backend-file test times out. > > I'm disabling parallel tests via 'dh_auto_test --no-parallel' now > but it seems there are more test failures on the archs where > the build failed previously. > > Also see the previously filed bug #888769 for more (mips-specific?) > investigations. Any progress on it? If it still takes much time, I suggest we force single- thread build first and investigate later since the current FTBFS is blocking many packages. -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#951821: gegl: FTBFS on arm*/mips* architectures; testing migration blocked
On Sat, Feb 22, 2020 at 06:23:36PM +0100, Andreas Henriksson wrote: > On Sat, Feb 22, 2020 at 05:21:08PM +0100, Andreas Henriksson wrote: > > Hello Boyuan Yang, > > > > Thanks for your bug report. > > > > On Sat, Feb 22, 2020 at 12:23:13AM -0500, Boyuan Yang wrote: > > > Source: gegl > > > Version: 0.4.18-2 > > > Severity: serious > > > Justification: out-of-sync unstable-to-testing > > > X-Debbugs-CC: jbi...@debian.org > > [...] > > FWIW I might have noticed that the problem is possibly related > to building on a single core machine rather than an arch- or > machinespeed-specific problem. > > Atleast using MESON_TESTTHREADS=1 when running the test-suite makes > the gegl:simple / backend-file timeout for me. Oh, SORRY! Actually it's the opposite. When running the tests in parallel the backend-file test times out. I'm disabling parallel tests via 'dh_auto_test --no-parallel' now but it seems there are more test failures on the archs where the build failed previously. Also see the previously filed bug #888769 for more (mips-specific?) investigations. Regards, Andreas Henriksson
Bug#951821: gegl: FTBFS on arm*/mips* architectures; testing migration blocked
On Sat, Feb 22, 2020 at 05:21:08PM +0100, Andreas Henriksson wrote: > Hello Boyuan Yang, > > Thanks for your bug report. > > On Sat, Feb 22, 2020 at 12:23:13AM -0500, Boyuan Yang wrote: > > Source: gegl > > Version: 0.4.18-2 > > Severity: serious > > Justification: out-of-sync unstable-to-testing > > X-Debbugs-CC: jbi...@debian.org > [...] FWIW I might have noticed that the problem is possibly related to building on a single core machine rather than an arch- or machinespeed-specific problem. Atleast using MESON_TESTTHREADS=1 when running the test-suite makes the gegl:simple / backend-file timeout for me. Regards, Andreas Henriksson
Bug#951821: gegl: FTBFS on arm*/mips* architectures; testing migration blocked
Hello Boyuan Yang, Thanks for your bug report. On Sat, Feb 22, 2020 at 12:23:13AM -0500, Boyuan Yang wrote: > Source: gegl > Version: 0.4.18-2 > Severity: serious > Justification: out-of-sync unstable-to-testing > X-Debbugs-CC: jbi...@debian.org [...] > Looking into the current status, it fails to build on all ARM and MIPS [...] Please inform the architecture porters for the affected architectures. I don't think the more or less defunct Debian GNOME Team to have resources to handle this or atleast not make it high enough in priority to do arch porting work. Preferably the arch porters will work this out with upstream (and for extra bonus keep making sure there are people working in collaboration with upstream to make sure arch specific problems doesn't arise again). Ping the Debian GNOME Team again with which commits should be cherry-picked once they're merged upstream. Another option would be to have the (likely massive) reverse dependency tree of packages removed on these architectures, but I guess you'll have a hard time convincing the ftp-team of going through that and removing everything so I guess that's only a theoretical option. Regards, Andreas Henriksson
Bug#951821: gegl: FTBFS on arm*/mips* architectures; testing migration blocked
Source: gegl Version: 0.4.18-2 Severity: serious Justification: out-of-sync unstable-to-testing X-Debbugs-CC: jbi...@debian.org Dear gegl maintainers, The latest upload of package gegl was made on 2019-11-21 and it never migrated to Debian Testing. According to https://lists.debian.org/debian-devel-announce/2020/02/msg5.html , packages that are out-of-sync between testing and unstable for more than 60 days are considered as having Release Critical bugs. This is blocking reverse- dependencies like GIMP from migrating to Testing. Looking into the current status, it fails to build on all ARM and MIPS architectures. The reasons are mostly timeout in tests. Please make some investigation and consider increasing the timeout limit or ignore test errors during building. -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
