+++ Lisandro Damián Nicanor Pérez Meyer [2014-08-15 22:05 -0300]:
> 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 :)
Cheers. We're making good progress there.
> 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.
Cheers. I am at bootstrap sprint for next 4 days. Then debconf 3 days after
that.
> 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.
OK. Steve was planning to comment there too.
> > 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)?
Yes. I hereby licence my (minor changes to existing work) under BSD or expat.
> 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.
I just adjusted the existing configure stuff so it was right. I
removed 3 lines, swapped position of 4 lines and changed a regexp. I
don't think that's copyrightable, and you already have suitable
licence on the previous patch.
> 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).
I just took the previous patch and made above changes.
> > 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.
I hope I've provided enough info for that above. Bug me more if not.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140816012341.gd19...@stoneboat.aleph1.co.uk
