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 ) id 1JeVx0-0005Td-Pt for garchives@archives.gentoo.org; Wed, 26 Mar 2008 13:45:59 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 16F49E098F; Wed, 26 Mar 2008 13:45:58 +0000 (UTC) Received: from mailstore.bawue.net (mailstore.bawue.net [193.7.176.63]) by pigeon.gentoo.org (Postfix) with ESMTP id 794F4E098F for ; Wed, 26 Mar 2008 13:45:57 +0000 (UTC) Received: from [192.168.0.6] (p57B4E32C.dip.t-dialin.net [87.180.227.44]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailstore.bawue.net (Postfix) with ESMTP id 0AF5738E96 for ; Wed, 26 Mar 2008 14:45:55 +0100 (CET) Subject: Re: [gnap-dev] [RFC] Summer of Code Proposal: GNAP Love From: Philipp Riegger To: gnap-dev@lists.gentoo.org In-Reply-To: <1206537543.15053.9.camel@supercoco> References: <1206536227.3183.71.camel@troy.riegger.name> <1206537543.15053.9.camel@supercoco> Content-Type: text/plain; charset=UTF-8 Date: Wed, 26 Mar 2008 14:45:51 +0100 Message-Id: <1206539151.3183.83.camel@troy.riegger.name> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo GNAP development 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-Archives-Salt: 13c9fa1b-4e16-43a5-865d-d294eeef5436 X-Archives-Hash: 93f5baefdbc32df4c407c034d19038b5 On Wed, 2008-03-26 at 14:19 +0100, jos=C3=A9 Alberto Su=C3=A1rez L=C3=B3p= ez wrote: > El mi=C3=A9, 26-03-2008 a las 13:57 +0100, Philipp Riegger escribi=C3=B3= : > > 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 ma= ny > > 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 subdirectori= es. >=20 > 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) This is all about catalyst. Catalyst takes a tree snapshot (/usr/portage as .tar.bz2), unpacks it somewhere and bind mounts it to its workdir. I'd like to get rid of this step, since it takes lots of time and wastes lots of disk space. I'm interested, what catalyst devs will say about it. > > =E2=80=A2 (Squashfs seedstage support) > > Maybe the same is possible for stages? A future plan for this could b= e > > to mount the squashfs image directly and use unionfs for the real wor= k, > > but i have no idea how deleting files in such a setup works. Research= is > > necessary here. >=20 > i dont understand it well Same as above. Has nothing to do with GNAP, only catalyst. Imagine you want to build a stage2. You rsync stage1 to a workdir and build stage2 there. Therefore you have to unpack the stage1 somewhere and store it there. I want to get rid of this. > > =E2=80=A2 uclibc-cross-compiling support > > Cross compiling is hard, but it should be possible to build arch-ucli= bc > > from arch. Research, what needs to be done combined with the > > implementation, if possible. This would also make GNAP more flexible. >=20 > this will be one of the biggest features so as you know is hard. I know, but i already know where to start, since i alredy got in touch with it last year. I just don't know, how many other problems there will be on the way. > > =E2=80=A2 Documentation > > In an email from some days ago i read, that documentation is planed f= or > > after the release. I could support this and proofread it, since i nee= d > > the knowledge anyway. >=20 > you mean gnap doc or catalyst doc? Catalyst, actually, but this could be extended to both. > > =E2=80=A2 Cross compiling research > > =E2=80=A2 Non-root builds research >=20 > i think that is hard, you dont need root only for catalyst, other GNAP > operations need to be root. Why, exactly? There are reasons like "mounting stuff", "creating /dev files" and others, but maybe we can do that without 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 patche= s, > > since there is no central repository for GNAP development. First i'd > > like to establish one and move all existing resources there. >=20 > yes, what about your google-code testing? I did not look into it, yet. If i slend half the week, testing it, i don't have an application for SoC. :-) > > =E2=80=A2 GNAP 2.1 > > There are some known and easy to fix bugs in GNAP 2.0. There have als= o > > 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. >=20 > you are right, but first we need and updated tree Yes, you're right. Maybe we could use the old tree, only fix security problems and ship that. Maybe we could package.mask it and use a development tree, that is only tested for building. Maybe some GNAP user (there have been some last year) is willing to share his tree and we can build on that. I'd like to look into an easy, mostly automated way of creating the tree, like a bunch of scripts and some documentation. If this is the only thing i get done, it was worth it. If i only get it started, then we are closer to being usable than we have before. > > =E2=80=A2 Reimplementation in python research > > Catalyst is written in python, maybe we could make better use of it i= f > > we reimplemented some parts of GNAP in python? This is just a researc= h > > item, i'd like to look into it and form some statement about it. I'll > > probably not do it. >=20 > i prefer to keep bash Again, i'll have to look into it. It's only research. There were some things i did not like in gnap, but i saw no other way to do it in such a low level language as bash. If i can do the scripts with half or one third of the lines of code in python, i would do that. If gnap and catalyst would merge in a way, that catalyst provides the tools and gnap only very very simple scripts and resources, that would be perfect, but gnap should not handle overlays, configurations and stuff, it should just pass them to catalyst. Much easier to do there, i think. But again, that are my current thoughts. Philipp --=20 gnap-dev@lists.gentoo.org mailing list