fixed 1102241 0.4.0-1 thanks Santiago Vila <sanv...@debian.org> writes:
> github.com/openpubkey/opkssh > # github.com/openpubkey/opkssh > src/github.com/openpubkey/opkssh/main.go:183:5: not enough arguments in call > to choosers.NewWebChooser > have ([]providers.BrowserOpenIdProvider) > want ([]providers.BrowserOpenIdProvider, bool) That problem happens when building opkssh version 0.3.0-1 using golang-github-openpubkey-openpubkey-dev version 0.8.0-1. I'm not sure exactly of the timing of events, but things could have happened like this: - I upload opkssh+golang-github-openpubkey-openpubkey+builddeps a couple of days to NEW, and the ftp-masters are really quick (thank you!) at reviewing things - golang-github-openpubkey-openpubkey 0.7.3-1 is ACCEPTED from NEW - opkssh 0.3.0-1 is REJECTED from NEW due to its built-using golang-filippo-bigmod 0.0.3-1 not being in the archive (when I uploaded opkssh 0.3.0-1 it was the then-current version, but the archive is a moving target): daklib.archive.ArchiveException: o/opkssh/opkssh_0.3.0-1_amd64.deb: Built-Using refers to package golang-filippo-bigmod (= 0.0.3-1) not in target archive ftp-master. - I upload golang-github-openpubkey-openpubkey 0.8.0-1 (at this point in time it had no reverse dependency in unstable) - I upload opkssh 0.3.0-1 again to NEW built using versions in unstable which happen to still be golang-github-openpubkey-openpubkey 0.7.3-1 - golang-github-openpubkey-openpubkey 0.8.0-1 is accepted into unstable (this usually takes some time, I'm not sure why) - You build opkssh 0.3.0-1 using 0.8.0-1 => fail - opkssh 0.3.0-1 is automatically accepted through NEW because builddeps now is accepted - I upload opkssh 0.4.0-1 Everything except the first step happened within hours. Maybe it actually was slightly different ordering. I could/should have added a 'Breaks: opkssh (<< 0.4.0~)' to the golang-github-openpubkey-openpubkey 0.8.0-1 upload, but that wasn't really clear to me at the time, and no automatic testing could have catched it either as far as I can tell. At this point, I'm not sure if it makes sense to re-upload golang-github-openpubkey-openpubkey with that Breaks, since nobody should ever attempt to build opkssh 0.3.0-1 with golang-github-openpubkey-openpubkey 0.7.3-1 again, right? There is a implicit temporal build dependency ordering in each archive. I'm tagging this bug with that information though. > If this is really a bug in one of the build-depends, please use > reassign and add an affects on src:opkssh, so that this is still > visible in the BTS web page for this package. > > Notes: > > - This is an "always" failure in my setup, not random. > > - Yes, I know that this built ok in the buildd merely 6 hours ago, > but they have additional packages in the chroot and they disable > network access. My theories to explain this would be a) Maybe this package > is trying to access Internet and b) Maybe there are missing build-depends. > > - In either case, weird cases like this one are the reason I always offer > a VM to test in case it's necessary. Maybe you could add 'c) Maybe you uploaded a new version of a build dependency that triggered this failure and forgot to add Breaks' to this list of reasonable explanations. /Simon
signature.asc
Description: PGP signature
