Bug#784451: Do you have resources to look after ball? [progress info]
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
Bug#784451: Do you have resources to look after ball? [progress info]
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. > 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. Thanks a lot Andreas. -- http://fam-tille.de
Bug#784451: Do you have resources to look after ball? [progress info]
Control: block 784451 by 832420 On 11/10/2016 09:13 PM, Andreas Tille wrote: > I take the freedom to turn this discussion into a public one > and CC the relevant bugs to leave a record there that something is > happening. Hello Andreas, that is fine with me. I'll keep the bugs in CC too. > Hmmm, may be we should base the packaging on a later upstream commit? > >> Among >> other things, upstream also migrated from Qt4 to Qt5, and incorporated a >> few fixes for recent boost. > > 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. 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 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. Cheers, Danny
Bug#784451: Do you have resources to look after ball? [progress info]
Hi Danny, thanks a lot for your quick response to analyse the problems in the ball package. I take the freedom to turn this discussion into a public one and CC the relevant bugs to leave a record there that something is happening. On Thu, Nov 10, 2016 at 03:26:30PM +0100, Danny Edel wrote: > On 11/09/2016 03:39 PM, Andreas Tille wrote: > > Sure you can't give a time line. I think when we start our Advent bug > > squashing party we need to tackle it somehow - but having this sorted > > out before to enable some testing would be great. > > I have had some time to look into this, there are three failures, and > all are perfectly reproducible. Investigating (with core dumps) revealed: > > 1. PoseClustering_Test depends on verbatim boost::serialisation output, > which changes with every library version update. Upstream has already > fixed this by ignoring the actual file contents, and instead feeding the > file to the de-serializer and check if the resulting object compares equal. Sounds good. > 2. DefaultProcessors_test segfaults after trying to use an optimized-out > variable. This looks like a legitimate upstream bug to me. > > 3. XDRPersistenceManager_test segfaults after following a null pointer. > Also looks like an upstream bug. > > While backporting the fix for (1) is straightforward, the code paths > responsible for (2) and (3) have seen quite some activity in the > meantime, with the relevant commits changing lots of other files. Hmmm, may be we should base the packaging on a later upstream commit? > Among > other things, upstream also migrated from Qt4 to Qt5, and incorporated a > few fixes for recent boost. We somehow should target to Qt5 anyway (see #784451) better sooner than later. > I tried building upstream master to see if it still contained the bugs. > It did not, however one other test fails > (AssignBondOrderProcessor_Test), which is related to upstream issue 576. > > I will try to isolate and backport fixes for the three issues, and > report back afterwards. Again thanks a lot for your contribution Andreas. -- http://fam-tille.de
