1 |
On Sunday March 22 atsui wrote: |
2 |
> markusle wrote: |
3 |
> > |
4 |
> > We had a long time |
5 |
> > ago agreed to go with 3., simply because of the fact that the |
6 |
> > octave-forge.eclass does most of the work at this point and there |
7 |
> > is hence no good reason to add a new category to the portage tree |
8 |
> > which contains many |
9 |
> > tens of split octave-forge ebuilds that by themselves simply call |
10 |
> > the eclass |
11 |
> > and hence don't do anything but waste space. |
12 |
> > |
13 |
> |
14 |
> I've just started following this list, so I was wondering what the |
15 |
> status of octave-forge is on the overlay? As you know, there might be |
16 |
> a SoC project to write something to handle the octave packages |
17 |
> including octave-forge, but I was wondering if there was any |
18 |
> development in this direction in the last month or so? |
19 |
|
20 |
The last work has been Markus eclass implementation which is what you |
21 |
see in the science overlay with git. |
22 |
|
23 |
|
24 |
> juantxorena wrote: |
25 |
> > |
26 |
> > Hopefully GCC-4.3 is going to be stabilized soon. Is there any |
27 |
> > comment on this? |
28 |
> > |
29 |
> |
30 |
> Does anyone know if this is still a problem? |
31 |
|
32 |
This is work in progress. Still some packages are not compiling with |
33 |
gcc-4.3. octave-3 is fine with it. The only worry here is that we want |
34 |
to have octave-3 stabilize, which is currently being done. |
35 |
|
36 |
-- |
37 |
Sébastien |