I was really expecting this mail :)
First of all, allow me to congratulate you an the rest of the arm64 porters
for it's inclusion in the archive :)
This is a "quick and dirty" mail to let you know that I'm looking at this, but
please give me some time to check this facts. Tip: I'm not currently very
available, so it might take me time, although some of my team mates might show
up too.
On Friday 15 August 2014 23:46:19 Wookey wrote:
[snip]
> OK. So I've brought the atomic queries to the attention of Steve
> Capper, who understands this stuff. He observed that the memory
> barriers are not the right type. They'll work (as they are the 'mos
> expensive' type) but will be slower than is necessary. Hopefully he'll
> find time to have a look at that reasonably soon, but he's a busy man
> at the moment.
To be honest this is not what I remember, IIRC they will not work. But I'll
double check the comments upstream did to the patches.
> In an attempt to solve the -fpermissive thing, I updated the patches
> for the current qt4-x11 package to try and get an example build log
> (without -fpermissive) to wave at people who grokked C++ and
> arm64. This involved some tweaking of the arch/ABI identification
> logic wich was bust and by using dpkg_arch ('arm64') in place of uname
> -m ('aarch64') then checking for arm* later, it incorrectly identified
> the ABI as 'arm' and tried to build wrong assembler. So I've fixed
> that up to not use the hacky mechanism and re-order the checks/extend
> the regeps so both arm64 and aarch64 end up pointing at QTs internel
> 'aarch64', and other arm* names refer to QTs internal 'arm'.
>
> And now it seems that the -fpermissive problem has gone away. The
> package builds without -fpermissive on arm64 (maybe updated compiler,
> maybe updated sources, maybe updated something else - who knows?
\o/ I skimmed trough the patch an indeed it seems sensible. Moreover, it has
high chances of getting upstreamed. Did you do this part of the patch (namely
the part that touches configure)?
You know that I would *love* to get this upstreamed but in order to do so I
need to:
a) in case the patch is really simple or not really copyrighteable I might
push it directly. But it is much much better if at least I can write down who
the original coder was.
b) In the case the patch is copyrighteable (ie, just not a couple of "obvious"
changes) I need to find the original coder and convince him/her to either:
b1) push the patch him/herself to upstream's gerrit instance (preferred
because it allows upstream to make questions or ask for changes directly to
the people who code them).
b2) publicly announce (could be a mail to this very same bug, a gined mail
is a plus) that the patch is licensed with a permissive enough license like
some BSD one. The downside of this approach is that in case upstream finds
something they don't like I need to be a proxy between them.
I would really *love* if you can help me with this, as I don't know exactly
who did what (I might infer some of that data from the previous splitted
patches).
> Anyway I guess we can call it fixed until we see evidence otherwise.
Definitely.
> Attached is current patch (obviously with atomics stuff unchanged)
>
> (The nice neat separated patches did not work for me and I've not had
> time to separate this one out into nice pieces, sorry).
No problem, I'll take care of it.
> Can we upload this so we at least have a working package in the
> archive (which will very soon be needed by our nice new official
> buildds), and refine the atomics patch for upstreaming in due course?
Please allow me to recheck the assertion wrt the atomic stuff. If I'm
remembering right and the atomics did pose some problems then we would have an
instant RC bug. And if this is true and arm64 becomes a release arch we Qt
maintainers have a bug we can't fix ourselves, not to mention we would be
doing a disservice to our users.
Now if the atomics are really not such a big problem count on me with the
patching, but please help me identifying who did which part of them. We really
want this upstreamed.
JFTR, I have already asked upstream about this in <https://codereview.qt-project.org/#/c/81011/>
Kinds regards, Lisandro.
--
12: Es posible insertar imagenes en los documentos y archivos al
trabajar con Word
* No o Si
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html
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.