[IAEP] [Sugar-devel] activites known not to either work at all or not on certin platforms

[Luke Faraone]

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[1] together a sugar
>>> activity package until a Debian package can be adopted. More info at
>>> https://wiki.ubuntu.com/SugarTeam
>>>
>>> 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
>>git-based packaging;
>
> 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:
> http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2008-April/000084.html
>
> 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
> work.
>
>
>>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
>>produce one,
>
> 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:
> http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2008-December/000681.html
> http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2009-January/000885.html
> http://lists.alioth.debian.org/pipermail/debian-olpc-devel/2009-February/000894.html
>
>
>>but as it stands the build and import process is undocumented.
>
> Bullshit!
>
> 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.

--
Luke Faraone
http://luke.faraone.cc