[Debian-med-packaging] Bug#833004: Do you have resources to look after ball? [progress info]

[Steffen Möller]

Hi,

well done!


On 11/11/2016 13:06, Andreas Tille wrote:
> Hi Danny,
>
> thanks again for your help.
>
> On Fri, Nov 11, 2016 at 12:36:49PM +0100, Danny Edel wrote:
>> Control: block 784451 by 832420
>>
>> that is fine with me.  I'll keep the bugs in CC too.
> :-)
>  
>>> We somehow should target to Qt5 anyway (see #784451) better sooner than
>>> later.
>>>  
>> For now, I have backported the fixes to the released, but Qt4-based
>> 1.4.3~beta1 version, to resolve the current FTBFS with a targeted fix.
>> The changes are uploaded to the debian-med/ball repository on alioth,
>> pending your review and upload.
> Build is just running ...  I'll come back later in case of any issues
> I feel unable to deal with myself.
>  
>> In that process, I tried building various stages of upstream master, and
>> bae96ab4 'Merge branch issue_596' might be a candidate for a snapshot
>> (entire testsuite passes).  However, there is the problem that
>> QtWebEngine is not yet included in Debian, so I could only build recent
>> master if I explicitly disabled support with -DUSE_QTWEBENGINE=OFF.  I
>> am not sure if this would be a good thing for users.
> I admit that I have no idea whether this is a real constraint.  I added
> Steffen in CC who might raise his opinion.
In my opinion, the BALL library is the essential part that is nice to
redistribute
in Debian. BALLView would be a nice application working with that and
certainly
I hope for many more BALL applications to come.

The dynamic web engine would of course be nice to eventually surface in our
distro but if we can get BALL without it then this is just fine as it is
no regression
from what we had before.
>> I added a blocking relationship to the ITP of QtWebEngine, I hope I
>> didn't mix up the numbers.  The changelog contains a Closes: clause on
>> both FTBFS issues, even though I could only test amd64.  Feel free to
>> remove those before uploading if that's an issue.
> I will also test on amd64.  If it turns out that there might be some
> issues on other architectures we possibly need to excluded these.
It would be particularly nice we could come up with ways to help BALL
development in some ways. Attracting fantastic folks like Danny is one
thing.
Another be could become the continuous integration work, such that even
while possibly working with other operating distros Upstream could learn
about upcoming difficulties (like with the QtWebEngine) and we would not
be taken by surprise either.

Best,

Steffen