From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gnap-dev+bounces-87-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1JeVX7-0003OZ-77
for garchives@archives.gentoo.org; Wed, 26 Mar 2008 13:19:13 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 5456CE062B;
Wed, 26 Mar 2008 13:19:12 +0000 (UTC)
Received: from outbound-mail-123.bluehost.com (outbound-mail-123.bluehost.com [67.222.38.23])
by pigeon.gentoo.org (Postfix) with SMTP id 1DBD8E062B
for <gnap-dev@lists.gentoo.org>; Wed, 26 Mar 2008 13:19:12 +0000 (UTC)
Received: (qmail 12419 invoked by uid 0); 26 Mar 2008 13:19:09 -0000
Received: from unknown (HELO box246.bluehost.com) (69.89.27.246)
by outboundproxy4.bluehost.com with SMTP; 26 Mar 2008 13:19:09 -0000
Received: from 161.168.217.87.dynamic.jazztel.es ([87.217.168.161] helo=[192.168.100.61])
by box246.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256)
(Exim 4.68)
(envelope-from <bass@gentoo.org>)
id 1JeVX0-0000kk-Je
for gnap-dev@lists.gentoo.org; Wed, 26 Mar 2008 07:19:09 -0600
Subject: Re: [gnap-dev] [RFC] Summer of Code Proposal: GNAP Love
From: =?ISO-8859-1?Q?jos=E9?= Alberto =?ISO-8859-1?Q?Su=E1rez_L=F3pez?= <bass@gentoo.org>
To: gnap-dev@lists.gentoo.org
In-Reply-To: <1206536227.3183.71.camel@troy.riegger.name>
References: <1206536227.3183.71.camel@troy.riegger.name>
Content-Type: text/plain; charset=utf-8
Date: Wed, 26 Mar 2008 14:19:03 +0100
Message-Id: <1206537543.15053.9.camel@supercoco>
Precedence: bulk
List-Post: <mailto:gnap-dev@lists.gentoo.org>
List-Help: <mailto:gnap-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gnap-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gnap-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo GNAP development <gnap-dev.gentoo.org>
X-BeenThere: gnap-dev@lists.gentoo.org
Reply-to: gnap-dev@lists.gentoo.org
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3
Content-Transfer-Encoding: quoted-printable
X-Identified-User: {:box246.bluehost.com:jasuarez%eneotecnologia.com:} {sentby:smtp auth 87.217.168.161 authed with jasuarez%eneotecnologia.com}
X-Archives-Salt: bddd84fb-1cee-4c98-b349-a7ec6916205d
X-Archives-Hash: 01d6ef92bb66927018b4131462808391
hi :)
as we talked before...
El mi=C3=A9, 26-03-2008 a las 13:57 +0100, Philipp Riegger escribi=C3=B3:
> Good morning,
>=20
> I have some ideas for Summer of Code which i'd like to discuss with you.
new ideas ever welcome
> I'm mostly interested in making GNAP usable and my proposal includes
> lots of tasks in GNAP and catalyst, of which i'd like to finish as many
> as possible and do some research on the rest.
>=20
> catalyst tasks:
>=20
> =E2=80=A2 Squashfs snapshot support
> I don't like it, that it takes so much time to unpack a new snapshot and
> it takes so much disk space to store it. Plan is: distribute tree
> snapshots as squashfs images, mount them directly into the workdir,
> use /mnt/distfiles and /mnt/packages instead of snapshot subdirectories.
i like this can be usefull, the problem is how mcuh espace you need to
redistribute all sources we need (not only gnap-core srcs, i mean
extensions srcs too)
> =E2=80=A2 (Squashfs seedstage support)
> Maybe the same is possible for stages? A future plan for this could be
> to mount the squashfs image directly and use unionfs for the real work,
> but i have no idea how deleting files in such a setup works. Research is
> necessary here.
i dont understand it well
> =E2=80=A2 uclibc-cross-compiling support
> Cross compiling is hard, but it should be possible to build arch-uclibc
> from arch. Research, what needs to be done combined with the
> implementation, if possible. This would also make GNAP more flexible.
this will be one of the biggest features so as you know is hard.
> =E2=80=A2 Documentation
> In an email from some days ago i read, that documentation is planed for
> after the release. I could support this and proofread it, since i need
> the knowledge anyway.
you mean gnap doc or catalyst doc?
> =E2=80=A2 (Code cleanups)
> I write this everywhere, but since i need a basic understanding, i have
> to read (parts of) the source and maybe i find something worth
> improving.
ever welcome :)
> =E2=80=A2 Cross compiling research
> This is the continuation of the uclibc stuff with some plans on what
> could be done how.
>=20
> =E2=80=A2 Non-root builds research
> Wouldn't it be nice if being root was not necessary for using catalyst?
> I would like to look into the possibilities there and what is needed to
> make it reality.
i think that is hard, you dont need root only for catalyst, other GNAP
operations need to be root.
> GNAP tasks:
>=20
> =E2=80=A2 Code/Tree hosting, VCS
> I've done some work last year and that does only exist as some patches,
> since there is no central repository for GNAP development. First i'd
> like to establish one and move all existing resources there.
yes, what about your google-code testing?
> =E2=80=A2 GNAP 2.1
> There are some known and easy to fix bugs in GNAP 2.0. There have also
> been some code cleanups. The last thing is, that the current GNAP is not
> really usable, since the tree snapshot is so old, that most of the
> distfiles are not fetchable from mirrors or other places. So i'd like to
> make a new release, be it in the tree or in an overlay.
you are right, but first we need and updated tree
> =E2=80=A2 Reimplementation in python research
> Catalyst is written in python, maybe we could make better use of it if
> we reimplemented some parts of GNAP in python? This is just a research
> item, i'd like to look into it and form some statement about it. I'll
> probably not do it.
i prefer to keep bash
> =E2=80=A2 uclibc-cross-compiling support
> This depends on catalyst.
>=20
> =E2=80=A2 (Cross-compiling support)
> My last years project. My thoughts/plans about that should be discussed
> with the community and put on the GNAP development website.
>=20
> =E2=80=A2 GNAP releases, long term support
> This is just an idea i have. Think of something like this: With each
> gentoo release, we take the release snapshot, form our reduced GNAP
> snapshot (only supported profiles, unsupported USE flags masked,
> unneeded ebuilds (X, desktop stuff) not in the tree) and support it for
> some time security wise (like the releng team does during release). This
> is more of a research topic, with informing what needs to be done,
> writing of scripts, maybe doing a proof of concept (maintaining a
> snapshot for some weeks to see how it works).
--
gnap-dev@lists.gentoo.org mailing list