[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#749743: qt4-x11: use ppc64el in no_pch_architectures to fix FTBFS on ppc64el



Copying ppc64el porters to see if we can speed up this and be able to push qt4 
with ppc64el on saturday (hopefully).

On Sunday 15 June 2014 23:14:37 Lisandro Damián Nicanor Pérez Meyer wrote:
> On Thursday 29 May 2014 20:26:53 Brahadambal Srinivasan wrote:
> [snip]
> 
> > Dear Maintainer,
> > 
> > While trying to build qt4-x11 on ppc64el, it failed, as it
> > required 'ppc64el' to be added to the no_pch_architectures
> > list
> 
> No problem with this one, I have already added it to the list.

And it has been there since a couple of uploads.

> > and also needed changes in the configure script.
> > Please consider the patches here, to correct the build issues.
> 
> Now I do have some concerns here. That seems to be changing more things that
> just ppc64el stuff.
> 
> I guess you need to change *86_64 to *64* because ppc is definitely no x86
> :) But I really doubt this is the correct way to do it.

And this is why I'm CCing porters. I currently do not have much spare time to 
get into a porterbox myself, and I will do my best to push a qt4-x11 upload on 
saturday to add (at least) arm64 support. If someone can get to test this 
before that I might be able to add ppc64el as well.

We have three issues here:

- In the patch [0] *86_64 has been changed to *64 in two lines (in the 
middle). I'm really skeptic that this is a good change (if needed at all). And 
I need to convince upstream too. Is this really necessary? In case it is, is 
there a more precise approach? Like, for example, leaving *86_64 and adding a 
new rule for whatever fits ppc64el.

- The second issue is: who did this patch? It is not mentioned in the bug and 
I need that info to properly add a patch for whatever reason.

- The first change in the mentioned patch uses ppc64le and not ppc64el, is 
that right?

Now, about upstreaming the patch: Qt has a CLA in which you *don't* loose your 
copyright but just give permission to Digia to use it in it's commercial 
product (the code remains FLOSS!). I have two ways of pushing this upstream:

- Find the original coder and beg him to push it to upstream's gerrit instance 
(preferred)

- Find the original coder and beg him to publicly state (on a mailing list, 
for example) that this patch is licensed under a BSD license, which is less 
restrictive. 

We don't want to have deltas, so I *really* need your help here.

Note: in this *particular* case I might solve this issue by the fact that this 
change really doesn't seems copyrighteable because it's just using already 
defined stuff, but if we have either of the above situations things get much 
much easier.

[0] <https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=add_ppc64le_support.patch;att=2;bug=749743>

Kinds regards, Lisandro.


-- 
El futuro es WIN95.... A no ser que hagamos algo a tiempo.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: