[IAEP] [Sugar-devel] activites known not to either work at all or not on certin platforms
luke at faraone.cc
Wed Feb 11 13:38:27 EST 2009
On 2/11/09, Jonas Smedegaard <dr at jones.dk> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On Wed, Feb 11, 2009 at 11:24:20AM -0500, Luke Faraone wrote:
>>On Wed, Feb 11, 2009 at 10:49 AM, Jonas Smedegaard <dr at jones.dk> wrote:
>>> Debian POV: Someone needs to volunteer packaging
>>> "sugar-etoys-activity". Drop an email to
>>> debian-olpc-devel at lists.alioth.debian.org .
>>> Ubuntu POV: Someone needs to volunteer hacking together a sugar
>>> activity package until a Debian package can be adopted. More info at
>>> I recommend helping as "upstream" as possible instead of only locally
>>> for Ubuntu. YMMV.
>>Yes, but our "hacks" are the result of a lack of understanding of your
> That is one way to put it.
> Another is that you have had no interest in starting out with simple
> stuff before complex stuff. I kept recommending you to try package an
> activity with no odd dependencies (i.e. written in Python), but you kept
> wanting to upgrade core Sugar libraries.
> You do not even need to use my packaging style. Just do not expect my
> help, then. Discuss it with other members of the OLPC Alioth list, with
> debian-mentors or whatever.
> All I say here is to avoid duplicate work: Package for Debian and pull
> that into derivatives, rather than packaging uniquely for each pet
> derived distro.
>>It's interesting that Ubuntu had *working* sugar packages with *more*
>>working activities six months ago. This is no longer the case, as we've
>>synced to Debian packaging (which had some show-stopper bugs that
>>required us to patch *each* activity you/we were shipping).
> Blame yourself for abandoning superior(?) packaging! My reasons for
> different packaging style than older work by Jani Monoses is here:
> Blame yourself for needing distro-specific workarounds: They are caused
> by your "running ahead" of Debian and then later wanting to adopt Debian
> packaging that when in slightly different direction than your earlier
>>If you'd support a sugar-whatever-activity package that didn't use
>>git-buildpackage or the multi-branch/tree workflow, I'd be happy to
> If you by "you" are referring to Debian, then sure, Debian supports
> other packaging styles.
> If you are referring to me personally, then no, I see no reason to
> support any other packaging styles than I want to use myself.
> If you are referring to the Alioth team, then feel free to use other
> schemes. I am not the law. Heck, I am not even an admin of that group. I
> just happen to actually get some work done.
> Your freedom to choose packaging style should come as no surprise:
>>but as it stands the build and import process is undocumented.
> Complex parts, irrelevant for activity packaging, is missing.
> So stop whining and start packaging some simple Sugar activities.
Maybe we're just thick, but neither Morgan nor I were able to use your
git README.packaging to upgrade a package to a new upstream version.
It doesn't matter wheter we were upgrading sugar-base or Pippy.
It seems that the file is missing some steps; moreover, how can we be
expected to package new activities with git when even the steps for
maintaining existing ones are lacking.
More information about the IAEP