On Wednesday, September 04, 2013 11:34:55 Scott Kitterman wrote:
> Dmitrijs Ledkovs <firstname.lastname@example.org> wrote:
> >On 4 September 2013 12:09, Scott Kitterman <email@example.com>
> >> Dmitrijs Ledkovs <firstname.lastname@example.org> wrote:
> >> Changes like this should really be coordinated in Debian so we don't
> >accumulate long term differences that can't easily be resolved.
> >Yeah, and as far as I know Timo is doing excellent work at keeping
> >packaging in sync as much as possible.
> >But e.g. w.r.t. multiarch & cross-compilation overall at the moment
> >Debian is still far behind Ubuntu, despite myself and many others
> >pushing many mutli-arch changes back to debian.
> He is. For changes that can't be pushed to Debian now (I guess such as
> this), there should still be up front coordination on the approach so
> Ubuntu doesn't head off in one direction and discover later that it's
> unacceptable in Debian and then Ubuntu is stuck with a permanent diff or a
> lot of rework.
> If such coordination has been done, I haven't seen it on what I would
> imagine to be the relevant lists.
> >> Why do you need to cross compile QML anyway? It's not like you need
> >it for bootstrapping.
> >This is not to cross compile QML itself. This is for 3rd party
> >developers to cross-compile their compiled qml extensions against
> >ubuntu's armhf qt to be included as part of their applications for
> >Ubuntu Touch.
> >Or e.g. to cross-compile ubuntu-touch-settings or other packages we
> >have in the archive that have qml extensions.
> >Going via this route though (make qmake support cross-compilation with
> >a debian specific toolchain file), will eventually make possible to
> >cross-compile qt itself and also be upstream able patches for qmake.
> It sounds at least vaguely reasonable. My main concern is that the
> coordination is done.
OK, so I checked. No, no coordination had been done and the response I got
was that this should be accommodated upstream rather than in the packaging. I
think that's reasonable. Before this is done in Ubuntu, there should be some
discussion with upstream about a long term plan for supporting this use case.
I know an upstream fix won't be available for saucy and likely not even for
"T", but the path to an upstream resolution should be started before we start
on a divergence like this.
ubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel