A possibly easier way to check dependencies for 2Removal?
grep-dctrl -w -F Depends,Recommends -s Source "python-$module" /var/lib/apt/lists/*_debian_dists_sid_main_binary-amd64_Packages ; grep-dctrl -w -s Package "python-$module" /var/lib/apt/lists/*_debian_dists_sid_main_source_Sources where python-$module is the *binary* package name. This finds runtime Depends/Recommends, and all mentions in the Sources index (Build-Depends*, Testsuite-Triggers, and the package itself): Outputs only this package's source name => ready to be removed Outputs other source package(s) => not ready yet Outputs nothing => package doesn't exist (either it's already been removed, or you mis-spelt it) (Previous suggestions in this thread were "apt-cache rdepends python-$module ; reverse-depends -b python-$module" (can be slow) or "dak rm -R -n -b python-$module" (DDs only); those both ignore autopkgtest depends.)
Re: Streamlining the use of Salsa CI on team packages
Raphael Hertzog: > Hi, > > On Sun, 15 Sep 2019, Louis-Philippe Véronneau wrote: >> For step 1, I proposed we use the "Salsa Pipeline" [1], as I feel it is >> the most mature solution, has more contributors and has more features >> (including reprotest and piuparts). This option seems to have had the >> most support so far. > > Ack. I also deployed this pipeline on 500 Kali packages at > https://gitlab.com/kalilinux/packages/ > and it has been working relatively well. There are a couple > of remaining issues but the project is evolving quickly and I'm > confident that we can get past them. > > One of the issue is related to the fact that the CI build does not bump > the version and it can conflict with the version in the archive and it > will often confuse piuparts. > https://salsa.debian.org/salsa-ci-team/pipeline/issues/78 > > The project is a bit lacking in terms of leadership/guidance and there are > pending issues that should have been resolved more quickly to avoid > confusion and better define the rules: > https://salsa.debian.org/salsa-ci-team/pipeline/issues/84 > https://salsa.debian.org/salsa-ci-team/pipeline/issues/76 > https://salsa.debian.org/salsa-ci-team/pipeline/issues/86 > >> For step 2, so far people seemed to agree that: >> >> * having a standardised CI pipeline is a good idea >> * the CI should be used as a tool to help us improve our packages, and >> not be required to pass > > On this, I disagree. The CI should pass, but it's perfectly OK to > disable some of the failing tests to make it pass. We want merge requests > to run the CI and we want them to succeed to prove that they are not > making the package regress compared to the current situation. > > Consider that the package tracker is likely to display the CI status at > some point. > > Note that for merge request, it won't really work until > https://gitlab.com/gitlab-org/gitlab/issues/30242 gets fixed in GitLab. That's a good point. The tests that are there should be required to pass, otherwise they can be removed, run manually, run in dev branches, or set to "allow_failure: true" in a specific job. That reminds me of a related topic I've been thinking about: should salsa's GitLab-CI setup be considered its own test tool, or just purely a conduit for the other standard Debian test methods (lintian, autopkgtest, piuparts, reprotest, etc). I'm on the fence about this, so I opened this discussion: https://salsa.debian.org/salsa-ci-team/pipeline/issues/111 .hc
Re: Streamlining the use of Salsa CI on team packages
Hi, On Sun, 15 Sep 2019, Louis-Philippe Véronneau wrote: > For step 1, I proposed we use the "Salsa Pipeline" [1], as I feel it is > the most mature solution, has more contributors and has more features > (including reprotest and piuparts). This option seems to have had the > most support so far. Ack. I also deployed this pipeline on 500 Kali packages at https://gitlab.com/kalilinux/packages/ and it has been working relatively well. There are a couple of remaining issues but the project is evolving quickly and I'm confident that we can get past them. One of the issue is related to the fact that the CI build does not bump the version and it can conflict with the version in the archive and it will often confuse piuparts. https://salsa.debian.org/salsa-ci-team/pipeline/issues/78 The project is a bit lacking in terms of leadership/guidance and there are pending issues that should have been resolved more quickly to avoid confusion and better define the rules: https://salsa.debian.org/salsa-ci-team/pipeline/issues/84 https://salsa.debian.org/salsa-ci-team/pipeline/issues/76 https://salsa.debian.org/salsa-ci-team/pipeline/issues/86 > For step 2, so far people seemed to agree that: > > * having a standardised CI pipeline is a good idea > * the CI should be used as a tool to help us improve our packages, and > not be required to pass On this, I disagree. The CI should pass, but it's perfectly OK to disable some of the failing tests to make it pass. We want merge requests to run the CI and we want them to succeed to prove that they are not making the package regress compared to the current situation. Consider that the package tracker is likely to display the CI status at some point. Note that for merge request, it won't really work until https://gitlab.com/gitlab-org/gitlab/issues/30242 gets fixed in GitLab. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/ signature.asc Description: PGP signature
