1 |
Hi, |
2 |
I see dropping ARM support is good for Gentoo in general due to lack of |
3 |
maintainers. GFZ is only a colateral damage ;-) |
4 |
|
5 |
That said, let's think what we should do now. |
6 |
|
7 |
First question that comes to my mind: Due to the many different ARM |
8 |
architectures out there, and the peculiarities of a zaurus (128Mb HD and 64 |
9 |
MB RAM, "special" install procedure, etc.), we will possibly not be valid ARM |
10 |
supporters, some packages could be validated by us and then be invalid for |
11 |
other ARM users. Should we create a ZAURUS architecture instead ARM? |
12 |
|
13 |
Fernando |
14 |
|
15 |
|
16 |
On Thursday 25 March 2004 10:00, Kumba wrote: |
17 |
> Akos Maroy wrote: |
18 |
> > we already have portage working, with an old snapshot of the portage |
19 |
> > tree (arm keywords still included). see |
20 |
> > http://gentooforzaurus.opensistemas.com/ |
21 |
> > |
22 |
> > the idea at the moment is to mount gentoo-related files through nfs, as |
23 |
> > it is quite large, and does not fit on most memory cards for the Zaurus. |
24 |
> |
25 |
> I don't doubt this. The smallest drive I managed to kludge gentoo on |
26 |
> was 1GB, and that required NFS mounting, and waiting about 5 days for |
27 |
> gcc to build over nfs (was a sparcstation 20). |
28 |
> |
29 |
> > by this you mean we shouldn't bother trying to create stage1? |
30 |
> |
31 |
> Stage1's need a seed stage, essentially a stage2 at minimum. I had to |
32 |
> use a live gentoo filesystem on my Cobalt RaQ2 to kickstart stage |
33 |
> building for the systems (they're mips little endian, at the time, only |
34 |
> big endian was supported). Once you can achieve a stage2, then you can |
35 |
> work on both stage3 and stage1. I basically tar'ed up my existing |
36 |
> stage2 on the cobalt at the time (installed over top a debian |
37 |
> installation), and used that as a seed stage for stage1 with catalyst |
38 |
> (was a ~100MB+ seed stage vs. ~40MB for stage2's), built a stage1 off |
39 |
> that, and then repeated twice more just to make sure I had a pure stage |
40 |
> with no debian in it (Took a week). |
41 |
> |
42 |
> > a lame question here: naturally there would be more poeple working on |
43 |
> > this, thus this separate portage tree has to be accessed / written by |
44 |
> > several people. how would we achieve this? put it in a CVS somewhere, |
45 |
> > and use cvs commit / update? or somehow utilize emerge sync? |
46 |
> |
47 |
> For this project, and since you already have people working on it, I'd |
48 |
> recommend CVS, or some kind of source code control system. It'll make |
49 |
> things easier. |
50 |
> |
51 |
> > I see, catalyst is the name of the game here :) |
52 |
> |
53 |
> Catalyst is the key for easier gentoo stage building. I always |
54 |
> considered the old 'stager' utility nothing more than a glorified bash |
55 |
> script, but catalyst is a real tool, and is rather effective at what it |
56 |
> does. |
57 |
> |
58 |
> > when we get there, we'll have to have special precautions for embedded |
59 |
> > systems. for example for the Zaurus, you have to flash the new operating |
60 |
> > system in, including the kernel and the base filesystem, via a manual |
61 |
> > procedure. |
62 |
> > |
63 |
> > but hey, it's still some way when we have to address this issue :) |
64 |
> |
65 |
> It's never an easy trip, porting to a new arch is typically only done by |
66 |
> one person, then others get interested. tuxus started the mips port |
67 |
> that way, tgall_foo is working on ppc64, GMSoft more or less ran the |
68 |
> hppa port all by himself for a time before some other people got hppa |
69 |
> boxes, iggy is working on an s390 port (unsure how many people are using |
70 |
> it), and the original arm port was started by zwelch by himself (he was |
71 |
> the one who forked Gentoo into Zynot btw). So in reality, if you've |
72 |
> already got a small team together, you're better off from the start than |
73 |
> some of the other ports. |
74 |
> |
75 |
> These precautions you speak of will need to be documented too. One of |
76 |
> the people working on the Zaurus stuff may want to maintain a |
77 |
> guidexml-based installation guide. Should arm get re-incorporated into |
78 |
> gentoo sometime down the road, this will be a required piece, especially |
79 |
> to get it integrated into the Gentoo Handbook. |
80 |
> |
81 |
> |
82 |
> --Kumba |
83 |
|
84 |
-- |
85 |
--------------------------------------------------------------------- |
86 |
Fernando Monera Daroqui |
87 |
|
88 |
openSistemas de Información Internet |
89 |
Tel.: 667 65 23 66 |
90 |
email: fmonera@××××××××××××.com |
91 |
http://www.opensistemas.com |
92 |
_____________________________________________________________________ |
93 |
|
94 |
Este mensaje se dirige exclusivamente a su destinatario y puede contener |
95 |
información privilegiada o confidencial. Si no es vd. el destinatario |
96 |
indicado, queda notificado de que la utilización, divulgación y/o copia |
97 |
sin |
98 |
autorización está prohibida en virtud de la legislación vigente. Si ha |
99 |
recibido este mensaje por error, le rogamos que nos lo comunique |
100 |
inmediatamente por esta misma vía y proceda a su destrucción. |
101 |
|
102 |
|
103 |
This message is intended exclusively for its addressee and may contain |
104 |
information that is CONFIDENTIAL and protected by professional |
105 |
privilege. |
106 |
If you are not the intended recipient you are hereby notified that any |
107 |
dissemination, copy or disclosure of this communication is strictly |
108 |
prohibited by law. If this message has been received in error, please |
109 |
immediately notify us via e-mail and delete it. |
110 |
___________________________________________________________________________ |
111 |
|
112 |
-- |
113 |
gentoo-embedded@g.o mailing list |