On 25/09/25 at 12:14 +0300, Adrian Bunk wrote: > On Thu, Sep 25, 2025 at 10:33:31AM +0200, Lucas Nussbaum wrote: > > On 25/09/25 at 10:00 +0200, Paul Gevers wrote: > > > I'm wondering if we > > > should hold off migrating cmake 4 while we're waiting a bit for > > > autoremoval > > > to do its job (including sending notifications). Or should we be more > > > aggressive with manual removal? What do you think? > > > > I wonder if we should decrease the auto-removal timeouts to make it > > easier to get broken packages out of testing (and new packages in > > testing) and increase it again later in the release cycle. > > > > There's some value to faster transitions even if that means temporarily > > removing non-key packages from testing. There's plenty of time to get > > them back in testing. > > Your suggestion might not result in faster transitions. > > As long as the autopkgtest of at least one key package gets broken > (as is the case for CMake) it's either a manual hint to ignore > autopkgtest failures or no migration.
Ah, right > Of the ~ 800 CMake 4 bugs only ~ 30 might have relevance for > migration.[1] > > BTW: The first key package with an autopkgtest broken by CMake 4 > I looked at does not even have a bug (libzstd). And there are others. I came up with a UDD query to combine the pseudo-excuses data with bugs[1], and could not identify corresponding bugs for the following autopkgtest regressions: double-conversion fastcdr (ppc64el only) ffc foonathan-memory khronos-opencl-headers libsfml libthread-pool libzstd msgpack-c msgpack-cxx mshr (ppc64el only) nvidia-cuda-samples (ppc64el only) Also, capnproto has #1095942 but I'm not sure it's relevant and clfft has #1112789 but it is marked as done, so it's worth re-checking. Lucas [1] with pseudo_exc_cmake as ( select policy_info['autopkgtest'] as test_results from migration_excuses_experimental where source='cmake' ), res1 as ( select split_part(d.key, '/', 1) as source, split_part(d.key, '/', 2) as version, d.value as result from pseudo_exc_cmake, jsonb_each(pseudo_exc_cmake.test_results) as d where d.key != 'verdict' ), res2 as ( select source, version, d.key as architecture, d.value->>0 as result, d.value as details from res1, jsonb_each(res1.result) as d ), regressions as ( select distinct source, version, architecture from res2 where result = 'REGRESSION' ), cmake_bugs as ( select * from bugs where title ~* 'cmake' ) select distinct r.source, r.architecture, id, severity, status, title from regressions r left join cmake_bugs using (source);
