Re: [maemo-developers] Best IDE for maemo development?
On Tue, 2006-02-21 at 13:29 +0100, Eloi Crespillo Itchart wrote: For the people that develops often on maemo, what IDE/set of tools have you found to be essential to this task? Anjuta? Emacs? Kdevelop? Eclipse? devhelp? ... It could be interesting to know which tools have you found to be more suitable for this task. It could also be interesting to know if you use them to develop maemo itself or userspace apps. Encode, of course--the only IDE in the world that has been designed for Maemo development from the ground-up. :) http://encode.sourceforge.net/screenshots.xhtml (It's still beta, tough.) timo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Best IDE for maemo development?
On Tue, 2006-02-21 at 12:26 -0300, Kasper Souren wrote: Looks good. What about a LiveCD containing this thing? LiveCD authors are free to include it, but it's still missing crucial features so I would wait a while. And, is it possible to use Encode for Python development? Of course (I use Encode for developing Encode). It just integrates different tools. timo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] Flasher debs
How about providing Debian packages (i386 and powerpc) of the flasher? It would be in line with the recommendation to use Debian or Ubuntu for development with maemo. Or would the (click-through) license prohibit that (or make it unfeasible)? timo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: Flasher debs
On Thu, Oct 27, 2005 at 03:42:04PM +0300, [EMAIL PROTECTED] wrote: On Thu, 27 Oct 2005, Aleksandr Koltsoff wrote: On Thursday 27 October 2005 10:45, Ferenc Szekely wrote: ext Timo Savola wrote: How about providing Debian packages (i386 and powerpc) of the flasher? yes, it is the license that prohibits us to distribute the tool in a debian repo. we could place the deb packages to the same place, but it does not help much, i guess. How about placing the deb packages somewhere where people download the SDK from? Should probably be a separate directory with a README that would note that the deb is not meant to be installed within SDK env. It would help though. Other possibility is making a separate deb repo for tools that one would find useful when developing on debian, but since flasher is the only tool at the moment, that might be an overkill. ak. I think that Timo wanted a debian repo that could have been put to a sources.list and installed with apt-get. Single debian package that would be downloaded via web page and installed to host with dpkg (after click-through license agreement) is IMHO quite pointles because then it would require one step more to use the flasher. On the other hand if at install phase license agreement would be enough to satisfy legal issues it could be provided by debian repo. Then if user disagrees with the license installing would fail or something. I'm not sure that this would satisfy legal issues but would be doable from technical point of view. Of course using dpkg-deb to package would mean that user can access the binary without accepting the license ;) Actually, I wanted none of those things. I want a Debian package that shows up in the dpkg database (with proper version information) so that I don't have any unaccounted-for files installed on my system. Downloading a file using a browser and installing it with dpkg is as easy than adding a line to sources.list, updating and installing. (I suspect that the flasher isn't going to be updated very often.) (If such a package would be provided, then the name of the executable and the package should be something more Nokia/OSSO/Maemo/770-specific than flasher.) timo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: [maemo-users] Root password?
On Sat, Sep 10, 2005 at 07:11:14PM +0200, Ralf Engels wrote: Fakeroot does not really allow you anything and the normal installer (on the device) is broken in another interesting way. On the emulation fakeroot seems to work quite well though. In Scratchbox? That's because you have write permissions to the target filesystem. :) timo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Re: [maemo-users] Root password?
On Wed, Sep 07, 2005 at 10:38:34AM +0530, Mayank Jain wrote: On 9/7/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Anyone know the default root password for Super User rights? Just doing fakeroot works for me :-) But that's just fakeroot, not actual super user privileges. You can't do anything in fakeroot that you probably want to do if you're looking for the root password. timo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Manual for creating debian packages
On Wed, 2005-08-17 at 13:22 +0300, Kalle Vahlman wrote: 2005/8/17, Timo Steuerwald [EMAIL PROTECTED]: I'm searching for a good manual about building debian packages for maemo. There are a couple of manuals/tutorials for this on the net (for example http://www.debian.org/doc/devel-manuals) Those manuals are as official as it gets, and there shouldn't be anything maemo-specific about building a debian package for it. It's supposed to be a debian system after all. The maemo tutorial[1] says that maemo packages should depend on the maemo package version =1.0 and installed files should go under the /var/lib/install directory. [1] http://maemo.org/platform/docs/tutorials/Maemo_tutorial.html#Creating-Maemo-packages timo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] build system
Gustavo Barbieri wrote: While trying to build it by hand and also create an ebuild (Gentoo), I've found out that many other things are hard coded and the build process is not that usual (ie: doesn't use autotools and stuff like that). There is any reason? Scratchbox is a complex piece of software; it's actually closer to an operating system than an application. There are a few reasons why things are like they are: Scratchbox's host tools (including compilers) are dynamic binaries that need to work in the sandbox where the root filesystem is dominated by the contents of the target filesystem. The host tools are linked so that they find correct host libraries from under /scratchbox instead of trying to link against ARM/whatever libraries found in /lib and /usr/lib. The host tools can also be used outside the sandbox environment, so the library location must be the same in either case for that to work. Being able to use the toolchains from outside is handy, but moving the Scratchbox installation directory to a more suitable place is often more important. I have done some preliminary work for making the installation and login process work even when /scratchbox doesn't exist outside the sandbox; the work should be fairly simple to complete. A bigger problem (from my perspective) is the fact that Scratchbox can only be built directly to its installation directory. The tools fail to configure and/or build when things are not in correct places. I worked on this problem last year, but in the end it seemed next to impossible to fix--I don't remember the specific problems anymore. This problem could also be solved by building most of the tools inside the sandbox (like sb-perl-devkit and sb-toolchains are built), but then we'd also have to build all libraries and tools that are used during the build (i.e. Linux from scratch). Using autotools for building Scratchbox would be a bit pointless because the Scratchbox build procedure is not something automake or autoconf solve. Scratchbox is mostly just a set of upstream packages that already have autotools-based build systems; we just have to build them with correct settings (and patches) in the correct order. We use the GAR system[1] which is specifically designed for this. (GAR is a bit messy because it uses make; I'd one day like to replace it with a scons[2]-based build system...) [1] http://www.lnx-bbc.org/garchitecture.html [2] http://www.scons.org/ We (Lauri Leukkunen, Veli Mankinen and myself) have plans[3] for a complete redesign of Scratchbox which (among other things) solves all of the problems you mentioned. We're hoping to write a more elaborate Scratchbox 2.0 design document in near future. But any help in improving the existing versions is naturally welcome. :) [3] http://scratchbox.org/~tsavola/sb2-outline.txt I'm posting this message to scratchbox-devel so that we can continue the discussion on a more suitable mailing list. timo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Maemo C++
Jaco du Preez wrote: I looked at the Maemo development environment and it looks great. Here is the thing, I would like to write applications in C++ and make use of OOP, templates and a few other features. I would like to make use of libraries such as Sigslot - http://sigslot.sourceforge.net/ ACE - http://ace.sourceforge.net/ Boost - http://www.boost.org/ If you are using the parts of Boost that are implemented completely with templates, Boost is only a build-time dependency and its libraries don't need to exist on the device. (Same of course applies to other template libraries aswell.) If you are using libraries that are not available on the device, you could always link them statically into your application... Is there a way I can develop in C++? Perhaps a C++ compiler that I can use that supports the Nokia 770 architecture and chipset and that is easily used in the Maemo development environment? Scratchbox (the maemo development environment) uses GCC toolchains with C++ language support enabled. I've understood that the 770 ships with the C++ runtime libraries included, and I've succesfully compiled and run C++ applications (which use Boost) on the maemo platform. On the other hand, the C++ bindings for GTK+ are (probably) not included and the Hildon framework doesn't have C++ bindings, but using the native C APIs from C++ code is of course not a problem. timo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Scratchbox rpm scriptlet failure
On Tue, 2005-06-07 at 16:24 -0700, Colin Charles wrote: ./run_me_first.sh Inconsistency detected by ld.so: rtld.c: 1192: dl_main: Assertion `(void *) ph-p_vaddr == _rtld_local._dl_sysinfo_dso' failed! Anyone else seen this? Take a look at these mails: http://lists.scratchbox.org/pipermail/scratchbox-users/2004-August/ timo ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
