Hey Dan,
You don't happen to have IRIX discs for the Octane2 do you? I have an
O2, and I wanted to install IRIX on it to test some stuff out, but I
lost the disks and SGI wants $450 to send me new ones (yikes!).
On Jan 15, 2008, at 16:25, Daniel Ostrow wrote:
All:
As I am no longer an e
Ah, you're right, there should be an env-update in there. Thanks for
the report.
As for sourcing /etc/profile, you don't need to do that with eselect-
compiler because your $PATH doesn't change like it did with gcc-
config-1.x.
--Jeremy
On Jun 8, 2006, at 11:27 , Donnie Berkholz wrote:
On Jun 7, 2006, at 02:47 , Mike Frysinger wrote:
On Tuesday 06 June 2006 18:39, Jeremy Huddleston wrote:
Uhm, what is this all about? If you have suggestions, make them, but
don't come out of the gate in a huff talking about unsubstantiated
breakage. That's about the least construct
been an extremely conservative development process
because of the nature of this package.
--Jeremy
On Jun 6, 2006, at 04:28 , Ned Ludd wrote:
Why are you hijacking tools not written by you, declaring
them as 2.0 and breaking the expected behaviors of them?
Please don't do that ever again.
On Jun 2, 2006, at 21:33 , Donnie Berkholz wrote:
Couple of questions:
1) Can it handle non-gcc compilers? If so, how?
It is possible, but I'm not sure if icc is installed in a way that
makes it convenient. All the binaries will need to be lumped in a
directory by themselves (like we do
Well, incidentally I was working on "toolchainasing" gnat (a gcc
based Ada
compiler, basically just another frontend) and pestered toolchain
people on
irc regarding similar matters. Basically it came down to:
toolchain.eclass
and eselect-compiler are not for stuff not in gcc, so I had to
cr
I finally had a few free cycles, so I fixed up the eselect-compiler
ebuild to better handle the transition from gcc-config and updated
toolchain.eclass to better work with multilib. I've had a bunch of
help from the amd64 devs/testers/users this past week testing it out,
and I think it's r
> Maybe there needs to be an IWANTSLOTS feature or something, because the same
> rationale for why I was against a slotted mysql would have other people
> against a slotted kde, or slotted perl (ouch, so close to home, even if its
> conceptually fictional) - I neither need nor desire having mult
> >Before to this to happen I'll try my best to close the greatest number
> >of bugs still open (many already are but not committed) and manage to
> >bring MySQL back to the unslotted version.
> >
> >[1]
> >Yes. 12% [ 12 ]
> >No. 75% [ 72 ]
> >No preference. 11% [ 11 ]
> >
> I have one question:
Ok, I've put together an alpha release of compiler-config-2.0. This is
a replacement for gcc-config which is alot more configurable
Some notable improvements over gcc-config-1.3.x:
GCC_SPECS and PATH are nolonger set in /etc/env.d/05gcc. Instead, that
info is in the config files and extracted by
On Tue, 2005-08-16 at 18:18 -0400, Mike Frysinger wrote:
> suggestion:
> stop keeping ChangeLog files in CVS and instead, let them be generated
> automagically by the cvs server using the last of commit
> messages. if you really want to keep a commit message out of the changelog,
> then we com
> My opinion is this: Keeping eselect modules inside eselect's SVN repo
> results in:
> a) More eyes reading the code (read: QA)
I think the point you're trying to make here is that the QA is easier to
accomplish for you, and that certainly is true.
I think having modules in app-admin/eselect-/fi
I've recently updated opengl-update to use the eselect framework. I
think the team has done a great job as it was extremely easy to port the
bash script to an eselect module. However, when I placed it in the
portage tree, it sparked a little bit of a policy discussion between
myself and the core
On Wed, 2005-08-10 at 00:34 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Wednesday 10 August 2005 00:12, Jeremy Huddleston wrote:
> > I'd probably go
> > for something similar to the samba/gdm config files if we were to go
> > down this road:
> Such a for
On Tue, 2005-08-09 at 22:19 +0100, Ciaran McCreesh wrote:
> | but I think having the xml configuration files allows a much more
> | robust configuration.
>
> How so? Using XML doesn't magically make your data files any different.
> It simply makes them much harder to parse.
That's a matter of opi
I've been pretty busy this summer and haven't had much time to devote to
the gcc-config changes we discussed here a couple months back until
yesterday. I created a cvs repository for the development in
gentoo/src/toolchain/gcc-config. Right now, it's barely more than
framework for the code and a
16 matches
Mail list logo
