Re: Request unblock sdl-stretch/0.3.1-3
2012/7/28 Philipp Kern <firstname.lastname@example.org>:
> On Sat, Jul 28, 2012 at 02:02:47PM +0100, Manuel A. Fernandez Montecelo wrote:
>> These changes that you mention, were introduced the 26th of April for
>> 0.3.1-2, well before the release, without any bug report being
>> submitted since then. This is what it's already authorised to migrate
>> in the unblock.
> As said we don't care. The package was unable to migrate by itself so that
> exception is void.
The package didn't migrate to testing not because of any problem of
the package itself, nor the changes in -2, or while building it or bug
reports, but because of a row in Package-arch-specific set in 2005
that allowed it only to be built for i386. In 2009 and 2011 the
package was updated (incl. 2011, when the arch-restriction in
debian/control was removed), but the restriction in that P-a-s file
So the package wasn't ever built *by buildd daemons* in amd64 arches
(or any other non-386). But since it happens that we uploaders have
amd64 machines, the package was actually provided in binary form for
amd64 in the Debian repositories. It was never part of mips, armel or
any other architecture, not even kfreebsd-amd64 where it's now built:
=== sdl-stretch: (you co-maintain it)
= Missing build(s) on amd64 armel ia64 kfreebsd-i386 mips
This might need manual action from your side.
= No migration to testing for 64 days.
I updated -2 in April also without realising that, and about the
freeze as per the notice above, I realized that this package was not
being migrated to testing (-2 hadn't make it in 3 months) because of
that ancient restriction in Package-arch-specific, etc. Why did -1
migrate but -2 didn't? I really don't know, but it was not due to a
bug report or inherent problem.
While trying to fix that and requesting removal from
Package-arch-specific, I *was asked* to create -3 because a developer
called Philipp Kern set it as a pre-requisite for him to remove the
restriction on packages-arch-architecture . And that's where we
are now, otherwise the package would have already been migrated with
-2, and this unblock would be a non-issue.
> I don't see how those ramblings relate to the two lines I objected to.
> They don't explain them, they just say that "there was no bug report"
> (yet). *Why* does one need to set "-pipe -Wall", *why* --as-needed
> (whose prior absence might cause rdepends to rely on linkage to be
> present), *why* --no-undefined. But then I see now that it hasn't got
> any rdepends at all.
The changes in -2 were mostly harmless, whitespace + debhelper/policy
depends updates + descriptions, and only these extra BUILD options
which didn't cause any problem in buildds, nor any bug reports, same
in Ubuntu (they already have -3 since a few weeks, also no bugs).
The same options are used in other SDL packages (so they are there for
consistency). --no-undefined is present already in the current
version of sdl-mixer1.2 (~17k popcon, 15% of Debian systems) before
the renewed SDL-team took over; and in the testing/unstable version
sdl-ttf2.0, sdl-sound1.2, sdl-net1.2 since 8 months ago. --as-needed
in most SDL modules. "-pipe -Wall" are pet peeves of mine, present in
almost all of the packages that I maintain in Debian.
I am not saying that they *have* to be there, but that now that they
are there, most of them I deem them innocuous and want them to be
there in the future, some of the more dangerous LDFLAGS don't seem to
cause problem (and they are supposed to bring hardening benefits,
which incidentally it's a release goal, even if --no-undefined is not
included), and so I don't want to spend time removing them from
So I'm not keen on the idea of spending more time changing back things
that are IMO mostly inoccuous and will be introduced again ASAP, with
no evidence so far that cause problems here or in Ubuntu, when if
these do indeed cause an option they are already identified and can be
promptly corrected in a new upload *if they really cause harm*. Apart
from that, I've been waiting most of this month for this issue to be
solved, now I am embarked in other tasks.
So I respect your decision as release manager/helper and agree if you
don't want to approve -3 or want to remove sdl-stretch altogether, but
I'm really not planning in going ahead with the changes that you
request. We've all been spending more time on this that this package
really deserves. Maybe some other people in SDL team will, although I
know that at least some of them are on holidays and offline for a few
> Also I do not see how reverting those changes make that package FTBFS
> shortly after stable is released.
Having -1 without changes in -3, and now that the restriction in P-a-s
files is removed, will make that a binary rebuild of the package will
be rebuilt in architectures where it was never built before.
So if somebody triggers a rebuild on testing right now, or in the
future stable if sdl-stretch is not updated, it will probably fail to
build in some of the architectures -- if I understand how the whole
Manuel A. Fernandez Montecelo <email@example.com>