Hi Andi. Thanks for the reply. As you saw, there's some cleanup stuff mixed in with the actual foreign-arch build-dep stuff. I did a rebase so that these aren't interleaved anymore, and the cleanup can be evaluated somewhat independently. The build-dep stuff does depend on the cleanup, however.
The new tree lives in a branch: http://anonscm.debian.org/cgit/users/dkogan-guest/wanna-build.git/log/?h=770925_foreign_arch_bd Same code as before, with a small, uninteresting bug fix: --- b/bin/wanna-build +++ a/bin/wanna-build @@ -1920,1 +1920,1 @@ - my @arch_foreign = grep { !/^(?:native|all|any|$arch_native)/ } keys %qualified_arches; + my @arch_foreign = grep { !/^(?:native|all|any|$arch_native)$/ } keys %qualified_arches; The tree now looks like this: * 800aaee..: more correct handling of dose exit codes, as defined in the latest dose3 * 4428317..: dose-builddebcheck now has Packages for native and ALL foreign arches * 62fe41c..: I now pass --deb-foreign-archs to dose-builddebcheck as needed * e041d64..: I now call dose-builddebcheck with IPC::Run * b857c74..: some small syntactic corrections Cleanup is the first two: b857c74 and e041d64. The other 3 are functional changes. Particularly, the last commit (800aaee) isn't cleanup as you labelled it previously: it changes the way dose-builddebcheck result codes are interpreted. Andreas Barth <a...@ayous.org> writes: > 55f2b48a6d58dfb306a71ac4b588833d129563ca > This breaks semantics of merge-v3 with only two sets of package files. > I need to think a bit more if there are other semantic changes (and if > so if we want them or not). I'm not sure what you mean here. If you need something changed once you think about it more, please tell me. > f3221db8f5ec5b063d87b7ef25f45f224821fc71 > First hunk, I would prefer if it would be written so it could be run > on an oldstable machine as well (see the one for vercmp two lines > below), perhaps with a reduced function set. On oldstable (wheezy) the dose-builddebcheck is too old to support the foreign-arch stuff. If you want something reasonable to happen with wheezy too, should we simply not even try to satisfy foreign-arch build-deps there? If so, then we don't need deps_iterate. Let me know and I'll put in the appropriate logic -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
