Otto Kekäläinen <otto@debian.org> writes: > Hi Simon! > > Please go to https://salsa.debian.org/jas/golang-go.crypto/-/pipelines/new > and for variable 'SALSA_CI_DISABLE_BUILD_REVERSE_DEPENDENCIES' set > value '0' and run it, so we can see what is the state of at least some > of the reverse deps. If the majority is failing, then we might not > want to upload to experimental yet, but if most are passing, then > upload is ok and fixing one package at a time in experimental makes > sense. It is running now: https://salsa.debian.org/jas/golang-go.crypto/-/pipelines/947073 > I already ran for the baseline > https://salsa.debian.org/otto/golang-go.crypto/-/pipelines/946961 so > there is something to compare to. Seems that at least etcd is already > failing with current version in unstable. Great to have a baseline! Your azure-sdk job ran out of disk space, and the etcd self-tests has often failed for me earlier so I tend to ignore those failures on Salsa. So the baseline loks good (as should be expected). Why did your pipeline get no debian unstable jobs, but my pipeline did? The apptainer and caddy jobs fail in my pipeline, and doesn't exist in your pipeline, but they seem to have FTBFS issues in unstable anyway so they can be ignored. Is this because I build the debian/experimental branch and you built debian/sid? When doing reverse builds for pre-upload checks, maybe reverse building everything in testing make more sense than unstable? Is it possible to tell Salsa CI pipeline that? Revbuilding packages in testing is what is important. Any diff between testing and unstable is probably work in progress that is easier to fix than any FTBFS of a testing package. That said, even if there is a lot of breakage, I think we need to upload to unstable because we can't be stuck on old Go crypto. Anything breaking needs to be fixed, or removed from testing. But let's see build results and analyze them a bit more first... /Simon
Attachment:
signature.asc
Description: PGP signature