On Thu, Nov 28, 2024 at 01:28:09AM +0100, Santiago Vila wrote: > El 28/11/24 a las 0:07, Holger Levsen escribió: > > On Wed, Nov 27, 2024 at 07:17:24PM +0100, Santiago Vila wrote: > > > Because the fix you have in mind involves bothering a lot of people, > > > or worse, a few people with a lot of work, while the intermediate > > > status proposed by Bill fixes all the undesired effects you > > > have listed before. > > > > but then I will still want to bother all those people^wpackages > > eventually. > > Such process has already started. наб has already reported several > bugs (with severity:normal). Maybe this is not very orthodox without > a MBF email in -devel first, but so be it. I think "normal" is completely ok > at this point. I also opened MRs for all (or close-to-all?) the packages on Salsa that are on Salsa and can take MRs (and calibre on github). The bugs were only sent for the packages with no valid VCS (as a basis for justifying either NMUs or salvaging later).
> I hope наб (in CCO) will find the way to tell Jonas about his 150 packages > without filing 150 different bugs. I'm not sold on this being the best approach either way. Initially I've assessed it thus: > out of the 313 build-deps on dh-buildinfo 226 are in topic teams, > going by the VCS fields (128 perl + 5 python + 19 science + > 27 js + 45 multimedia + 2 haskell) and 30 more in collab-maint/debian, > so one'd expect the 39 stragglers to be the most problematic And this seems to hold IMO. The perl packages are all going to be relatively uniform, so iterating over PGPASSWORD=udd-mirror psql --port=5432 --host=udd-mirror.debian.net --username=udd-mirror udd -c 'select vcs_url from sources where (build_depends like '\''%dh-buildinfo%'\'' or build_depends_arch like '\''%dh-buildinfo%'\'' or build_depends_indep like '\''%dh-buildinfo%'\'') and release = '\''sid'\'' and vcs_url like '\''%perl-team%'\'';' + https://salsa.debian.org/perl-team/modules/packages/perlrdf.git + https://salsa.debian.org/perl-team/modules/packages/libcatalyst-view-petal-perl.git (both on salsa but not uploaded since the move) in a mostly-mechanised fashion by any uploading team member (something like gbp clone "$1" cd "$(expr "$1" : '.*/\(.*\)\.git')" sed -i -e '/^[[:space:]]*dh-buildinfo[,]*$/d' -e 's/,[[:space:]]*dh-buildinfo//' debian/control grep buildinfo debian/rules && $SHELL git commit -am 'd/control: Build-Depends: remove dh-buildinfo (see #1068809)' gbp dch -R --team --spawn-editor=never git commit -am "Upload $(IFS="$IFS()" read -r pkg v _ < debian/changelog; echo $pkg $v) to unstable" gbp buildpackage -S gbp tag git push && git push --tags worked for me on a random sample of a few from the list) and clicking through it thusly seems much more sensible than micro-managing each uploader separately. The same should apply to packages team-maintained by other teams. If you want to avoid mass-uploading 200 packages, then just committing the removal and letting it get picked up with the next upload should be even less controversial (but considering how long the tail gets, given perlrdf and libcatalyst-view-petal-perl, well.). I'd click through this if I could, but I can't, so I focused on the packages that were less automatable.
signature.asc
Description: PGP signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/reproducible-builds
