Packages-arch-specific blocking of a single binary blocks the entire source package

[Max Bowsher]

It looks as if when Packages-arch-specific declares a single binary package as arch-specific, that limitation is erroneously applied to the entire source package.

Example: https://launchpad.net/ubuntu/+source/zblast/1.3-2.3ubuntu1 was built only on i386. zblast-svgalib is a P-a-s-ed binary, but zblast-x11 is arch:any and is not P-a-s-ed, so should have been built on all architectures.

[Celso Providelo (cprov)]

Hi Max,

Thanks for reporting this issue, but that's more like a feature than a bug. Blocking a single binary (or any of them for this matter) in P-a-s has the same effect than blocking the source.

I don't think I agree with your statement claiming that the restriction is erroneously applied to the the whole set of produced binaries, it's more like a debian-format limitation.

However I acknowledge the problem, and the only possible solution I can think is to fix the source (so we can get rid of the Pas entry) or to split it in two.

[Max Bowsher (maxb)]

I don't understand why this would be considered a feature? Let me try to explain the behaviour I expect to see more clearly, and you can say which specific part you disagree with:

There is a source package, zblast, with three binary packages:
 * zblast-data, Architecture: all
 * zblast-svgalib, Architecture: i386
 * zblast-x11, Architecture: any

When built on, for example, amd64, the build is successful and just produces only the zblast-data and zblast-x11 binaries.

There is a P-a-s entry for zblast-svgalib, the purpose of which it to notify the archive maintenance software that it is expected that it be omitted on non-i386 architectures. The P-a-s entry is *not* intended to prevent the package building at all on other architectures - if it were, it would be written as %zblast in the P-a-s file.

This appears to be a Soyuz-specific misinterpretation of what P-a-s is intended to mean, as far as I can see. http://packages.debian.org/search?keywords=zblast-x11 shows that the Debian buildds have built zblast-x11 on all arches.

[Celso Providelo (cprov)]

I see what you mean, thanks for providing more information.

The scenario indicates that the binary P-a-s line for zblast-svgalib is doing, literally, nothing in Debian. The zblast source rules implements its very own architecture-dependent mechanisms to control what gets built in which architecture (kind of insane, but who am I to say, right ?!).

It's very likely there is a misinterpretation on the Soyuz side, indeed. We can discuss a solution with Ubuntu archive-admins when they come back in January.

[Scott Kitterman (kitterman)]

This could also explain the disappearance of kde4bindings builds on hppa for recent uploads. If so, the build history for that package could give you a date range for when this problem was introduced.

[Max Bowsher (maxb)]

The binary P-a-s line for zblast-svgalib does have a purpose in Debian. Without it, quinn-diff on a non-i386 architecture would report the source package as being "partial", and resubmit it to wanna-build.

[Celso Providelo (cprov)]

Scott,

You are right, good catch. the .NET/Mono stuff (libqyoto-dev and qyoto-dev-tools) are blacklisted for hppa.

Max,

That's subtle, thanks for the information. Let's see how we can glue those pieces properly in soyuz.

[Adam Conrad (adconrad)]

Cut-n-paste of IRC, because I'm lazy:

14:31 < infinity> cprov-out: binary P-a-s lines are a description for quinn-diff, not for buildds.
14:31 < infinity> cprov-out: Okay, you know how a .dsc file lists "Binaries: foo bar baz quux"?
14:32 < infinity> cprov-out: If we build "foo bar baz" on all arches, but only build "quux" on a few arches, then quinn-diff would consider those arches "incomplete" and keep requeuing them for builds in wanna-build. P-a-s binary lines prevent that loop.
14:32 < cprov-out> infinity: debian/control
14:33 < infinity> cprov-out: For the purpose of what soyuz does (just creating build records), we only care about %source entries (and, like I said, single-binary packages, where %source == binary, due to some laziness in the past maintenance of the file)
14:33 < cprov-out> infinity: right, the quinn-diff relationship I got from Scott's comment, but for Soyuz it seems irrelevant
14:33 < infinity> cprov-out: Yes, for soyuz, binary lines are irelevant. The fact that we're parsing them to determine build queues is wrong.
14:33 < cprov-out> infinity: uhm, you're saying that we can ignore binary-lines
14:34 < infinity> cprov-out: We can ignore all binary lines, except binary lines for single-binary packages.
14:34 < infinity> Say that the "hello" source produces only the "hello" binary, and no others. In that case, "hello: hppa" and "%hello: hppa" are the same entry.
14:34 < cprov-out> that makes sense ... interesting mis-implementation ;)
14:35 < infinity> But in all other cases, binary lines are ONLY there as a post-upload processor, not to determine build-time behaviour.
14:35 < cprov-out> infinity: roger.
14:36 < infinity> The binary = %source thing for single-binary packages isn't so much a misimplementation as it is a lenient implementation to allow for people occasionally breaking the file's syntax when they meant to add %source entries. :)
14:36 < cprov-out> infinity: can you register this endorsement as bug comment (then I will remember to not bother you again later)
14:36 < infinity> It takes a bit more processing to do that bit, but I assume we have all that info handy anyway, so it's not tough.
14:37 < cprov-out> infinity: no, it will be trivial to validate binary lines only for single-binar sources.

[Max Bowsher (maxb)]

"single-binary" is possibly special-casing only the most common possibility? Perhaps the algorithm should actually be: If _all_ the binaries produced by a source package are masked by P-a-s (either explicitly or by %sourcepkg) then don't build it

[Scott Kitterman (kitterman)]

Before we optimize, can we at least get back to where we were before and
get Soyuz building packages that should be built.

[Scott Kitterman (kitterman)]

I'm not sure what else this is blocking, but it's currently blocking virtually all of KDE on hppa for Jaunty.

[Max Bowsher (maxb)]

Any thoughts on whether this can be made to happen soon?

Time is running out in the Jaunty cycle.

[Celso Providelo (cprov)]

RF 7959

[Max Bowsher (maxb)]

Celso: Brilliant!

Is there some way you can magic up the missing "needs build" build records for jaunty, or are no-change uploads the way to go?

[Celso Providelo (cprov)]

Max,

I will run queue-builder for jaunty, it should create the missing build. I will let you know when it's done.