[Tinkerphones] [Gta04-owner] QtMoko2 again...

Josua Mayer josua.mayer97 at gmail.com
Thu Oct 26 12:40:21 CEST 2017

Hi Jonas, Nikolaus,

Am 26.10.2017 um 11:11 schrieb Jonas Smedegaard:
> Quoting H. Nikolaus Schaller (2017-10-26 07:05:10)
>>> Am 25.10.2017 um 19:32 schrieb Jonas Smedegaard <jonas at jones.dk>:
>>> Quoting H. Nikolaus Schaller (2017-10-25 17:44:50)
>>>> Back to the original problem: I had not expected that there is a 
>>>> need for a configure-make-install. Since we are fully Debian.
>>> How do you mean configure-build-install isn't needed? QtMoko is 
>>> compiled code, so will need to be compiled.
>> Indeed.
>> But you shouldn't have to to type configure & make to start the 
>> dpkg-buildpackage wrapped by a makefile.
>> The dpkg-buildpackage of course must do a configure & make for the 
>> source tree, but hide that from the user.
>> IMHO, something is done here upside down.
>> My initial mistake was to assume that I can directly call 
>> dpkg-buildpackage after unpacking the source tree. It turned out that 
>> this does not work. At least not without modifications.
> If you expect source to be a Debian source package¹ then I agree it must 
> be be buildable by a) simply unpacking it (dpkg-source -x *.dsc), b) cd 
> into root of unpacked source tree, and c) build it (dpkg-buildpackage).
> But a large project involving embedded (likely multiple interlinked) 
> libraries cannot sensibly² be organized as a single(!) Debian source 
> package - each library should be a separate source package, built and 
> tested and packaged and versioned on its own.
> I thought that your labeling it "upside down" meant that you think it 
> should be adjusted to be able to compile with a single dpkg-buildpackage 
> call.  I disagree with that: I believe that the sensible way to turn 
> such a set of essentially multiple sources is to unentangle those into 
> multiple Debian source packages and build each of those separately.
> If untentangling into multiple Debian source packages was also what you 
> talk about I do believe that untentangling into multiple Debian source 
> packages is what Joshua intend to (eventually, when better understood) 
> reach at.  If that is also what you are talking about above, then I 
> simply suggest to not label it as "upside down" which can be 
> misunderstood as the _build_ routines_ need fixing when really it is 
> more fundamentally the _source organization_ which need fixing (too).
> A more descriptive labeling would in my opinion be "a big mess".
> ¹ Source format "1.0" is upstream tarball + Debian diff + dsc file, and 
> source format "3.0 (quilt)" is upstream tarball + Debian tarball + dsc 
> file.
> ² Indeed, Chromium is *not* a sensibly organized source package!
>>>> It should even be possible to use apt-source -b - if we have proper 
>>>> source packages. So it looks as if the build architecture of QtMoko 
>>>> is upside down...
>>>> Maybe it is historical since this is still Squeeze and Wheezy code 
>>>> and multiarch wasn't complete back then. On Jessie or Stretch I 
>>>> think it could be much simpler if the debian/rules are updated.
>>> I believe the reason QtMoko build routines fit badly with Debian 
>>> style of packaging is that it does not use existing shared Qt 
>>> libraries but instead embeds its own fork of Qt optimized for 
>>> embedded devices: https://en.wikipedia.org/wiki/Qt_Extended
>> It could be a renowned Debian citizen if it would not embed it but 
>> just package and provide the special QtE libraries and then just use 
>> the -dev version for dpkg-building the launcher, dialer, etc. This is 
>> what Josua is working on:
>> http://git.goldelico.com/?p=qtmoko2-qte.git;a=summary
> I guess that this:
>    "if it would not embed it"
> expands to this:
>    "if QtMoko project would not embed QtE libraries"
> and then we agree - except for the word "just": Joshua reports that 
> there are trouble unentangling them because their interdependency seems 
> to form a circular graph.
Not really. The configure script of qtmoko sets up a ton of qmake
projects, *one* of them being a build of Qt itself. The only thing
special about that Qt appears to be that it is built to use the
framebuffer directly for drawing.
In the past I have tried to build and package Qt standalone, and have
the qtmoko configure script find that existing qt. However there was
always some weird error message in a deeply hidden piece of either
configure(written in perl), qmake.pro, or more weird files referenced by
It is those build preparation files that also include a recursive call
of configure to itself with different arguments. I guess this is the
circular thing you remember.

Otherwise qtmoko should be a component based project, producing a bunch
of shared libraries, the qtmoko application, and a bunch of additional
I expect these to be organizable as individual qmake projects
referencing each others as dependencies, and called by a central qmake
subdirs project.
>  - Jonas

More information about the Community mailing list