Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))

[Andy Green]

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

[Werner Almesberger]

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

[Andy Green]

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

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

[nickd]

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

[Dylan Semler]

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

[Rod Whitby]

Werner Almesberger wrote:
> 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.

Fully agree.  The problem occurs when the "quick and dirty" 
dissemination to other developers and alpha testers evolves into being 
the main end-user distribution channel.  The quick and dirty will happen 
by default, so someone needs to continue to push towards the "nice and 
tidy distribution" if it's to happen at all and not degenerate into chaos.

> 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 ;-)
 >
> 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.

Fully agree.

There will also be people (including resellers of application specific 
turnkey solutions involving openmoko hardware) who will want to select a 
set of applications for a custom rootfs build.

If application developers want their software to ever be part of a 
custom installation, or to even be part of the standard factory build 
that openmoko installs, then it's in their interest to learn how to 
package their software in the official distribution system ...

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

[Werner Almesberger]

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

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.

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

[George Brooke]

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

[Jay Vaughan]

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

[Andy Green]

-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]
|> > wrote:
|> 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?
|
| 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))

[Gilles Casse]

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

[Rod Whitby]

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

[Pranav Desai]

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]
>> > wrote:
>> 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?
>
> 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))

[Rod Whitby]

Pranav Desai wrote:
On Wed, May 28, 2008 at 5:49 PM, Rod Whitby <[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
 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

Re: Packaging third-party applications (Was: Meta Toolchain Release (2008 May))

[Pranav Desai]

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

Packaging third-party applications (Was: Meta Toolchain Release (2008 May))

[Rod Whitby]

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 

* Should we create another project on 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