Re: Public maemo repository
Hi Quim Gil, When I wrote that I was not with nokia company in my mind but the maemo community that is made by people. I know that there is no free lunch, and many (most?) of this community is being payed to work on this platform, but I was thinking in free time contributing, that is common in free software community. I'd never write that thinking in nokia itself because I know that for a company it is not easy to change. There are costs, strategy, discussions, etc... About the technical challenges, I'm pretty sure about that and I have all of them when building Mamona. Sorry if I was not clear in my last email. Regards, vivijim. On 8/7/07, Quim Gil [EMAIL PROTECTED] wrote: Hi, On Thu, 2007-07-26 at 13:20 -0300, ext Rodrigo Vivi wrote: I don't believe that wait is a good approach. We are not waiting. We are doing plenty of things. Nokia didn't wait to start producing n years ago tablets with Debian GNU/Linux and GNOME inside. We are dealing now with real products already in the market and only this should explain clearly why our priorities today can't be just the same than the ones Ubuntu Mobile currently has. A bit more of background about Nokia not waiting. For what I know Nokia didn't wait Debian to have something ready when the maemo project started. They (I say 'they' because this happened before I joined) didn't wait either Ubuntu to become mobile, being present and active in the Ubuntu summits and keeping good communication with the key people in Canonical. We were talking with Intel and others in the context of the GNOME Mobile conversations months before the initiative was announced (in fact Nokia's participation in this initiative was key since the first day). We didn't wait to talk face to face to Intel about collaboration as soon as they talked publicly about their MID using Hildon. We didn't wait to make explicit this collaboration with Intel and Canonical, making all our internal steps at light speed (in corporate sense) to start moving Hildon to real GNOME upstream. This thread shows that we are not waiting today/tomorrow either. 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. A move like this is not done by belief. You check strategies, you look at processes, you analyze interests, you listen, you discuss and a long etc until the day you decide to change the way you have been doing things for another way that seems more appropriate. Then another odyssey starts. Doing all these while keeping your production and own RD is not simple. Besides, there is no single good alternative to the current status. Ubuntu, Debian, maemo distro... all these options have pros and cons and 'belief' is perhaps one of the worst advisers when you have a project like Nokia has in its hand with maemo and the tablets. Also, help the Ubuntu community is a nice way to put it. We are helping Intel and Canonical as well (or primarily, at this stage). As for today this means we are indirectly helping also Samsung, Fujitsu, Kohjinsha, HTC, Amtek, Elektrobit and probably other vendors to come. No problem, we believe in open source collaboration and we expect this help provided and received to be sustainable and useful for all parties. But don't be surprised if we get questions from a business perspective, since all these organizations are businesses as well. More than businesses, they are also brands. Brands are amazing: just a name and a logo bring a complex message to the inner parts of people's consciousness. Nokia joining the Ubuntu Mobile project sponsored by Canonical and Intel is a single sentence that tells nothing specific to a distro developer but has a strong many for the rest of population (in fact this sentence would have 100 interpretations). And well, don't you think that there are not technical challenges in the pure codebase. Ubuntu and maemo lovers should know all this already: It's not only about ARM/EABI vs x86. We have cross-build vs native build, toolchain changes, different security models, single user system vs multi-user, root vs no root, passwords management, different organization in partitions and package management, Busiybox vs GNU utilities, Perl and Python as essential or not, debconf yes or not, upstart yes or not, Kdrive X vs full X, different way to handle localization a lot more. And what about the differences in product schedules, that's another whole story. Nothing that couldn't be aligned somehow (nor with pure original Debian if that option should be chosen) but you reckon the amount of effort is noticeable - already if we enter at a planning level. Remember that for Nokia (and for any company) effort = time + people + money. As said we are doing plenty of things and we probably are doing a good use of time, people and money available. Helping the Ubuntu community is not a free-as-in-beer exercise. This
Re: Public maemo repository
Hi Rodrigo, On Tue, 2007-08-07 at 19:57 -0300, ext Rodrigo Vivi wrote: Hi Quim Gil, When I wrote that I was not with nokia company in my mind but the maemo community that is made by people. No problem! I wasn't seeing you as anything different as community. In fact I wasn't answering to you personally, I just took an anchor and tried to come up with a satisfactory answer for the people that here and there are telling us that we just or simply (real quotes) should take Ubuntu Mobile as a base. Not only in this thread, see also the comments at http://desdeamericaconamor.org/blog/node/378 Those people are asking us as Nokia to do the step, this is why I though it was worth to see in more details what this implies for us as Nokia. The maemo community can embrace any initiative, we as Nokia can only be happy about that (being Mamona, Poky, Newton port and etc). We want people to play and experiment as much as they want with the tablets and with (or without, no problem) maemo. Doing official steps. Well, that's another story. It is good that 'the community made by people' is aware about the details that might not be evident. Sorry if I was not clear in my last email. No, sorry me since I should have been clearer in the first place. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Public maemo repository
Hi, ext Kees Jongenburger wrote: From my point of view as user as you call them has no access to the sbuild/buildd/debuild system, they get an sdk and that's it, Creating an improved dh_make , recompiling the package to use the thumb instruction set or not, are simply not part of the things that can be done (or am i missing the big picture?) You can override with Scratchbox all packages compilation flags. Just use the SBIX_EXTRA* and SBOX_BLOCK* environment variables documented in your Sbox installation /scratchbox/doc/variables.txt document. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Public maemo repository
On 8/6/07, Eero Tamminen [EMAIL PROTECTED] wrote: Hi, ext Kees Jongenburger wrote: From my point of view as user as you call them has no access to the sbuild/buildd/debuild system, they get an sdk and that's it, Creating an improved dh_make , recompiling the package to use the thumb instruction set or not, are simply not part of the things that can be done (or am i missing the big picture?) You can override with Scratchbox all packages compilation flags. Just use the SBIX_EXTRA* and SBOX_BLOCK* environment variables documented in your Sbox installation /scratchbox/doc/variables.txt document. Thanks Eero, I was trying to determine the process you guy's where performing when creating a new SDK. I was also trying to understand if that process was usable by me I guess the process is described in here http://sardine.garage.maemo.org/build_environment.html with the download/build status here http://repository.maemo.org/sardine/armel/herring/packagestatus.html It would be great to hack the same functionality user packages! greetings - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Public maemo repository
On Mon, Jul 30, 2007 at 02:03:53PM +0200, ext Kees Jongenburger wrote: On 7/30/07, Daniel Stone [EMAIL PROTECTED] wrote: On Fri, Jul 27, 2007 at 09:14:09PM +0200, ext Kees Jongenburger wrote: What kind of step does a user have to take between creating it's own package and the sbuild/buildd/debuild aproach? isn't this hole open-source thingy about giving power to the user? It depends entirely on the tools. You could easily construct an improved dh_make that required no editing of any files at all. It has nothing to do with the packaging system itself, as cdbs's three-line debian/rules files have shown. I am really not trying to be annoying or anything I really am trying to understand. From my point of view as user as you call them has no access to the sbuild/buildd/debuild system, they get an sdk and that's it, Creating an improved dh_make , recompiling the package to use the thumb instruction set or not, are simply not part of the things that can be done (or am i missing the big picture?) Sorry, I completely misread your question. As for the build part, again, this is just a question of tools, and not a fundamental limitation of the packaging system. Something like pbuilder almost certainly does what you want. (That our SDK could certainly be improved is a separate issue as to whether we should use OE/BitBake or Debian packages.) If you are using dh_make you are not using the power of the existing debian packages and you are in trouble Who was saying this? Using dh_make is fine. If you want your packages to be good, then you should clean up the template a bit, yes. I guess it's fine as long as it's you own software you are packaging. I understand that one must put some effort in packaging. I was referring to the missing libs like some sdl packages or sqlite3 etc. I you run dh_make on those your a in trouble since different packagers will give the libs different names/options. Again am i missing the big picture or how do I get sqlite3 in maemo? Usually, you just take the sqlite Debian package, and build it in a Maemo SDK. Again, the problem you mention is completely independent of the build system: I could create a BitBake package called 'sqlite' and you create one called 'sqlite3', and we have exactly the same problem in another packaging system. if you don't use dh_make and try to use upstream packages + patches you are in trouble because you are creating the chaos youself, You are also prooving that the initial source packaging was not sufficient for your need I don't see what you mean here? This is again about the differences between maemo .deb packages and mainstream packages they are not the same and maemo as community does not provide a place to upload those changes/patches. When nokia chooses to create a new distro people are constantly trying binnay packages of exiting app that where ported earlyer in the hope it sill works. IMHO not an optimal solution Yes, again, we could've done a lot better on the SDK/distro side of things, but this is also a separate problem from the packaging system. Most Debian packages won't work (unless you use the new armel port), because we use EABI and Debian's arm port doesn't -- mismatching toolchains generate incompatible binaries. We should be a great deal better at giving back to Debian in general, and working to develop better-integrated support for cut-down systems (embedded and consumer devices), so you can take packages straight from Debian and build them with no changes (as opposed to the Emdebian approach). But we haven't been, and that -- like the others -- is another problem with the approach we've been using, not our packaging system. I think there is a big difference between those systems. Me as developer ,I have the same tools as you the packager (as I tend to call people who create packages) bsd ports,gentoo portage and oe contain meta packages. lets' face it what good did the packaging bring maemo until now? I don't understand I am still waisting my time with this packaging issue. The possibly to derive from an existing system, not having to invent our own packages or tools to solve problems that have already been taken care of long ago? :P I understand but just try to be on my side for a few minutes. I am experiencing the complexity of the debian packaging with the tweaks required for the maemo platform. I was not born as debian developer. I really did not care about repositories, free non-free stable unstable . I did not care about arch, I did not ask for dh_make. dpkg-xxx. All I really want is to be able to share software, and improve existing software for the arm platform (like sdl). The current packaging does not make it easy to do either. I hope that this will improve in the future. just having a public maemo repository is not enough. % dh_make % debuild -us -uc (or, if you have a broken Scratchbox: dpkg
Re: Public maemo repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Stone schreef: (That our SDK could certainly be improved is a separate issue as to whether we should use OE/BitBake or Debian packages.) Again, that is not an 'or', OE is perfectly capable of creating debian packages, as the Mamona distro for maemo proves. regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGrdivMkyGM64RGpERAkVtAJ44HZPsI12xuP25wMHjekYZM+DmrACgkxzW ZtDIHX/LVIOtaJZwBB/j+1A= =KSY+ -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Public maemo repository
ext Koen Kooi [EMAIL PROTECTED] writes: To summarize the differences: * OE is a build and packaging tool * Scratchbox is a development tool Hmm: http://www.openembedded.org/ OpenEmbedded is a full-featured development environment [...] :-) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Public maemo repository
Hi Marius, I'll call by end user those developers that use the distro/SDK to develop their programs and by developer those that are coding the distro/SDK itself. OE makes developer's life easier because under OE repository there are a lot of package descriptions and tasks definitions that bitbake (that is a task executor) uses to build what you tell to build. Bitbake is too flexible. But for the end user that is compiling and recompiling his code it is not a good idea to use the OE and bitbake to do the cross-compilation. At that point scratchbox can be useful. OE makes the end user's life easier just when his program is ready to be packed. Instead of create a debian control dir, with a lot of complex files and rules, you just need to add a .bb file with few lines of description and use the bitbake to cross-compile, test and pack it. Yes, it is too close to Gentoo. It is easier to pack. And about the machines it depends on a machine configuration file that you define in OE. If you want a generic arm compilation you can do it, but don't forget that n770 and n800 has some important differences: n770 is armv5te with soft fpu and n800 is armv6 with hard fpu. I'm not telling that dpkg-buildpackage approach is bad and I know that emdebian team is doing a good work to adapt it to cross compiling. What I want to avoid is the creation of debian controls files that I believe that is to painful. Some Months ago Koen said me a truth: Hackers like to code and don't want to spend their time packing Regards, Vivi. On 7/27/07, Marius Vollmer [EMAIL PROTECTED] wrote: ext Rodrigo Vivi [EMAIL PROTECTED] writes: 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. Let me show my ignorance by digging into this a bit deeper. My understanding is that OpenEmbedded is a concrete set of software components that come with detailed instructions for BitBake to cross-compile them for a number of host architectures[1]. Thus, the BitBake recipes for OpenEmbedded components make sure that these components can be cleanly cross-compiled. Scratchbox, on the other hand, 'fakes' a complete emulated environment for the host architecture and the usual autotooled software components can be compiled natively in that environment. Thus, Scratchbox saves you the need to make your software cleanly cross-compilable.[2] These two approches don't conflict, of course. But what is the point of using Scratchbox if all your components are also contained in OpenEmbedded? In other words, if your software is cross-compilable, why use Scratchbox? [ There might be components that are not cross-compilable, such as 3rd party applications that are not part of OpenEmbedded. We shouldn't tolerate these kinds of components, I'd say, since their existence will just increase the chaos. ] And, if your software is cross-compilable, why use BitBake? Isn't dpkg-buildpackage good enough for us? The Emdebian project is going that direction, I think, and it's a good direction.[3] I would expect BitBake to support more host configurations in an easier way than dpkg-buildpackage (for example, changing a compiler flag and recompiling the whole thing), but we don't want to go there, I'd say. There should be one architecture (in the Debian sense) that runs on as much hardware platforms as possible. I don't want to compile separately for the 770 and the N800, or for McCaslin and Menlow, the same way I don't compile separately for Intel and AMD. In that sense, OpenEmbedded is too close to Gentoo for my taste. :) [1] I think cross-compiling terminology goes like this, at least in the GNU project: `--build=BUILD-TYPE' the type of system on which the package is being configured and compiled. It defaults to the result of running `config.guess'. `--host=HOST-TYPE' the type of system on which the package will run. By default it is the same as the build machine. Specifying it enables the cross-compilation mode. `--target=TARGET-TYPE' the type of system for which any compiler tools in the package will produce code (rarely needed). By default, it is the same as host. [2] I think it's close to a miracle that this actually works well enough in practice. [3] If anything, they are too careful by forking all the packaging (emdebian/ versus debian/). Debian prides itself for supporting dozens of architectures, surely making cross-compile-cleanliness an important target will not be rejected? -- Rodrigo Vivi INdT - Instituto Nokia de Tecnologia Blog: http://blog.vivi.eng.br GPG: 0x905BE242 @ wwwkeys.pgp.net ___
Re: Public maemo repository
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rodrigo Vivi schreef: Some Months ago Koen said me a truth: Hackers like to code and don't want to spend their time packing To summarize the differences: * OE is a build and packaging tool * Scratchbox is a development tool They overlap in the 'compiling' part, but that's about it. Both systems were designed for different goals, so I don't see them as competitors[1]. regards, Koen [1] OE even has targets to generate scratchbox1 toolchains -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGqgT1MkyGM64RGpERAuAoAJ43FYJl0rXRiYAWPprdO7h8yDgTcACfR6Vz xYwQs2z799+4+lHzav7Myac= =RQ2z -END PGP SIGNATURE- ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Public maemo repository
ext Rodrigo Vivi [EMAIL PROTECTED] writes: On 7/23/07, Marius Vollmer [EMAIL PROTECTED] wrote: [...] Can't we just wait for Ubuntu Mobile? I don't believe that wait is a good approach. Yep, I agree. With waiting for Ubuntu Mobile I meant to wait for it to emerge enough that we can join them, not wait until it is 'done'. I guess we don't need to wait at all, as Adilson points out. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Public maemo repository
On 7/27/07, Koen Kooi [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rodrigo Vivi schreef: Some Months ago Koen said me a truth: Hackers like to code and don't want to spend their time packing To summarize the differences: * OE is a build and packaging tool * Scratchbox is a development tool This was the best summary ever. I was looking for that ;) They overlap in the 'compiling' part, but that's about it. Both systems were designed for different goals, so I don't see them as competitors[1]. Me neither. regards, Koen [1] OE even has targets to generate scratchbox1 toolchains -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFGqgT1MkyGM64RGpERAuAoAJ43FYJl0rXRiYAWPprdO7h8yDgTcACfR6Vz xYwQs2z799+4+lHzav7Myac= =RQ2z -END PGP SIGNATURE- -- 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: Public maemo repository
On Fri, Jul 27, 2007 at 11:36:55AM -0300, ext Rodrigo Vivi wrote: I'll call by end user those developers that use the distro/SDK to develop their programs and by developer those that are coding the distro/SDK itself. OE makes developer's life easier because under OE repository there are a lot of package descriptions and tasks definitions that bitbake (that is a task executor) uses to build what you tell to build. Bitbake is too flexible. Er, how is this different from Debian, where you have a number of package descriptions and task definitions that sbuild/buildd/debuild uses to build? (Bearing in mind that debian/rules is a Makefile, and thus infinitely flexible.) OE makes the end user's life easier just when his program is ready to be packed. Instead of create a debian control dir, with a lot of complex files and rules, you just need to add a .bb file with few lines of description and use the bitbake to cross-compile, test and pack it. debian/ can be rather verbose, but most users won't need to change much from the dh_make template. I'm not telling that dpkg-buildpackage approach is bad and I know that emdebian team is doing a good work to adapt it to cross compiling. Actually, emdebian is fundamentally the wrong approach, and makes everything far worse than it could possibly be with any other technique. It's almost the worst thing I can think of. What I want to avoid is the creation of debian controls files that I believe that is to painful. Some Months ago Koen said me a truth: Hackers like to code and don't want to spend their time packing Sounds like a recipe for crap packages to me (maybe OE's are good, I don't actually know). If you want incredibly basic skeleton packages, just use the dh_make template and ignore them, and the packages won't be any good. If you want to fix them up so they conform to policy, are more generally useful, are split as they should be, etc, then you'll need to spend time on your packages. This is no different from ebuilds, spec files, or any packaging system I've ever used. The only difference is that debian/ tends to be a little more verbose for the skeleton case. But the core is the same: if you want crap packages, then you can easily create them in any packaging system. If you want good packages, then you need to spend a bit more time. Cheers, Daniel (a developer who is trying his best to ignore packaging now) signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Public maemo repository
Er, how is this different from Debian, where you have a number of package descriptions and task definitions that sbuild/buildd/debuild uses to build? (Bearing in mind that debian/rules is a Makefile, and thus infinitely flexible.) What kind of step does a user have to take between creating it's own package and the sbuild/buildd/debuild aproach? isn't this hole open-source thingy about giving power to the user? Sounds like a recipe for crap packages to me (maybe OE's are good, I don't actually know). If you want incredibly basic skeleton packages, just use the dh_make template and ignore them, and the packages won't be any good. If you want to fix them up so they conform to policy, are more generally useful, are split as they should be, etc, then you'll need to spend time on your packages. If you are using dh_make you are not using the power of the existing debian packages and you are in trouble if you don't use dh_make and try to use upstream packages + patches you are in trouble because you are creating the chaos youself, You are also prooving that the initial source packaging was not sufficient for your need This is no different from ebuilds, spec files, or any packaging system I've ever used. The only difference is that debian/ tends to be a little more verbose for the skeleton case. But the core is the same: if you want crap packages, then you can easily create them in any packaging system. If you want good packages, then you need to spend a bit more time. I think there is a big difference between those systems. Me as developer ,I have the same tools as you the packager (as I tend to call people who create packages) bsd ports,gentoo portage and oe contain meta packages. lets' face it what good did the packaging bring maemo until now? I don't understand I am still waisting my time with this packaging issue. Cheers, Daniel (a developer who is trying his best to ignore packaging now) Exactly, but for me a user packaging is a real issue Greetings ___ 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: 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: Public maemo repository
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? 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. 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
Re: Public maemo repository
ext [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Ok, let me go once again back to this boat analogy. Be sure to understand that an anology is not a model for reality. You can't use it to predict how reality will behave. It is just an aid to talk about reality. Maybe because the whole concept of something that is heavier than water but still floats without effort seemed to be too good to be true. Wood floats, agreed. But sorry, not without effort. You could say: Distributions are boats made out of wood: they require serious effort to keep floating. and you might be right. Then we could argue whether distributions require more effort than they save. Nokia has good engineers even if sometimes you disagree with their decisions. I have no problem passionately disagreeing even with my past self! This is not about pinning blame on someone. It is about recognizing what should have been done (if only we knew better), and how to fix it now. [...] floating wood ends up soaking and sinking if you don't put a lot of effort maintaining it. [ And still people spent the effort. Must have been worth it, don't you think? Also, we found better materials than wood for making ships that require less maintenance. When I said something that is heavier than water but still floats without effort I meant that the thing does not sink right in front of you because of its bowl shape. Dry wood already floats on its own as you observe, and thus is not really heavier than water. Thus, let's drop the boat analogy. ] Combine this RealPhysics principle with the already commented fact that a distro is a lot more than code (i.e. the humans around it) and you find good reasons to start doing what our Nokia team ended up doing in the early days. Nokia was building the maemo community from the beginning and it exists. You seem to say that getting serious about the maemo distribution implies creating a new community. Is that so? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Public maemo repository
Ok, let me go once again back to this boat analogy. I wasn't in the early days of this project so I really don't know the detals of the first decisions, but I still see that the options chosen probably made a lot of sense on that time. Maybe because the whole concept of something that is heavier than water but still floats without effort seemed to be too good to be true. Wood floats, agreed. But sorry, not without effort. Nokia has good engineers even if sometimes you disagree with their decisions. I believe they knew about the Archimedes principle when playing with wood. But you know what, good saylors of my Mediterranean town know that this perfect theoric principle doesn't work in reality (and Archimedes surely knew as well): floating wood ends up soaking and sinking if you don't put a lot of effort maintaining it. Combine this RealPhysics principle with the already commented fact that a distro is a lot more than code (i.e. the humans around it) and you find good reasons to start doing what our Nokia team ended up doing in the early days. 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. Let's keep the transport analogies. You know that warning in the aircrafts: Help yourself before attempting to help others. This is exactly our case. We still have a lot to do in order to make application and platform developers happy inside the maemo platform. We are really happy seeing that Intel, Ubuntu and others are interested in using parts of our work. We want to help them, but in order to do that we need to make sure that maemo itself is in a good position to help them. 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? Allignment and direct connection with upstream projects is probably the strongest reason nowadays. We don't say the OpenEmbedded aproach is bad: it's clear that is a good approach that works. But we can't support officially all the alternatives and one choice had to be made. I think we are currently in the right path even if we could make developers' life much easier when compiling, packaging, debugging (but this is another topic). If you disagree you can always try and support alternatives like Mamona. I do like the idea that the time I spend on maemo stuff might be usable on different platforms. I insist on this basic statement: we want people to install whatever they want in the Nokia tablets and we want people to use maemo in the way they want in non-Nokia devices. A core driver of this statement is our will to help developers developing once and targetting to different platform, getting the best result from their software and their time. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Public maemo repository (plus Intro)
Hi, I'm a Debian Developer participating in Debian GNOME packaging and interested in the packaging of maemo apps. On Fri, Jul 20, 2007, [EMAIL PROTECTED] wrote: [...] But a non-stable repository is something different: a tool for developers. [...] There must be clear reasons to do that and a crystal clear collection of needs and requirements. The first reason Nokia / Maemo might want to offer an unstable repository is quite certainly to ease developer participation. But I think there are two things which you're developing at the same time: - upstream development of some software (especially Hildon, misc N800 apps such as the embedded browser, some proprietary modules...) - the Maemo distribution(s) (its packaging, integration, themes and branding...) These are quite different and while you're doing both at the same time, one might wonder which one of these you're looking to open the development of. An unstable repository will always help open the participation in the distribution, and it might open the participation in the upstream development of the open source software you're upstream of. On the other hand, if your goal is to improve the development of the Hildon stack, then perhaps the important focus should be on moving to GNOME's hosting infrastructure. You mention a non-stable (and not unstable) repository: perhaps you already tickled the idea of having a testing-style distribution? I think this is a really great concept which makes sense in the perpetually moving software landscape: you're always receiving the latest software close to its upstream release but still after a short period where important issues can be raised -- and prevent buggy software from reaching the testing archive. If you do want to experiment with the perpetually up-to-date and almost-stable repository concept, then I do think you'll need an *unstable* repository first. [...] The maemo stack has a non-trivial size and variety of components (i.e think of the licenses and distribution rights). Releasing a stable version implies a lot of effort already. Don't think in coding only, there is a lot more. For instance, legal checks of the code that is being shipped. Moving the software integration to the public implies a deep reorganization of parts of our process and implies also more work, no matter how you look at it. Hmm I fail to see a huge difference here: instead of doing these checks at release time, you would probably do them at the time where you include software in the public repository. This is likely to spread the load over time, and I think the other distributions (at least Debian and Ubuntu) demonstrated the concept of a NEW queue [1] pretty well until now. [...] Yes, real testing has a value but we could keep handling this by releasing binaries and the relevant source code by pieces, as we have done this week with the Mozilla based browser and the RTCom update. No need to mount an entire public distro for that. Having a developer crowd get all updates all the times is very different from having to promote each individual software for each new major release. You can get pretty good bug reports -- perhaps with patches -- as the result of the combination of all new software, and some bugs might only be visible with some combinations of software or in some use cases which you might not be directly testing in your current process. While you discuss the benefits or costs of having an unstable archive with unstable software, you seem to be aware of some of the setup costs: setting up such an archive, maintaining it etc. But there's a non-technical angle that will need to be addressed as well: who do you grant access to such an archive? Will the archive only be available for Nokia folks to upload to, or will anybody be able to join a new uploaders community? How will you select people who are allowed to upload software which will be built on your build daemons and which will run on the devices of the end-users/end-developers tracking the unstable repo? IOW, are you interested in creating a new technical distribution tool fully handled by the same people currently handling Maemo, or are you interested in building a new community with its processes, rules and policies? Bye, [1] http://ftp-master.debian.org/new.html -- Loïc Minier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Public maemo repository (plus Intro)
Hi Loïc, The first reason Nokia / Maemo might want to offer an unstable repository is quite certainly to ease developer participation. But I think there are two things which you're developing at the same time: - upstream development of some software (especially Hildon, misc N800 apps such as the embedded browser, some proprietary modules...) - the Maemo distribution(s) (its packaging, integration, themes and branding...) These are quite different and while you're doing both at the same time, one might wonder which one of these you're looking to open the development of. This is a very good point, and there is not a common answer for all the packages. Something we have to clarify is the feedback and contributions expected in each component. Some potential scenarios: - Package A developed by Nokia and open source. Bugs and patches welcome. - Package B developed by Nokia and closed source. Bugs welcome. - Package C fully developed upstream and open source. Feedback and contributions to be done upstream, we inherit. - Package D fully developed by some partner and closed source. Feedback where the partner decides. - In the extras side: package E fully developed by a garage project and open source. Feedback, bugs and patches sent wherever it is agreed. if your goal is to improve the development of the Hildon stack, then perhaps the important focus should be on moving to GNOME's hosting infrastructure. Hildon has started already its upstreamization and we have a compromise to complete. This is for real and will take a while to achieve it. On top of extracting the Hildon packages from the maemo context, we have to sort out deep changes like moving to GNOME's release cycle and sharing the development with others. If we ever have a non-stable distro, Hildon will be probably treated as a pure upstream project. You mention a non-stable (and not unstable) repository: perhaps you already tickled the idea of having a testing-style distribution? I'm insisting in non-stable only because at this point there is not a clear idea whether it would be more suitable to have testing, unstable or both. How would this work in practice? Would it be more suitable to use this Debian approach or the GNOME/Ubuntu (n months to go from unstable to stable). Hmm I fail to see a huge difference here: There is. I'll try to summarize the details another day. there's a non-technical angle that will need to be addressed as well: Yes, I have insisted on the human factors of maintaining a distro and, in fact, I'm personally more concerned about them than about the code management itself. who do you grant access to such an archive? Will the archive only be available for Nokia folks to upload to, or will anybody be able to join a new uploaders community? How will you select people who are allowed to upload software which will be built on your build daemons and which will run on the devices of the end-users/end-developers tracking the unstable repo? To be defined. I wouldn't expect radical changes in terms of ownership and control of packages and commits, but there is probably room for a positive evolution. It would be useful to look in detail how other companies (Canonical, RedHat, Novell, Sun...) are dealing with this. IOW, are you interested in creating a new technical distribution tool fully handled by the same people currently handling Maemo, or are you interested in building a new community with its processes, rules and policies? Mmm probably a combination of both. Nokia needs to handle the software that is officially supporting (main restricted, so to say). The extras repository could be handled at a community level (it would be interesting to see this happening down-top). Perhaps one day the community would be in a condition of creating an own flavour totally controlled at a community level and able to run in the tablets. I don't think Nokia would object as far as the core objective is fulfilled: a more powerful IT OS preinstalled and better releases/upgrades thanks to the collaboration between Nokia - community - 3rd parties around the distro. Quim PS: I'm starting short holidays and I will be away from keyboard. I hope in the meantime the developer call gets more feedback and points of view. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Public maemo repository
Hi, But you can give users the choice to select option to install from unstable repository which may contain OS upgrade packages and this practice is ordinary. We have already announced our plans to allow updated via packages instead of having to reflash the device. This feature implies the existence of a public and stable repository at some point, and we will do it for the benefit of the users. But a non-stable repository is something different: a tool for developers. The steps for us to put this maemo unstable repository in place are not ordinary at all. Create and maintain a public repository is not an ordinary task in general. There must be clear reasons to do that and a crystal clear collection of needs and requirements. The maemo stack has a non-trivial size and variety of components (i.e think of the licenses and distribution rights). Releasing a stable version implies a lot of effort already. Don't think in coding only, there is a lot more. For instance, legal checks of the code that is being shipped. Moving the software integration to the public implies a deep reorganization of parts of our process and implies also more work, no matter how you look at it. Companies accept to handle more work if they will get more benefit from the extra work invested (in fact community developers follow this very same principle most of the times). There is a potential benefit in the fact of having a maemo unstable repository, but I don't think this benefit is based on the end users accessing and using that code. Yes, real testing has a value but we could keep handling this by releasing binaries and the relevant source code by pieces, as we have done this week with the Mozilla based browser and the RTCom update. No need to mount an entire public distro for that. This unstable repository makes sense if upstream other 3rd party developers make use of it to help us and help themselves getting better code sooner optimizing the work. It also makes sense if platform and application developers want to invest their time pushing new functionality to their components, experimenting and stabilizing having the maemo platform in mind. It makes sense if thanks to this unstable context the day we release a new IT OS version the end result is better, and that day there is also a wider collection of stable applications making the most of the new improvements, documented and ready to be installed. For instance, these days at GUADEC we are seeing how many developers are taking an N800 to experiment stuff with their own code. They are using and creating bleeding edge code, and maemo unstable would be a useful context for them to innovate. Nokia wants innovation around maemo, so there is a common interest here. It would help us a lot to know about developers explaining why they would use this maemo unstable repository, how it would benefit their work and their software. There is definitely a value in power users trying fresh code, but it is not clear the effort to launch and maintain a public distro compensates this value. The elements that make valuable an unstable repository are developer quality feedback, insightful bug reports, code contributions, better sync with upstream and, at the end, innovation at a platform and application level. This is evident for your bleeding edge desktop distro of choice. It will be great to receive specific requests and proposals of developers showing that this is an evident path for maemo as well. Share your ideas and plans if we were going to this direction. Don't save details about current problems and future opportunities. The general idea is understood. The progress comes from the level of detail we can achieve through this discussion. For instance: - Context: we need to make sure that this project is useful in the wider context. A big chunk of the maemo code comes from elsewhere. How this distro relates to i.e. Debian, GNOME Mobile and other upstream projects. How it helps developers and maintainers instead of becoming just extra work or hassle. What would you do if you were in our place? We want to be good citizens and be in good relation with our neighbors. - Real cases: Now I'm doing this but with a distro I could do that, I want to do this but currently I can't because of that, etc. - Unstable, testing or what? What is the quality and expectation? Can we have the distro broken or is it expected to build at any time? and etc Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Public maemo repository
The steps for us to put this maemo unstable repository in place are
not ordinary at all. Create and maintain a public repository is not
an ordinary task in general. There must be clear reasons to do that
and a crystal clear collection of needs and requirements.
Change means work and there needs to be a reason for it. What I find
to be usually missing is however a good justification of the status
quo.
If you abstract enough, most issues can be characterized as:
- Changing to the new thing means work and comes with risks since the
new thing is new.
- Staying with the old thing means no work and has no risks since it
is old.
The new thing is always at a disadvantage.
But, what is the new thing and what is the old thing depends very much
on what you started with. maemo _could_ have started with a public
distribution and developer support in the form of more beta releases
and could have implemented its own development processes around this.
Distributions are not a new thing at all and I would like to see the
crystal clear reasons why Nokia decided to derive from Debian sources,
including the packaging, but chose to build something out of it that
is very much unlike Debian. ('Different needs' isn't a crystal clear
reason.)
We didn't start out with a distribution and now fixing this of course
means work to implement the changes. This work is mainly caused by
missing the boat in the first place, in my opinion. The boat was
there but we decided to swim instead. Maybe because the whole concept
of something that is heavier than water but still floats without
effort seemed to be too good to be true. Arguing against boats by
saying that it is extra work to climb into them and that you'd rather
continue swimming means that you either don't understand the concept
of boats or you don't plan to go a long way.
Continuing this leaky analogy, we should all be in the same boat of
course.
The work needed to maintain a distribution is not needed because you
maintain a distribution. You will need to do the work anyway, and a
distribution is a good tool to reduce gratuitous work. (Work here
includes things like integrating components to work well together,
managing API compatibility issues, defining supported configurations,
and providing smooth upgrades.)
A distribution is a organizational tool. It significantly amplifies
synergistic effects since people will tend to work in the same
environment and can see and fix integration bugs in a coordinated way.
The thing that a distribution gives you is to be able to say for each
package whether it is 'in' or 'out'. We could make the following
list:
http://catalogue.tableteer.nokia.com/certified $DIST user
http://catalogue.tableteer.nokia.com/non-certified $DIST user
http://repository.maemo.org$DIST free non-free
http://repository.maemo.org/extras $DIST free non-free
That could be your maemo distribution right there, as a starting
point. All packages in those repositories are 'in', the rest is
'out'. It could really be as simple as that.
Looking at recent events, this particular but rather obvious way to
define the distribution would mean that the browser beta is in the
distribution, but neither the SIP beta nor the OpenedHand stuff are.
It is by pure chance that the SIP and OpenedHand packages have subtle
conflicts, and the browser stuff just works, but the distribution
gives you a good idea about what to do next: pull both the SIP and
OpenedHand stuff into the distribution.
The repository layout above is not particularily elegant, and it might
not be totally clear what the requirements are for the distribution
(i.e., should you be able to follow changes to it via apt-get, who is
supposed to be able to actually change it, how do we protect Joe
Couchclick from beta releases?), but it's a starting point and it is
important to have such a starting point so that discussions can
crystallize around something concrete and we don't need to talk so
much in the abstract. Being concrete helps to understand how much
work you are actually talking about.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Public maemo repository
We didn't start out with a distribution and now fixing this of course means work to implement the changes. This work is mainly caused by missing the boat in the first place, in my opinion. The boat was there but we decided to swim instead. Maybe because the whole concept of something that is heavier than water but still floats without effort seemed to be too good to be true. Arguing against boats by saying that it is extra work to climb into them and that you'd rather continue swimming means that you either don't understand the concept of boats or you don't plan to go a long way. Hello Marius I like the boat analogy very much :p 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. 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. Anyway i wonder what part of maemo is to be attractive if the hildon development goes outdoors. 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 do like the idea that the time I spend on maemo stuff might be usable on different platforms. greetings ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
