RE: sbox2 & maemo
> > Lauri, I can see you've been away for too long and missed > > some of the action ;-) > > That's probably true, but I'm not afraid to raise old issues that may > or may not have been 100% addressed. Worst thing that can happen is > that things are actually not as bad as I thought. I'm just one voice > here, I think there are enough yes-men to go around so it doesn't hurt > if I object even when there was no need ;) Your voice is welcome. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
A question to status bar plugin in hildon-desktop
Hi , Frrom my experience on hildon, gtk_status_icon_*** function and event process for status icon works pretty well on hildon-desktop. I didn't see any special thing what status bar plugin brings. It's just my thinking. Some guys here might have something I didn't know. Please let me know. Thank, Peter ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 & maemo
On 7/26/07, Carlos Guerreiro <[EMAIL PROTECTED]> wrote: > ext Lauri Leukkunen wrote: > > Nokia and Maemo community really need to figure out an easy way for > > developers to use the real hardware and system-mode qemu. Those are the > > only adequate solutions for testing and debugging of software. > > > No doubt system emulation would be a good thing but I wouldn't > go as far as saying that it's the only adequate solution. > For application development you can do a lot with the current > system as you can see in this list and the application catalog. This just proves that humans can adapt to anything, and even learn to like it. Personally I find the round-trip of compiling, copying to target hw and debugging to be slow and requiring manual setup work. As long as I stick to kernel and initfs I'm fine, I find it a little amusing that we have better debugging facilities for kernel than for applications on the target hw. > > components should be pushed to debian and ubuntu and get those bigger > > communities involved in their development. One day we will anyway be > > > Indeed. When it comes to Hildon that is certainly starting to happen now. This should be the default mode for most of the stuff we do. Arguing that we need to keep something in-house for "competitive advantage" is bollocks. Nokia has a few completely proprietary software platforms already. No need create another one. Anyway almost all of the proprietary components in maemo are of dubious quality, maybe there's a reason for that... > > running debian/stable with a few custom components on the tablets. > > That was the aim with this whole debian thing in the first place, remember? > > > Well, a few custom components is a big understatement ;-) > But yes, building on Debian was the thinking. As you know better > than me we started like that with a snapshot of debian/unstable > and somehow we never really got serious enough about keeping up > with that plan. I hope we can get back to it. Somehow spending a year away from OSSO made me believe firmly that the only way this Maemo thing can be valuable in the long run is by being true to its roots. Every single semi-proprietary component is at least an order of magnitude more expensive to maintain and they force ridiculous software architecture decisions. /lauri ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
WLAN power saving
Is there any way to completely disable WLAN power saving on the N800? While for most use cases the aggressive power saving is welcome, for some power-user applications (SSH, synergy) this is unwanted. If there is no way, I would appreciate it if the maintainer or contact or whoever is responsible for the closed-source driver could add a knob for this. Ideally it could be automatically activated when the power is plugged in, but I would be happy with the manual knob. I realize USB networking doesn't have these problems, but WLAN networking is much easier to use and better integrated into the software. -- Andrew Barr We matter more than pounds and pence, your economic theory makes no sense... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 & maemo
On 7/26/07, Carlos Guerreiro <[EMAIL PROTECTED]> wrote: > > > As long as Nokia works in the current, essentially forked, mode, > > nothing will happen. Nokia needs to look at the way it interacts with > > upstream projects and change. Sure it can be painful, but hiding > > behind a smoke-screen of "product program priorities" is just not > > helping to solve the real issues. > > > > > Lauri, I can see you've been away for too long and missed > some of the action ;-) That's probably true, but I'm not afraid to raise old issues that may or may not have been 100% addressed. Worst thing that can happen is that things are actually not as bad as I thought. I'm just one voice here, I think there are enough yes-men to go around so it doesn't hurt if I object even when there was no need ;) > >>> One day we will anyway be > >>> running debian/stable with a few custom components on the tablets. > >>> > >> You mean switching back to OABI? > >> > > > > Not really =) > > This needs the current armel port to mature and be accepted to debian. > > Nokia pushing it and putting resources into it would seriously help, I > > think. So far Nokia has done next to nothing right in the distro > > > Fair enough. For the sake of presenting an argument I may push things a bit too far, but I believe that the Original Idea(TM) behind the debian choice was distorted by the product requirements and it needs to be raised again now that things have evolved. We shouldn't be afraid to throw away a lot of our custom stuff and development processes if it turns out to be slowing us down. Corporations are notoriously bad with this, we are no exception. > > maintenance area. If SB1 somehow contributed to this state of affairs > > I'm really sorry > > about it, SB2 is trying hard to change things around by removing an > > obscure layer from between the host and the target distros, hopefully > > forcing a tighter coupling of them. At least it should be possible to > > > I'm afraid things don't work like that. Alignment needs to > happen for its own sake. It just makes sense to simplify > and streamline our work and work shoulder to shoulder with > upstream and other distros. Forcing that alignment through > tools before it's there just means the tools don't get adopted. Sure, I'm not saying that SB2 will necessarily force this stuff on people, just that SB1 probably tilted the table so that it encouraged sub-optimal way of working. This is very fuzzy of course :) /lauri ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Public maemo repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rodrigo Vivi wrote: > > I don't believe that wait is a good approach. If we believe and > conclude that Ubuntu Mobile will be a good alternative we need to join > and help the Ubuntu community to do that. This kind of contribution > that makes the free software community even better. And if you just > wait for, I really don't believe that the Ubuntu Mobile for arm will > be released soon because they are focused on x86 platform and don't > have a cross compile environment yet. > But don't think that I'm telling "Let's do it.". I'm just telling that > somehow we need to move on and contribute with projects that we > believe in. > As a member of the Ubuntu Embedded and Mobile team I second that and invite you to join us in any fashion you are up to. More info can be find here: https://wiki.ubuntu.com/MobileAndEmbedded []s Adilson. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGqQTt2cB5Bt7H7YARAjYmAJ9Btbc2yg353LfgZnTWOuepWXcySQCgoo6g 34RQKUOjbMtsu6BlqoFBOqI= =tXIE -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 & maemo
> As long as Nokia works in the current, essentially forked, mode, > nothing will happen. Nokia needs to look at the way it interacts with > upstream projects and change. Sure it can be painful, but hiding > behind a smoke-screen of "product program priorities" is just not > helping to solve the real issues. > > Lauri, I can see you've been away for too long and missed some of the action ;-) >>> One day we will anyway be >>> running debian/stable with a few custom components on the tablets. >>> >> You mean switching back to OABI? >> > > Not really =) > This needs the current armel port to mature and be accepted to debian. > Nokia pushing it and putting resources into it would seriously help, I > think. So far Nokia has done next to nothing right in the distro > Fair enough. > maintenance area. If SB1 somehow contributed to this state of affairs > I'm really sorry > about it, SB2 is trying hard to change things around by removing an > obscure layer from between the host and the target distros, hopefully > forcing a tighter coupling of them. At least it should be possible to > I'm afraid things don't work like that. Alignment needs to happen for its own sake. It just makes sense to simplify and streamline our work and work shoulder to shoulder with upstream and other distros. Forcing that alignment through tools before it's there just means the tools don't get adopted. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 & maemo
> The big problem is that hildon depends on an old, forked version of gtk+ that > nobody in > their right mind wants on their x86 systems. The nokia people at guadec were > unable to > give me an ETA on when that will be fixed :( > There's been a huge amount of progress towards fixing that. Nowadays the delta between gtk+ and maemo-gtk+ is much much smaller. Tommi Komulainen presented on that this GUADEC. And as Riku pointed out Hildon now runs on stock gtk+ with minimal patching. Lucas Rocha [2] and Karoliina Salminen [3] had presentations on the Hildon Desktop this GUADEC. We're not yet 100% there but things have progressed to the point were it has been possible for Ubuntu Mobile to adopt Hildon. [1] - http://guadec.org/node/584 [2] - http://guadec.org/node/561 [3] - http://guadec.org/node/547 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 & maemo
ext Lauri Leukkunen wrote: > Hi, > > Scratchbox2 can now be found in debian, unstable and testing carry frequently > updated releases of it. I've been going over a number of packages trying > to test it. I think it's pretty good considering the limited amount > of people using it, and the fact that the public maemo rootstraps are an > insult to all root filesystems. > > Most problems arise from maemo being totally geared towards SB1, which > is terribly unfortunate. It has resulted in rootstraps being stripped > of many essential packages to make them even marginally useful, all because > SB1 has kindly provided those and even pretended that its versions > satisfy build-dependencies for them. Target images are quite a bit more > useful, but require special tools to extract files out of jffs2 images, I agree that it would make more sense to have all essential packages in the distro and in the rootstraps rather than in scratchbox. Being dependent on scratchbox updates in order to update dependencies is not fun. ... > Nokia and Maemo community really need to figure out an easy way for > developers to use the real hardware and system-mode qemu. Those are the > only adequate solutions for testing and debugging of software. > No doubt system emulation would be a good thing but I wouldn't go as far as saying that it's the only adequate solution. For application development you can do a lot with the current system as you can see in this list and the application catalog. > Also note that SB2 is totally not interested in doing x86->x86 development, > > like what many people are doing today with SB1. People need to wake up, smell > the coffee, integrate with debian proper and get with the program. It's > stupid to maintain a lame x86 port of maemo which nobody wants when all the > Many (most?) people actually do a lot of their development on x86 so at least in that sense you could say they want that distro ;-) Nevertheless I too would prefer Maemo to be well aligned with Debian so we could focus more on what is specific to us and less on redoing their work. > components should be pushed to debian and ubuntu and get those bigger > communities involved in their development. One day we will anyway be > Indeed. When it comes to Hildon that is certainly starting to happen now. > running debian/stable with a few custom components on the tablets. > That was the aim with this whole debian thing in the first place, remember? > Well, a few custom components is a big understatement ;-) But yes, building on Debian was the thinking. As you know better than me we started like that with a snapshot of debian/unstable and somehow we never really got serious enough about keeping up with that plan. > regards, Lauri > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Public maemo repository
On 7/23/07, Marius Vollmer <[EMAIL PROTECTED]> wrote: > "ext Kees Jongenburger" <[EMAIL PROTECTED]> writes: > > > from what I understand it' maemo that has been assembled from well > > known wood sources (debian/linux/glib/gtk). I just can't imagine that > > you could have been that creative/productive with hildon if you also > > had to manage external deps/communication. > > Why not? Hildon was one of the first things that went fully public > after the 770 launch. We had to deal with the consequences right > away. We might not have been perfect in doing that (enormous, sudden > API breaks, no proper releases, etc). > > We didn't provide Hildon in the context of a continuously evolving > distribution, but doing that would not have slowed us down, I think. > We just would have had to learn some lessons earlier. > > > Nokia does not make it a secret that they choose for "strong > > upstream projects" and the last moves (the ubuntu mobile stuff) > > shows that apparently something was created that will be usable on > > different platforms. so you are really going the distro/generic > > aproach where the person who packages a package and the person who > > created software are not the same. > > Yes, I don't insist that Nokia has to run the "maemo Distribution". > Ubuntu Mobile could make the maemo distribution unnecessary. In fact, > my first reaction when I heard people start talking about a maemo > distribution was: Isn't it a bit late now? Can't we just wait for > Ubuntu Mobile? I don't believe that wait is a good approach. If we believe and conclude that Ubuntu Mobile will be a good alternative we need to join and help the Ubuntu community to do that. This kind of contribution that makes the free software community even better. And if you just wait for, I really don't believe that the Ubuntu Mobile for arm will be released soon because they are focused on x86 platform and don't have a cross compile environment yet. But don't think that I'm telling "Let's do it.". I'm just telling that somehow we need to move on and contribute with projects that we believe in. > > Anyway i wonder what part of maemo is to be attractive if the hildon > > development goes "outdoors". > > The community will still cluster around maemo, of course: the planet, > garage, etc, and maybe the distribution. > > > Could you elaborate a litte on the choice for debian as opposed to > > openembedded or the openwrt kind of distro's?(small fast ships that > > allow water-skying :P ) is that the strong upstream projects thing? > > I can't talk about the initial choice as it was already made when I > joined Nokia (and it was in fact one of the points that convinced me > that Nokia got it right before the 770 was launched). > > Later, when enabling real package management in IT OS 2006, I talked > some with the people involved in OpenEmbedded, Emdebian and looked at > ipkg, etc. At that point, we already had the SDK based on Scratchbox > and the Debian packaging tools were used internally and externally. > Neither of the alternatives seemed to offer enough advantages to > justify a switch. OpenEmbedded doesn't imply ipkg. Mamona already has a repository with .deb and sources (.dsc) generated using OpenEmbedded. Another thing that is necessary to say is that OpenEmbedded and scratchbox can coexist. OE is a great buildsystem to build the distribution itself (avoiding monkey work) and scratchbox is a great cross-compile environment that is very useful to make faster the compilation in a SDK like maemo. > > The 770 and N800 hardware has no problem running dpkg and apt, > Scratchbox is (on average :-) a nice cross-compiling substitute and if > anything Operating Systems for mobile devices will converge with OS's > for general purpose computers (that's why Nokia went with Linux, X11, > Gnome, etc in the first place). Thus, there is no point to go with > some specialized, 'niche' approach to save 2 MiBs of flash[1]. > > Projecting this into the future means that we should work to make a > existing mainstream OS distribution useable as the base of the > Internet Tablet OS. That could be Debian GNU/Linux or Ubuntu. Our > vehicle to get there could be our own maemo distribution, or we could > skip that step. > > [1] Yes, I admit to freely waste hardware resources to save human > resources and to stay in the mainstream. Old time embedded > engineers might get gray hairs about that attitude, but then they > should go and program washing machines... ;-) > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > -- Rodrigo Vivi INdT - Instituto Nokia de Tecnologia Blog: http://blog.vivi.eng.br GPG: 0x905BE242 @ wwwkeys.pgp.net ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Webkit based browser on N800
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Oliver Dole schreef: > Hi, > > It's my pleasure to announce that we just released OWB, a webkit-based > browser > We also plan to start a GTK port Another one?!?![1][2] regards, Koen [1] http://trac.webkit.org/projects/webkit/wiki/BuildingGdk [2] http://gtk-webcore.sourceforge.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGqMjpMkyGM64RGpERAqPXAJkBjRSg0Yz508iwOyBVGZ4nJtN9aQCfX8wG rOFTesNuAUf7GyTVqdHC4Bw= =U+8F -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: hildon dependency on modified gtk+ (was: sbox2 & maemo)
On 7/26/07, Loïc Minier <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 26, 2007, Loïc Minier wrote:
> > Would be nice if someone could add a #ifdef GDK_CLOSE_ALL_AVAILABLE
> > etc. :)
>
> Updating my own question: this function is within "#ifdef
> MAEMO_CHANGES"; does that mean that if we start pulling some maemo
> changes into Gtk to build hildon (such as the filechooser API which was
> mentionned in the thread), then we need the full patch?
The issue here is: the pc file for hildon-1 hardcodes MAEMO_CHANGES to
1, so anything you build on top of it will get that define. This wan
fine by the time we did it ("if you use hildon you surely want all the
stuff and certainly you are using our gtk version"), but now that we
aim to be an upstream project it is no longer acceptable. At the very
least we should add the MAEMO_CHANGES to the pc file only if hildon-1
is compiled against our gtk. More rational configuration management is
badly needed here.
>
> If yes, how does one get this patch? By diffing SVN's gtk in
> stage.maemo.org/maemo/projects/haf/trunk/gtk+ with upstream's?
>
> --
> Loïc Minier
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Webkit based browser on N800
Hi, It's my pleasure to announce that we just released OWB, a webkit-based browser which aim is to present an abstraction layer for different parts of the browser architecture, making porting effort smoother and faster. For instance, we have an abstraction for network part (currently curl based) or for graphics part (currently sdl based). This project is known to compile and run fine for N800... The drawback is that the current port is SDL based. This implementation raises some troubles like text input inside the browser which are for now impossible since the keyboard does not show up. If you want to have a look to OWB, you can check http://www.sand-labs.org/owb/ To checkout the sources: svn checkout http://www.sand-labs.org/svn/trunk/ Further information on how to compile OWB for N800 can be found at this location: http://www.sand-labs.org/owb/wiki/OwbN800 We also plan to start a GTK port in order to get OWB running on GTK/Hildon but I don't really have a timeframe about that, so if some people are willing to see webkit on N800 / GTK, please show up, any help is greatly encouraged :) Best regards, -- Olivier DOLE Software Engineer ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Licensing of dummy packages / of the packaging
Hi there, There are some dummy / dependencies-mostly packages in the maemo archive such as haf-marketing-release or maemo-af-desktop-l10n which do not carry much licensing information. The debian/copyright file is along: Copyright (C) 2006 Nokia Corporation and pretty much nothing more. Would it be possible to clarify that the packaging or the full source are under the LGPL for example? I don't think you *need* to explicitely declare the licensing of all the packaging in all packages, but the mostly empty ones are without any license, and that's a bit problematic. Perhaps you can simply add a COPYING.LGPL file and a small statement that "this package is under the LGPL version foo blahblah". Thanks! -- Loïc Minier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: hildon dependency on modified gtk+ (was: sbox2 & maemo)
On Thu, Jul 26, 2007, Loïc Minier wrote: > Would be nice if someone could add a #ifdef GDK_CLOSE_ALL_AVAILABLE > etc. :) Updating my own question: this function is within "#ifdef MAEMO_CHANGES"; does that mean that if we start pulling some maemo changes into Gtk to build hildon (such as the filechooser API which was mentionned in the thread), then we need the full patch? If yes, how does one get this patch? By diffing SVN's gtk in stage.maemo.org/maemo/projects/haf/trunk/gtk+ with upstream's? -- Loïc Minier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 & maemo
Riku Voipio <[EMAIL PROTECTED]> writes: > Marius Vollmer wrote: > >> There are two kinds of borders: one kind isolates OSs from each >> other; this could be done with some virtualization tool like xen, >> uml, or maybe chroot. The other kind isolates different >> architectures within the same distribution; this is what SB2 does. > > There has been some thinking about this dilemma, and we have pretty > much decided that we will not implement anything that does the first > kind of isolation in sb2. A separate tool can be created for that > purpose. Yes, exactly my view. So, I think I am getting sb2 now (in both senses :). ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: hildon dependency on modified gtk+ (was: sbox2 & maemo)
On Thu, Jul 26, 2007, Tommi Komulainen wrote: > Currently the only required patch for hildon stack is one that exports > some GtkFileChooser headers so that hildon-fm can run. Everything else > is available in gtk+ trunk or #ifdef'd out (except for oversight in > hildon-desktop.) Yeah; while talking about this, I think this was introduced around june: make[4]: Entering directory `/home/lool/bzr/debian/pkg-maemo/hildon-desktop/debian/libhildonwm' /bin/bash ../libtool --tag=CC --mode=compile i486-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -DMAEMO_CHANGES -I/usr/include/hildon-1 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -DORBIT2=1 -pthread -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -DORBIT2=1 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -DORBIT2=1 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DLOCALEDIR=\"/usr/share/locale\" -DDESKTOPENTRYDIR=\"/usr/share/applications\"-Wall -g -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -Werror -Wno-format-extra-args -c -o hd-wm.lo hd-wm.c i486-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -DMAEMO_CHANGES -I/usr/include/hildon-1 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12 -DORBIT2=1 -pthread -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -DORBIT2=1 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -pthread -DORBIT2=1 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DLOCALEDIR=\"/usr/share/locale\" -DDESKTOPENTRYDIR=\"/usr/share/applications\" -Wall -g -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -Werror -Wno-format-extra-args -c hd-wm.c -fPIC -DPIC -o .libs/hd-wm.o cc1: warnings being treated as errors hd-wm.c: In function 'mce_handler': hd-wm.c:708: warning: implicit declaration of function 'gdk_close_all_temporary_windows' make[4]: *** [hd-wm.lo] Error 1 make[4]: Leaving directory `/home/lool/bzr/debian/pkg-maemo/hildon-desktop/debian/libhildonwm' Would be nice if someone could add a #ifdef GDK_CLOSE_ALL_AVAILABLE etc. :) -- Loïc Minier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 & maemo
On 7/26/07, Marius Vollmer <[EMAIL PROTECTED]> wrote: > From my point of view, the host and target distributions should be as > independent as possible. The host could be Debian, or Redhat, or > Nokia's internal Linux, or OSX, or even Windows. There are many, many ways to solve this, starting from running a chroot and continuing all the way up to vmware & co. SB2 would then be used in that "virtualized" environment. > The SB2 idea seems to be that there is only one distribution, and SB2 > is a clever hack to allow you to compile for a different target > architecture than the host one without having to worry about > cross-compilation complexities too much. Pretty much yes. SB1 tried to pretend that it's a "generic" cross-compilation tool, but ended up being neither generic nor specific. > Thus, from what I understand about SB2, I would characterize the > situation so that the "sb2" command takes you from the host > architecture to the target architecture, but stays in the same > distribution. The host and target architecture environments are > separate installations of this one distribution, and you need to make > sure that both of them are properly up-to-date and syncronized. All target distributions have build requirements, of course we could construct maemo to be a totally non-debian distro but still use debian/unstable as build requirements. It would be weird, but certainly possible. It's pointless to pretend that we could construct a new distro that could use any linux distro from the past five years as build requirements. That just won't work. Using something like the project-builder from ubuntu might be a way to provide the build deps on a number of different host distros. > Programs that run inside the target architecture environment get a > native environment to run in and a properly emulated CPU to run on. > Thus, they never know that they are effectively being cross-compiled. > This is too slow for some programs like the compiler, so here comes > the clever part of SB2: there is a conceptual second layer of > emulation that emulates the host architecture on the target > architecture with the magical property that the two layers of > emulation cancel each other out and performance actually increases. Well, by default we're really staying in the host as much as possible, it's all path based, so if you access files from let's say /usr/share they are by default the target files, with quite a few exceptions to support running the build tools. I've tried to make sure the build tools get their own files from the host always, this reduces the number of packages that need to be installed for the target, and it's the right thing anyway. > This is a good and simple model, the only thing I don't like about it > is that I can't choose or configure my host environment independently > from the target environment. There are ways to work around this as described above, it would not be smart to include yet another way into sb2. That would only make it bigger with all the downsides of SB1. /lauri ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 & maemo
Marius Vollmer wrote: > There are two kinds of borders: one kind isolates OSs from each other; > this could be done with some virtualization tool like xen, uml, or > maybe chroot. The other kind isolates different architectures within > the same distribution; this is what SB2 does. > There has been some thinking about this dilemma, and we have pretty much decided that we will not implement anything that does the first kind of isolation in sb2. A separate tool can be created for that purpose. Lets try to keep sb simple this time :) > In order for me to use SB2 and still retain control over my host OS, I > would have to install the OS that SB2 wants as its host inside a > virtual machine. That's not a problem, of course. I think I found my > weekend project... > That is not that different than what Debian/Ubuntu developers already do. Their host OS is whatever it is (etch/testing/sid or dapper/gutsy or whatever), with whatever crap and extra hacks installed. When building packages to distro, a clean chroot of target distro or pbuilder is used. > So, in the end, I think it's actually all quite simple: we make a OS > that runs on real x86 hardware, inside Xen on x86 and on a Internet > Tablet arm device and can be used both as a development environment as > well as the basis for IT OS. That OS includes sb2 which is used to > 'cross-compile' software from i386 to armel. > The *main* point here needs to be that all development tools inside the X86 development system need to unmodified packages from some mainstream distro. Else we end up maintaining a similar soup of patched and hacked packages that nobody dares to upgrade. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 & maemo
"ext Lauri Leukkunen" <[EMAIL PROTECTED]> writes: > At least it should be possible to build a package for both host and > target distros like this: > > cd my_package > dpkg-buildpackage -rfakeroot > sb2 dpkg-buildpackage -rfakeroot Hmm, I am still quite fuzzy about what SB2 is all about. Maybe you can hep me out a bit. >From my point of view, the host and target distributions should be as independent as possible. The host could be Debian, or Redhat, or Nokia's internal Linux, or OSX, or even Windows. The target distribution right now is the existing maemo mess, but we could collectively move to Debian or Ubuntu. In any case, people might use whatever host OS works for them, but would work all on the same target distribution. The SB2 idea seems to be that there is only one distribution, and SB2 is a clever hack to allow you to compile for a different target architecture than the host one without having to worry about cross-compilation complexities too much. Thus, from what I understand about SB2, I would characterize the situation so that the "sb2" command takes you from the host architecture to the target architecture, but stays in the same distribution. The host and target architecture environments are separate installations of this one distribution, and you need to make sure that both of them are properly up-to-date and syncronized. Programs that run inside the target architecture environment get a native environment to run in and a properly emulated CPU to run on. Thus, they never know that they are effectively being cross-compiled. This is too slow for some programs like the compiler, so here comes the clever part of SB2: there is a conceptual second layer of emulation that emulates the host architecture on the target architecture with the magical property that the two layers of emulation cancel each other out and performance actually increases. This second layer of emulation makes use of the programs installed in the host distribution. This is the reason why everybody needs to agree on the host distribution as well as on the target distribution, but the two distributions don't need to be the same for this reason. The two distributions need to be the same since the host distribution is directly used for development of the same software that is compiled in the target architecture environment. The host environment is much nicer for testing and debugging, since the SB2 emulation is good enough for compiling, but not for really booting and running the distribution. This is a good and simple model, the only thing I don't like about it is that I can't choose or configure my host environment independently from the target environment. There are two kinds of borders: one kind isolates OSs from each other; this could be done with some virtualization tool like xen, uml, or maybe chroot. The other kind isolates different architectures within the same distribution; this is what SB2 does. In order for me to use SB2 and still retain control over my host OS, I would have to install the OS that SB2 wants as its host inside a virtual machine. That's not a problem, of course. I think I found my weekend project... [ There is another picture in my head that I think might work: we keep the current SB1 setup but instead of having SB1 redirect tools into devkits, it redirects tools into a second target. That second target can then be maintained in the usual way. But I like the full-virtualization approach much better than the half-assed SB1 emulation. ] So, in the end, I think it's actually all quite simple: we make a OS that runs on real x86 hardware, inside Xen on x86 and on a Internet Tablet arm device and can be used both as a development environment as well as the basis for IT OS. That OS includes sb2 which is used to 'cross-compile' software from i386 to armel. As a bonus, we could extend the range of supported hardware platforms (Xen on PowerPC, Intels x86 mobile platform, sb2 from powerpc to i386...) Debian GNU/Linux is pretty close to these requirements: it doesn't run on Internet Tablets yet and it probably can't be the basis for IT OS if it would. Both issues should be straightforward to address. (I hope I don't have to explain why they are worth addressing. :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
hildon dependency on modified gtk+ (was: sbox2 & maemo)
On Thu, 2007-07-26 at 10:04 +0200, ext Koen Kooi wrote: > The big problem is that hildon depends on an old, forked version of gtk+ that > nobody in > their right mind wants on their x86 systems. The nokia people at guadec were > unable to > give me an ETA on when that will be fixed :( Currently the only required patch for hildon stack is one that exports some GtkFileChooser headers so that hildon-fm can run. Everything else is available in gtk+ trunk or #ifdef'd out (except for oversight in hildon-desktop.) -- Tommi Komulainen<[EMAIL PROTECTED]> ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Errors while installing Maemo3.1 on Debian Linux
I'm trying to install the Maemo 3.1 SDK on Scratchbox under Debian Linux, and I am getting errors at step 3.3 in the installation guide: [sbox-SDK_X86: ~] > fakeroot apt-get install maemo-explicit (lots of stuff that seems to have worked, then:) Setting up maemo-explicit (3.0) ... W: Couldn't stat source package list http://repository.maemo.org bora/free Packages (/var/lib/apt/lists/repository.maemo.org_dists_bora_free_binary-i386_Packages) - stat (2 No such file or directory) W: Couldn't stat source package list http://repository.maemo.org bora/non-free Packages (/var/lib/apt/lists/repository.maemo.org_dists_bora_non-free_binary-i386_Packages) - stat (2 No such file or directory) W: You may want to run apt-get update to correct these problems The above happens for both SDK_X86 and SDK_ARMEL. In both cases, my sources.list contain the following: deb http://repository.maemo.org/ bora free non-free deb-src http://repository.maemo.org/ bora free deb file:/home/david/maemo-sdk-nokia-binaries_3.1 bora explicit Can anyone suggest why the error is occurring, and what I need to do to correct it? Is there perhaps something wrong with the placement of the files on the repository.maemo.org site? This certainly seems to be what the installer is complaining about. (In fact, I had a similar problem when I was trying to install Scratchbox. I had to download the files to my local system manually, adjust their relative placement in relation to the Packages.gz file, and then install from my local path.) I don't know whether it is related, but I had problems with the download of the Maemo 3.1 files from the website. I was able to download the release notes and installation instructions, but my attempt to download the SDK installer script failed on my Debian Linux system. However, I was able to download the script from my Windows XP system. I'm fairly new to Linux development, although I do have lots of experience (about 24 years!) of software development on many operating systems. Regards, David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 & maemo
Koen Kooi wrote: > The big problem is that hildon depends on an old, forked version of gtk+ that > nobody in > their right mind wants on their x86 systems. The nokia people at guadec were > unable to > give me an ETA on when that will be fixed :( > > Guadec of what year? :P http://packages.ubuntu.com/gutsy/x11/hildon-desktop looks like a recent enough non-forked gtk to me...[1] >> One day we will anyway be >> running debian/stable with a few custom components on the tablets. >> > > You mean switching back to OABI? > > unofficial[2] Debian EABI port is pretty much ready for what tablet's would need from it. D-I, java (argh, but being worked on) and FORTRAN (Argh!!) are the main incomplete things, but they do not really touch tablet usage. What _is_ missing for tablet usage is free UI's for selected things (input, wifi/bluetooth network connectivity etc), which I expect the Ubuntu mobile people already be working on. [1] Well it's still patched but the patches are included in mainstream distros' gtk and being integrated upstream. [2] http://lists.debian.org/debian-arm/2007/07/msg00076.html ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 & maemo
On 7/26/07, Koen Kooi <[EMAIL PROTECTED]> wrote: > > It's > > stupid to maintain a lame x86 port of maemo which nobody wants when all the > > components should be pushed to debian and ubuntu and get those bigger > > communities involved in their development. > > The big problem is that hildon depends on an old, forked version of gtk+ that > nobody in > their right mind wants on their x86 systems. The nokia people at guadec were > unable to > give me an ETA on when that will be fixed :( As long as Nokia works in the current, essentially forked, mode, nothing will happen. Nokia needs to look at the way it interacts with upstream projects and change. Sure it can be painful, but hiding behind a smoke-screen of "product program priorities" is just not helping to solve the real issues. > > One day we will anyway be > > running debian/stable with a few custom components on the tablets. > > You mean switching back to OABI? Not really =) This needs the current armel port to mature and be accepted to debian. Nokia pushing it and putting resources into it would seriously help, I think. So far Nokia has done next to nothing right in the distro maintenance area. If SB1 somehow contributed to this state of affairs I'm really sorry about it, SB2 is trying hard to change things around by removing an obscure layer from between the host and the target distros, hopefully forcing a tighter coupling of them. At least it should be possible to build a package for both host and target distros like this: cd my_package dpkg-buildpackage -rfakeroot sb2 dpkg-buildpackage -rfakeroot I don't know any way to make it significantly easier than that. > > That was the aim with this whole debian thing in the first place, remember? > > Not marketing targeted at geeks? Honestly that came later, although it has worked pretty well, no? /lauri ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: sbox2 & maemo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lauri Leukkunen schreef: > Also note that SB2 is totally not interested in doing x86->x86 development, > like what many people are doing today with SB1. People need to wake up, smell > the coffee, integrate with debian proper and get with the program. I agree with that > It's > stupid to maintain a lame x86 port of maemo which nobody wants when all the > components should be pushed to debian and ubuntu and get those bigger > communities involved in their development. The big problem is that hildon depends on an old, forked version of gtk+ that nobody in their right mind wants on their x86 systems. The nokia people at guadec were unable to give me an ETA on when that will be fixed :( > One day we will anyway be > running debian/stable with a few custom components on the tablets. You mean switching back to OABI? > That was the aim with this whole debian thing in the first place, remember? Not marketing targeted at geeks? regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGqFVxMkyGM64RGpERAnQsAJwN6pV7jGNvhAsj9L3B2apdBEngWACcD7LI UJYH2aGwUWyMgVEehMoEpXY= =oMOm -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
