On Mon, Dec 8, 2008 at 9:31 PM, Martin Langhoff
<[EMAIL PROTECTED]> wrote:
> On Mon, Dec 8, 2008 at 1:50 PM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote:
>> Does that work ?
>
> How do we trust that the setup.py is not malicious? Part of what I am
> suggesting when I talk about rpm files that have
On Mon, Dec 8, 2008 at 1:50 PM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote:
> Does that work ?
How do we trust that the setup.py is not malicious? Part of what I am
suggesting when I talk about rpm files that have no %post/%pre etc
(and therefore can be installed with --no-scripts) is that we ca
On Thu, Dec 4, 2008 at 5:10 PM, Martin Langhoff
<[EMAIL PROTECTED]> wrote:
> On Tue, Dec 2, 2008 at 8:33 PM, Martin Langhoff
> <[EMAIL PROTECTED]> wrote:
>> What I meant to say is that all the good things we get from a bespoke
>> packaging format, we can get from rpm with a few conventions as to th
Martin Langhoff wrote:
> Using rpm or apt Sugar would getting a bit further away from Windows
> (does cygwin carry either?) - a bit less so on OSX (where the fink
> toolchain will probably work alright, specially with translation pkgs,
> which are by definition "noarch").
>
I don't think that t
On Fri, Dec 5, 2008 at 7:56 PM, Alexander Dupuy <[EMAIL PROTECTED]> wrote:
> via fink, but it's worth remembering that translation packages are not 'by
> definition "noarch"' - if the packages contain compiled gettext .mo files,
> those files may be machine-specific. As noted in
> http://www.gnu.o
On Tue, Dec 2, 2008 at 8:33 PM, Martin Langhoff
<[EMAIL PROTECTED]> wrote:
> What I meant to say is that all the good things we get from a bespoke
> packaging format, we can get from rpm with a few conventions as to the
> directories where things land.
A couple of additional notes from a private s
I must admit, I don't really understand this proposal; and I want to,
because it raises important issues for activity signing. Sayamindu, can you
explain the options as you see them:
-in very general terms, what is the ui ("control panel" is enough on this
point)
-what code is activated by this ui
On Wed, Dec 3, 2008 at 3:47 AM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:
> Re: Scratch & etoys: the problem with updating translations "in
> place" is that it doesn't support distributed work on translations:
> OLPC might do basic translations; they might be further developed in a
> country or
On Tue, Dec 2, 2008 at 7:34 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:
> Please re-read Sayamindu's original message. Thanks.
I don't find anything too special there. Perhaps I wasn't clear earlier.
What I meant to say is that all the good things we get from a bespoke
packaging format, we c
On Tue, Dec 2, 2008 at 4:26 PM, Martin Langhoff
<[EMAIL PROTECTED]> wrote:
> On Tue, Dec 2, 2008 at 6:49 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:
>> Fedora does not have a standard solution either, so I'm not sure
>> where you're going with this. We have to invent something. RPM is
>> not
On Tue, Dec 2, 2008 at 6:49 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:
> Fedora does not have a standard solution either, so I'm not sure
> where you're going with this. We have to invent something. RPM is
> not obviously the right solution.
So Fedora doesn't use rpm files for localization
On Tue, Dec 2, 2008 at 2:26 PM, Martin Langhoff
<[EMAIL PROTECTED]> wrote:
> On Thu, Nov 13, 2008 at 6:58 PM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote:
>> I have been thinking of having a separate place in the filesystem for
>> _new_ translations, and using RPM to manage the installation and
>>
On Thu, Nov 13, 2008 at 6:58 PM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote:
> I have been thinking of having a separate place in the filesystem for
> _new_ translations, and using RPM to manage the installation and
> upgradation of the new translations.
What is the downside of RPMs? If users ed
Re: Scratch & etoys: the problem with updating translations "in
place" is that it doesn't support distributed work on translations:
OLPC might do basic translations; they might be further developed in a
country or region, etc. Each might be updated individually.
Further, you want to be able to b
Hello.
On Fri, Nov 14, 2008 at 5:58 AM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote:
> Hello,
> One of the things in my TODO for 9.1 is to have a better mechanism for
> language packs[1] in the XO. The primary goal of language packs is to
> decouple the process of translations from the process of
It doesn't sound too invasive of a change and yet it is in keeping
with the basic update system and may evolve into a simpler framework
for end users to contribute translations as well.
-walter
On Thu, Nov 13, 2008 at 3:58 PM, Sayamindu Dasgupta <[EMAIL PROTECTED]> wrote:
> Hello,
> One of the th
Hello,
One of the things in my TODO for 9.1 is to have a better mechanism for
language packs[1] in the XO. The primary goal of language packs is to
decouple the process of translations from the process of OS release as
much as possible, since as our software gets larger and more
complicated, it wil
17 matches
Mail list logo
