Bug#685209: unblock: ball/1.4.1+20111206-4
Dear Adam,
On 08/18/2012 01:34 PM, Adam D. Barratt wrote:
> On Sat, 2012-08-18 at 13:17 +0200, Steffen Möller wrote:
>> On 08/18/2012 12:48 PM, Adam D. Barratt wrote:
>>> On Sat, 2012-08-18 at 12:05 +0200, Steffen Moeller wrote:
>>>> The uploader is upstream who kindly added a patch to fix a FTBFS.
> [...]
>>> While I'm happy to believe that a number of the patches are required to
>>> fix building with gcc-4.7, these at least don't look like they are:
>>>
>>> patches/0007-Fixed-the-FPT-version-of-bond-order-assignment.patch | 447 ++++
>>> patches/0008-Added-MAX_PENALTY-option-to-bond-order-assignment.patch | 975 ++++++++++
>>> patches/0009-Fixed-a-bug-in-the-AssignBondOrderProcessor.patch | 271 ++
>>>
>>> Indeed some of those look like they may well introduce ABI changes if
>>> the changes are reflected in libball.
>
> Some comment on this, possibly from upstream, would be helpful. I
> realise that nothing outside of ball uses the libraries, but they (I
> missed libballview) are shipped as public soversioned libraries and
> nothing in the package dependencies appears to ensure that the packages
> are upgraded in step.
>
>>> This obviously isn't a gcc 4.7 fix:
>>>
>>> patches/0011-Fix-compilation-of-Python-bindings-with-new-sip-vers.patch | 25
>>>
>>> It may well be needed for the package to build in unstable now, but it's
>>> certainly not covered by "Fix compilation with g++ >= 4.7".
>>
>> >From the description of those bugs I tend to agree that indeed that is more
>> than the FTBFS required. Upstream mostly works on version 2 of BALL now, so
>> knowing whatever ships with Wheezy now to be worked with for a while, I presume
>> Andreas (upstream) to just have wanted some of the later experiences
>> backported. A respective description in the changelog is missing.
>
> At the very least, yes.
>
>>> Was simply forcing building with gcc 4.6 considered as an option?
>>
>> I did not know myself this was allowed for anything in stable. The bond-order
>> changes were apparently important. With my Debian Med hat on, I am always
>> eager to have such close ties with upstream so Debian gets the best that is
>> possible, not only something that compiles.
>
> In general, I'd agree. The focus on changes during a freeze is somewhat
> narrower, however.
>
>> I understand that you see difficulties to accept the package for Wheezy
>> as it is. Would it help you to have the debian/changelog updated with the
>> maintainer change and a description about those changes to the bond order?
>
> A description of those patches would certainly help. As would an
> explanation as to why they're so important that they either meet the
> published freeze guidelines or merit an exception.
If you were the ftpmasters then I would now have suggested to reject the
upload for Andreas to upload a corrected version. Actually I had already
formulated that sentence when I realised that the package already is in
unstable :o/
@Andreas: Since everything is already uploaded and went through the
buildds and was shipped to all the mirrors and your pending explanations
now are mostly for the release team to decide, please first formulate
an email to Adam outlining your reasoning on those non gcc
4.7-associated changes. Trusting you in your initial reasoning
I have some remaining hope for the package to be acceptable nonetheless,
at least we/you will learn if the bond-bits can remain in or if you rather
have the version currently in testing removed because of those bond issues
you now know about.
Many thanks to Adam for his constructive review and regards to all
Steffen
Reply to: