Hi Helmut! El miércoles, 26 de julio de 2023 01:44:17 -03 Helmut Grohne escribió: > Hi Lisandro, > > On Tue, Jul 25, 2023 at 09:23:14PM -0300, Lisandro Damian Nicanor Perez Meyer wrote: > > As discussed on IRC I am hacking around this in qt6-virtualkeyboard > > 6.4.2+dfsg-3 so parallel is at least 2. I personally do not think this is an > > RC bug, but at least we have a way to avoid the FTBFS for the time being. > > Let me clarify my view on this. I see a failure to build from source > when passing parallel=1 as an RC bug. To me RC means "not fit for releasing", including "does not build in our infra". The fact that using parallel >1 makes it work (we have a workaround) and that our infra does not suffers from this bug means, in my point of view, that it is not RC. The final result when built in our infra is still a perfectly usable piece of software. > However, I do not see a failure to > honour the requested parallelity as an important bug. When I request > parallel=1 and your package successfully performs a parallel build, > that's not an important bug in my view. There are a number of packages > in the archive doing this. As long as your workaround does not cause > random FTBFS (e.g. on slower buildds), I think it adequately addresses > the issue I raised and I'm happy with you closing the bug. > > Leaving that aside, an unexplained segfault during build is probably > worth investigation (though not an RC bug either). > > Is this something you can agree to? Well, a segfault that only happens on certain conditions that are hard to replicate (I could not debug it, it only happened for me on sbuild) and come from parallelism _are_ important, but complicated to debug. Now at the same time I tried a 6.5.1 build with parallel=1 on sbuild (one I have for private purposes) and the build worked for me. So this seems to be an upstream bug that it is probably fixed by upstream already. At this point I prefer to simply use my scarce free time to try and package a newer Qt rather than trying to dig more into this issue. So, I think that, for the time being, keeping the severity in important + checking that parallel >= 2 is a good compromise solution. Now if we can replicate this in Qt >= 6.5.x then something else is going on and requires further checking.
Attachment:
signature.asc
Description: This is a digitally signed message part.