2012/7/28 Philipp Kern <[email protected]>: > 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 remained intact. 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. See https://buildd.debian.org/status/package.php?p=sdl-stretch = No migration to testing for 64 days. See <http://release.debian.org/migration/testing.pl?package=sdl-stretch> 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 [1]. 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. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680275 > 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 sdl-stretch. 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 days/weeks. > 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 thing works. Cheers. -- Manuel A. Fernandez Montecelo <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CAPQ4b8k5yhsNSZC0fJEUNb1XKD5UxbsaxBB3wUtDhz=-nsq...@mail.gmail.com
