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

2017-10-26 Thread Jonas Smedegaard 
Quoting H. Nikolaus Schaller (2017-10-26 07:05:10)
>> Am 25.10.2017 um 19:32 schrieb Jonas Smedegaard :
>> 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.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

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

2017-10-25 Thread H. Nikolaus Schaller 
Hi Jonas,

> Am 25.10.2017 um 19:32 schrieb Jonas Smedegaard :
> 
> 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.

> 
> 
>> 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

> 
> ...but I am a bit puzzled here: I seem to recall you reminding me of 
> that (after Debian developer Paul Wise initially explained it to me, and 
> helped me install QtMoko on one of my GTA02 devices - which I didn't use 
> much because I wanted a *Debian* environment not a "bastard" like that).

Me too :)

BR,
Nikolaus

___
Community mailing list
Community@tinkerphones.org
http://lists.goldelico.com/mailman/listinfo.cgi/community
http://www.tinkerphones.org

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

2017-10-12 Thread H. Nikolaus Schaller 

> Am 09.10.2017 um 08:22 schrieb H. Nikolaus Schaller :
> 
> Hi,
> 
>> Am 08.10.2017 um 22:17 schrieb Andreas Kemnade :
>> 
>> On Thu, 5 Oct 2017 17:53:17 +0200
>> "H. Nikolaus Schaller"  wrote:
>> 
>>> Hi,
>>> I have started to pick up the build process for QtMoko2 [1].
>>> 
>>> I now run a Debian (Wheezy) inside VirtualBox (i386).
>>> 
>>> The command is simply ./mdeb-qtmoko -vb
>>> 
>>> After approx. 8 hours (with heavy use of ccache), compile fails
>>> with these two lines (amongst 104 MB log):
>>> 
>>> dpkg-shlibdeps: error: couldn't find library libamr.so.1 needed by 
>>> debian/qtmoko-neo/opt/qtmoko/plugins/codecs/libamrrecordplugin.so (ELF 
>>> format: 'elf32-i386'; RPATH: '')
>>> dpkg-shlibdeps: error: couldn't find library libtimidity.so.1 needed by 
>>> debian/qtmoko-neo/opt/qtmoko/plugins/codecs/libtimidityplugin.so (ELF 
>>> format: 'elf32-i386'; RPATH: '')
>>> 
>>> Well, it is easy to understand why the linker can't continue here...
>>> 
>> Hmm, it is the final step before packaging... *not* the linker linking
>> together binaries, so building seems not to fail, just putting it
>> into a package.
> 
> Ah, I start to understand... There seems to be some build rule which
> says which packages depend on what components and dpkg-shlibdeps
> tries to check. But does not find libamr and libtimidity. So that
> it thinks dynamical linking after installation at runtime would fail.
> 
> Hm. Are rules to pack libamr.so.1 and libtimidity.so.1 missing?
> 
>> 
>> That means, you could create a tarball of the result and play around
>> with it (and start to fix the interesting problems like sysfs paths,
>> etc).
> 
> How would I restart the dpkg-shlibdeps on such a tarball to see if my
> changes have any effect?
> 
> The full log from these error: up to failure of make is:
> 
> dpkg-shlibdeps: error: couldn't find library libamr.so.1 needed by 
> debian/qtmoko-neo/opt/qtmoko/plugins/codecs/libamrrecordplugin.so (ELF 
> format: 'elf32-i386'; RPATH: '')
> dpkg-shlibdeps: error: couldn't find library libtimidity.so.1 needed by 
> debian/qtmoko-neo/opt/qtmoko/plugins/codecs/libtimidityplugin.so (ELF format: 
> 'elf32-i386'; RPATH: '')
> dpkg-shlibdeps: warning: package could avoid a useless dependency if 
> debian/qtmoko-neo/opt/qtmoko/lib/libQtWebKit.so.4 
> debian/qtmoko-neo/opt/qtmoko/qt_plugins/phonon_backend/libphonon_gstreamer.so 
> were not linked against libxml2.so.2 (they use none of the library's symbols)
> dpkg-shlibdeps: warning: package could avoid a useless dependency if 
> debian/qtmoko-neo/opt/qtmoko/lib/libQtWebKit.so.4 was not linked against 
> libgio-2.0.so.0 (it uses none of the library's symbols)
> dpkg-shlibdeps: warning: package could avoid a useless dependency if 
> debian/qtmoko-neo/opt/qtmoko/plugins/network/libbluetooth.so 
> debian/qtmoko-neo/opt/qtmoko/plugins/mediaengines/libcruxus.so 
> debian/qtmoko-neo/opt/qtmoko/lib/libqtopiaprinting.so.4 
> debian/qtmoko-neo/opt/qtmoko/plugins/inputmethods/libsvgkeyboard.so 
> debian/qtmoko-neo/opt/qtmoko/bin/qui 
> debian/qtmoko-neo/opt/qtmoko/plugins/viewers/libgenericviewer.so 
> debian/qtmoko-neo/opt/qtmoko/plugins/application/libphonenetworks.so 
> debian/qtmoko-neo/opt/qtmoko/bin/messageserver 
> debian/qtmoko-neo/opt/qtmoko/plugins/application/libprofileedit.so 
> debian/qtmoko-neo/opt/qtmoko/bin/gta02-gps 
> debian/qtmoko-neo/opt/qtmoko/plugins/application/libminesweep.so 
> debian/qtmoko-neo/opt/qtmoko/lib/libqdsync_common.so.1 
> debian/qtmoko-neo/opt/qtmoko/lib/libmd5.so.1 
> debian/qtmoko-neo/opt/qtmoko/plugins/application/librotation.so 
> debian/qtmoko-neo/opt/qtmoko/lib/libqtopiaaudio.so.4 
> debian/qtmoko-neo/opt/qtmoko/plugins/application/libdatebook.so 
> debian/qtmoko-neo/opt/qtmoko/qt_plugins/iconengines/libqtopiapiciconengine.so 
> debian/qtmoko-neo/opt/qtmoko/plugins/application/liblogging.so 
> debian/qtmoko-neo/opt/qtmoko/plugins/application/libbtsettings.so 
> debian/qtmoko-neo/opt/qtmoko/plugins/themeitems/libdialerlineedit.so 
> debian/qtmoko-neo/opt/qtmoko/plugins/application/libmindbreaker.so 
> debian/qtmoko-neo/opt/qtmoko/lib/libqtopiatheming.so.4 
> debian/qtmoko-neo/opt/qtmoko/plugins/application/libfifteen.so 
> debian/qtmoko-neo/opt/qtmoko/bin/phonesim 
> debian/qtmoko-neo/opt/qtmoko/plugins/viewers/libsmilviewer.so 
> debian/qtmoko-neo/opt/qtmoko/plugins/videooutput/libdirectpaintervideooutput.so
>  debian/qtmoko-neo/opt/qtmoko/plugins/application/liblight-and-power.so 
> debian/qtmoko-neo/opt/qtmoko/plugins/application/libstartupflags.so 
> debian/qtmoko-neo/opt/qtmoko/lib/libspygrind.so.1 
> debian/qtmoko-neo/opt/qtmoko/bin/NeronGPS 
> debian/qtmoko-neo/opt/qtmoko/bin/sysmessages 
> debian/qtmoko-neo/opt/qtmoko/lib/libqtopiavideo.so.1 
> debian/qtmoko-neo/opt/qtmoko/qt_plugins/qmltooling/libqmldbg_inspector.so 
> debian/qtmoko-neo/opt/qtmoko/bin/qtmaze 
> debian/qtmoko-neo/opt/qtmoko/qt_plugins/iconengines/libqtopiaiconengine.so 
>