Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
What music applications would you be sharing? -nick Jay Vaughan wrote: I thought the Openmoko developer community would want to better than that ... Whats missing IMHO is a Repository Leadership clique, wherein a known group of people are responsible for some nice repositories that end-users might find interesting .. If I could easily add a few sites to my Freerunner, I would. And I'd watch them for regular updates too. For example, I'm considering firing up an Openmoko repository - known and public - for music apps for the OpenMoko suite .. ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Rod Whitby wrote: | And therein starts the decline of Openmoko application availability into | the poor practices of the windows world ... | | ;-) It's really two different usage scenarios: one is the nice and tidy | distribution, the other is getting something to build and, sometimes, | to disseminate it quickly. | | While there are people who indeed have the angelic patience to work in | distribution mode all the time, for most of us, this is just too much | pain and overhead. (Hi Andy ;-) Hi yourself... I guess you must have started using Openmoko build system then because last time we spoke about it you were avoiding it same as me - -- for the same reasons. | Also, having a toolchain that makes it easy to cross-build from sources | will help a lot towards people not even wanting to download pre-built | binaries. This is completely backwards. I know you run Gentoo so maybe the insanity is normal for you, but if someone painstakingly equipped their box to build death-foo-libs package that has crazy build dependencies on automake 0.1 and emacs 0.01, and kindly packaged and made available the binary, why on earth should you ignore that and go through agonies setting up your box to regenerate exactly the same bits? They even give you a -dev package, after YOU compiled the thing there is NOTHING additional over just using the packages. Except what, a chunk of your life evaporated while you stared at things scrolling. What you should have said is: ''Also, having a toolchain that makes it easy to cross-build from PACKAGES will help a lot towards people not even wanting to BUILD STUFF THAT IS ALREADY BUILT AND USABLE.'' - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhGOH8ACgkQOjLpvpq7dMpdEwCglPhYYa6ZK7zIR7GdKtXp3qpc zzwAn3JcIXJJj/SU8hcO/8U8cVfIzAhR =TJSV -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | in a main repository? In Fedora, the multitude of repositories for | downloading packages has caused nightmares of dependency hell when | users install from two or more repos that carry some of the same package. | | The most user-friendly solution is one location that holds all the apps | a user could want, one place for them to look, one place to maintain. | Branching repositories should be avoided as much as possible. | | Submitting packages to OE is like contributing upstream. It makes the | most out of your contribution. Yeah I know what you are talking about exactly. In fact it is OK if apps are in multiple repos so long as they are linked entirely against canonical dependent packages from central distribution. The damage came when you had say mplayer from freshrpms and livna that each required and imported say faad from their respective repositories. Then if you wanted xine from a different place you got mplayer, the Hell appeared because faad dependency in xine could either be satisfied by the foreign package of different patchlevel than the one from the same place as the Xine, or worse could not be satisfied due to use of = version dependency when the two repos' faad were at different versions. Of course it becomes political then what gets into the central distribution with what config options, as happened with Fedora rafts of dependent packages were landgrabbed into Extras as the de-facto canonical source of them and the independent guys felt treated badly about having that taken away from them rather brusquely. In addition people were and still are grumpy about the pretty intense packaging rules and bureaucracy surrounding submission of packages and approval, although since as a Fedora user I benefit from the high level of engineering and consistency I find it hard to argue against it. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhGOuwACgkQOjLpvpq7dMq2GQCeI9+3ZV3kn5nrmwDaHKJi4gG0 cM8Anj0U1lFpaM32+W4UuJLcM30kONzI =1GZi -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
Andy Green wrote: Hi yourself... I guess you must have started using Openmoko build system then because last time we spoke about it you were avoiding it same as me - -- for the same reasons. I think you misunderstood me there - I wasn't referring to myself when I mentioned the angelic patience :-) (*) For me, bitbake is a great tool for distribution makers. I say that it's a great tool for them because they seem to be happy with it. When they're happy and make happy little pre-compiled packages for me, I'm happy as well. And I'm even happier if I never ever have to touch bitbake ;-) (*) If you must know, I was thinking of Raster. Although the deprecations he uttered on IRC while struggling to use bitbake as a twisted substitute for make seemed somewhat less angelic (-:C What you should have said is: ''Also, having a toolchain that makes it easy to cross-build from PACKAGES will help a lot towards people not even wanting to BUILD STUFF THAT IS ALREADY BUILT AND USABLE.'' What I mean is that, with a good and extensible toolchain, you can pick some Openmoko-agnostic package and build it from sources without pain. Yes, if the package has already been properly openembeddified and is part of someone's build process, sure, you can just grab the binary. But often enough, you'll find that this hasn't happened yet, and you probably want to try it out before lobbying its addition to the daily build. Similarly, if it's work in progress, you often don't want to wait for the daily build. And neither do you want to run your own OE build just to get that package (unless you're blessed with the aforementioned angelic patience). - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Andy Green wrote: | Hi yourself... I guess you must have started using Openmoko build system | then because last time we spoke about it you were avoiding it same as me | - -- for the same reasons. | | I think you misunderstood me there - I wasn't referring to myself when | I mentioned the angelic patience :-) (*) OK then :-) just people might have gotten the wrong idea :-) | For me, bitbake is a great tool for distribution makers. I say that it's | a great tool for them because they seem to be happy with it. When they're | happy and make happy little pre-compiled packages for me, I'm happy as | well. And I'm even happier if I never ever have to touch bitbake ;-) | | (*) If you must know, I was thinking of Raster. Although the deprecations | he uttered on IRC while struggling to use bitbake as a twisted | substitute for make seemed somewhat less angelic (-:C Yeah I saw him myself fidgiting and complaining through endless rebuilds to pointlessly regenerate for himself what was already sitting in a package in the OM repo. | What you should have said is: ''Also, having a toolchain that makes it | easy to cross-build from PACKAGES will help a lot towards people not | even wanting to BUILD STUFF THAT IS ALREADY BUILT AND USABLE.'' ... | Yes, if the package has already been properly openembeddified and is | part of someone's build process, sure, you can just grab the binary. | But often enough, you'll find that this hasn't happened yet, and you | probably want to try it out before lobbying its addition to the | daily build. Even if you build something weird it would just mean you should package your dependent stuff in OE package first, and then install it into the package-based toolchain the same using your local packages so you can link against it. It's no different with any packaging system like RPM: if you planned on passing this new package around, you had to package the dependencies anyway. Packaged-based toolchain is then a complete stand alone solution for normal devs. For the people who build the packages in the main repo from scratch and do have to have a complete set of build dependencies on their build box, this bitbake or mokomakefile stuff that wants to build an entire subdistro on their host is actually useful. But how many people need to drink that bleach? Three? Everyone else can have a happy life building package-based. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhGUOEACgkQOjLpvpq7dMqzYwCeOND0JKcaLwEpWTa/V/4lVfbM o3EAniqRSTvEJfw7UQPC+nCsBa3q1XpY =fZ76 -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
On Fri, May 30, 2008 at 4:38 AM, Jay Vaughan [EMAIL PROTECTED] wrote: I thought the Openmoko developer community would want to better than that ... Whats missing IMHO is a Repository Leadership clique, wherein a known group of people are responsible for some nice repositories that end-users might find interesting .. If I could easily add a few sites to my Freerunner, I would. And I'd watch them for regular updates too. For example, I'm considering firing up an Openmoko repository - known and public - for music apps for the OpenMoko suite .. But why do you want to promote these separate channels and avenues for obtaining software? Wouldn't it be better to include these music apps in a main repository? In Fedora, the multitude of repositories for downloading packages has caused nightmares of dependency hell when users install from two or more repos that carry some of the same package. The most user-friendly solution is one location that holds all the apps a user could want, one place for them to look, one place to maintain. Branching repositories should be avoided as much as possible. Submitting packages to OE is like contributing upstream. It makes the most out of your contribution. -- Type faster. Use Dvorak: http://dvzine.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
On 5/29/08, Rod Whitby [EMAIL PROTECTED] wrote: Pranav Desai wrote: On Wed, May 28, 2008 at 5:49 PM, Rod Whitby [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The usual way is to add the package to OpenEmbedded, and then add it's name to the task-openmoko-feed.bb http://task-openmoko-feed.bb recipe so that it automatically gets built, packaged and deployed to the official download site. But wouldn't that mean writing a recipe for all packages that we want to add? That is correct. Many third party apps already have a makefile setup, why do you want to change that ? Writing a recipe does not involve changing the existing Makefile. If the existing Makefile is written properly, then the recipe should be about 5 lines long. But the major reason to do this is the one I gave below, which you didn't comment on. Security and trust of third-party apps should be a very significant consideration for the Openmoko community. Also, I am much more likely to trust a package recipe that I can build and install myself using OpenEmbedded (or download from an official site where the package has been built from source by a trusted autobuild system), rather than downloading some unknown, possibly virus-tainted binary package from some random site ... I agree with that issue, but that choice should be left to the user, if they don't feel comfortable downloading a binary pkg, they are more than welcome to get the src and build it themselves. My attempt is to make existing opensource apps available for Openmoko. If I have rewrite or wrap around the existing build process just to fit the OE model then it seems a bit discouraging. Maybe its trivial to include apps into OE, but currently it seems more than that to me. And especially, with the toolchain out, it seems even more easier to build apps as-is and just putting out the binaries for people to use. -- Pranav -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
Pranav Desai wrote: My attempt is to make existing opensource apps available for Openmoko. If I have rewrite or wrap around the existing build process just to fit the OE model then it seems a bit discouraging. Contrast this with Debian, Ubuntu, Gentoo, etc ... you're effectively saying that Debian repositories with GPG signed packages are not required - you are saying that people should just download random binaries from random sites and take the consequences, or they should be smart enough to build the packages themselves. Maybe its trivial to include apps into OE, but currently it seems more than that to me. And especially, with the toolchain out, it seems even more easier to build apps as-is and just putting out the binaries for people to use. And therein starts the decline of Openmoko application availability into the poor practices of the windows world ... encouraging people to download and install binary applications with no means of determining exactly how they were built (and therefore not able to verify that something bad hasn't been included in them). I thought the Openmoko developer community would want to better than that ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
Hello, Having an official packages repository is excellent. It is not enough though: openness to external contributions, possible reactivity are welcomed too, otherwise the repository would tend to a sanctuary. Gilles ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | Pranav Desai wrote: | On Wed, May 28, 2008 at 5:49 PM, Rod Whitby [EMAIL PROTECTED] | mailto:[EMAIL PROTECTED] wrote: | The usual way is to add the package to OpenEmbedded, and then add | it's name to the task-openmoko-feed.bb | http://task-openmoko-feed.bb recipe so that it automatically gets | built, packaged and deployed to the official download site. | | But wouldn't that mean writing a recipe for all packages that we want | to add? | | That is correct. | | Many third party apps already have a makefile setup, why do you want | to change that ? | | Writing a recipe does not involve changing the existing Makefile. If the | existing Makefile is written properly, then the recipe should be about 5 | lines long. | | But the major reason to do this is the one I gave below, which you | didn't comment on. Security and trust of third-party apps should be a | very significant consideration for the Openmoko community. Hey allow me to comment on it. Openmoko doesn't break new ground in having a distro, most of the issues furrowing brows here were solved long ago in proper distros (and, if we directly used a proper distro in the future, these issues would just magically work, but that's a flamewar for another time). Looking at Fedora, the solution is not to have a single point of fai- I mean distribution and claim that this is especially secure, the solution is to crypto-sign the packages and have the public key on the clients. This is a very strong assertion you can trust -- no matter how you came by the package -- that the holder of the private key authorized the package build. And indeed with that, Fedora gets to use a system of mirror repos that are completely out of their control to distribute their packages, but it is perefctly safe due to enforcement of sig checking at the client. Nor does it limit us to only having safe packages from Mr Openmoko, if we decide we want Pranav's packages we install his public key too and we can safely eat packages from Pranav even if we found them on Usenet or lying around on the street. Anyone faking or meddling with Openmoko or Pranav packages is SOL when we try to install them it is rejected with package payload differs from signature or missing signature, etc. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkg/yesACgkQOjLpvpq7dMpbEwCfbQdRVlXz5rvg4ByJx2/lxb3S rKgAn1Vw6kFbEGhdBAqJ4+FlLTlZ2vMA =4RrR -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
I thought the Openmoko developer community would want to better than that ... Whats missing IMHO is a Repository Leadership clique, wherein a known group of people are responsible for some nice repositories that end-users might find interesting .. If I could easily add a few sites to my Freerunner, I would. And I'd watch them for regular updates too. For example, I'm considering firing up an Openmoko repository - known and public - for music apps for the OpenMoko suite .. ; -- Jay Vaughan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
How about a system like launchpad's PPA (Personal Package Archive) which allows developers to have their packages built automatically for all versions of ubuntu. This could have access to all of the libraries available through OE and any that you build your self - avoiding dependency problems in the toolchain and allowing users to get hold of the packages once built. solar.george ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
On Wed, May 28, 2008 at 5:49 PM, Rod Whitby [EMAIL PROTECTED] wrote: Pranav Desai wrote: But that brings another question (which probably needs another thread), where do we store/host the ported apps if we have some? * Can we put it somewhere on downloads.openmoko.org http://downloads.openmoko.org * Should we create another project on project.openmoko.org http://project.openmoko.org. * Or do we put the responsibility on whoever ported it, to host the app. The usual way is to add the package to OpenEmbedded, and then add it's name to the task-openmoko-feed.bb recipe so that it automatically gets built, packaged and deployed to the official download site. But wouldn't that mean writing a recipe for all packages that we want to add? Many third party apps already have a makefile setup, why do you want to change that ? Especially, if they can be build easily enough with the toolchain. Packaging and publishing random applications here, there and everywhere is just going to fragment the set of applications available to users. Thats not going to stop anyway, but if we have a central place where people can put their packages, maybe it can be reduced. Also, I am much more likely to trust a package recipe that I can build and install myself using OpenEmbedded (or download from an official site where the package has been built from source by a trusted autobuild system), rather than downloading some unknown, possibly virus-tainted binary package from some random site ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
Pranav Desai wrote: On Wed, May 28, 2008 at 5:49 PM, Rod Whitby [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: The usual way is to add the package to OpenEmbedded, and then add it's name to the task-openmoko-feed.bb http://task-openmoko-feed.bb recipe so that it automatically gets built, packaged and deployed to the official download site. But wouldn't that mean writing a recipe for all packages that we want to add? That is correct. Many third party apps already have a makefile setup, why do you want to change that ? Writing a recipe does not involve changing the existing Makefile. If the existing Makefile is written properly, then the recipe should be about 5 lines long. But the major reason to do this is the one I gave below, which you didn't comment on. Security and trust of third-party apps should be a very significant consideration for the Openmoko community. Also, I am much more likely to trust a package recipe that I can build and install myself using OpenEmbedded (or download from an official site where the package has been built from source by a trusted autobuild system), rather than downloading some unknown, possibly virus-tainted binary package from some random site ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Packaging third-party applications (Was: Meta Toolchain Release (2008 May))
Pranav Desai wrote: But that brings another question (which probably needs another thread), where do we store/host the ported apps if we have some? * Can we put it somewhere on downloads.openmoko.org http://downloads.openmoko.org * Should we create another project on project.openmoko.org http://project.openmoko.org. * Or do we put the responsibility on whoever ported it, to host the app. The usual way is to add the package to OpenEmbedded, and then add it's name to the task-openmoko-feed.bb recipe so that it automatically gets built, packaged and deployed to the official download site. Packaging and publishing random applications here, there and everywhere is just going to fragment the set of applications available to users. Also, I am much more likely to trust a package recipe that I can build and install myself using OpenEmbedded (or download from an official site where the package has been built from source by a trusted autobuild system), rather than downloading some unknown, possibly virus-tainted binary package from some random site ... -- Rod ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
