Re: [gentoo-dev] Available hardware

2008-01-15 Thread Jeremy Huddleston

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 ebuild dev (real life job got in the way) I  
have a

whole slew of hardware that I'm willing to ship to any gentoo dev for
the cost of shipping alone. The list of hardware is as follows:

1x HP C3700 750 MHz PA-RISC
1x Dec/Compaq PWS 600 600 MHz Alpha
1x SGI Octane2 Dual 195 MHz Mips
1x HP ZX2000 1.4 GHz Itanium2
1x Apple G4 1.25 GHz PPC32

I also have a slew of SPARC hardware, need to go home and catalog  
that,
not all that sure what all I have. I can answer any questions about  
the

other specs of the machine upon request.

If anyone is interested contact me off list. I live in northern
California for shipping reference.

Thanks,

--Dan


--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] eselect-compiler updates and unmasking

2006-06-09 Thread Jeremy Huddleston
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:


Donnie Berkholz wrote:

This aliases g77 to gfortran and gfortran to g77. They are entirely
different compilers and do not accept all the same options. This is
incredibly broken behavior, it masks issues in a number of  
packages and

creates new issues in many others. Please fix it.


It also doesn't run env-update, so the library paths aren't  
updated. In

the past, all that was necessary was to source /etc/profile.

Thanks,
Donnie



--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] eselect-compiler updates and unmasking

2006-06-07 Thread Jeremy Huddleston

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 constructive way to get heard.


i guess his point is, you're the only guy supporting eselect- 
compiler ... if

you arent going to be around to support it, then dont unmask it
-mike


Yeah, I couldn't agree more.  That's part of the reason why I hadn't  
unmasked it until now.


--Jeremy

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] eselect-compiler updates and unmasking

2006-06-06 Thread Jeremy Huddleston
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 constructive way to get heard.


The wrapper provided in gcc-config-2.0 provides the exact same  
interface to the user as gcc-config-1.x, so how is that breaking  
expected behavior?  If anything, it's providing expected behavior to  
users who want it and don't care about migrating over to eselect.   
Additionally, If you check through the ChangeLog, you'll see that I  
did actively worked on gcc-config-1.x last year prior to my starting  
eselect-compiler.  That's how I came to realize its limitations and  
_need_ for replacement on multilib systems.  A similar wrapper is  
needed for binutils as has been discussed multiple times on  
toolchain@, and at amd64 and ppc64 dev meetings on IRC.


Additionally, eselect-compiler has been discussed multiple times on  
the toolchain and gentoo-dev lists over the past year (main threads  
started 2005-08-09, 2005-09-17, 2005.10.02), and you didn't once  
raise an objection until now.  I'd say you missed the 10 month window  
I gave you, but if you do have suggestions, I'd be more than happy to  
hear them.


Even more so, I left eselect-compiler in package.mask for a _very_  
long time as I didn't have much time to devote to its development  
over the past school year.  During that time, very few issues were  
raised despite it being used by many testers and developers.  This  
past month, I worked out all but one of the known bugs (the one  
remaining is just specific to the wine package on amd64) and got more  
testers to give it a final beating before finally unmasking it.  If  
anything, this has 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 Fri, 2006-06-02 at 21:24 -0700, Jeremy Huddleston wrote:

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 ready to be removed from package.mask sometime soon
(next week).  Before that happens, I'd like to get some feedback from
a broader test base, so if you have some time and aren't using
eselect-compiler yet, I'd appreciate your testing.  All you need to
do is add the following to /etc/portage/package.unmask:

app-admin/eselect-conmpiler
sys-devel/gcc-config

then just update gcc-config:
$ emerge -uv --oneshot sys-devel/gcc-config

gcc-config is just a wrapper which takes the same syntax as the older
gcc-configs and makes the appropriate call to eselect-compiler.

Please report any bugs you find in bugzilla and assign them directly
to me ([EMAIL PROTECTED]).

Also, if you've been using eselect-compiler, you may have an issue
where your profiles don't get removed from /etc/eselect/compiler when
you unmerge gcc.  This problem is fixed now for future installs, but
you'll have to manually remove the file when you unmerge any gcc that
is on your system now.

Thanks,
Jeremy


--
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux

--
gentoo-dev@gentoo.org mailing list



--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] eselect-compiler updates and unmasking

2006-06-04 Thread Jeremy Huddleston
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  
create my own
ones (gnatbuild.eclass and eselect-gnat), a bit simpler versions  
actually :).
I could not inherit toolchain.eclass either, only copy the relevant  
parts of

it..

A due notice: this was discussed already like half a year ago  
(although when I
announced progress here on -dev no comments followed), so if the  
things have

chaged since then I will be interested to know too..


Well, I'm not against that support being in eselect-compiler, and in  
fact I think it'd be nice... It's just not a priority on my list, so  
if you'd like to contribute changes which allow support for what you  
want without needlessly complicating things for those who don't want  
to use these advanced features, then I'm more than willing to  
incorporate them.


--Jeremy
--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] eselect-compiler updates and unmasking

2006-06-04 Thread Jeremy Huddleston

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 with gcc).  You'll have to create  
your own profile in /etc/eselect/compiler.



2) Can it handle different languages being set to different compilers?
For example, use Intel's Fortran compiler but GCC for everything else.



No, this isn't something I considered a high priority.  I was more  
interested in tackling the issues road-blocking multilib, but this is  
something that would be a nice feature down the road.



--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] eselect-compiler updates and unmasking

2006-06-02 Thread Jeremy Huddleston
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 ready to be removed from package.mask sometime soon  
(next week).  Before that happens, I'd like to get some feedback from  
a broader test base, so if you have some time and aren't using  
eselect-compiler yet, I'd appreciate your testing.  All you need to  
do is add the following to /etc/portage/package.unmask:


app-admin/eselect-conmpiler
sys-devel/gcc-config

then just update gcc-config:
$ emerge -uv --oneshot sys-devel/gcc-config

gcc-config is just a wrapper which takes the same syntax as the older  
gcc-configs and makes the appropriate call to eselect-compiler.


Please report any bugs you find in bugzilla and assign them directly  
to me ([EMAIL PROTECTED]).


Also, if you've been using eselect-compiler, you may have an issue  
where your profiles don't get removed from /etc/eselect/compiler when  
you unmerge gcc.  This problem is fixed now for future installs, but  
you'll have to manually remove the file when you unmerge any gcc that  
is on your system now.


Thanks,
Jeremy

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] SLOTed MySQL or not?

2006-03-15 Thread Jeremy Huddleston
 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:
 Who answer NO on poll?

Users don't always know what's right for themselves, and I'm sure a big
percentage of these nos are because people don't want to go through
the hassle of figuring out how to switch to slotted, not because it's a
bad idea.  This is a MUCH NEEDED feature and one I was extremely glad
someone worked on.  Don't get rid of it.  I didn't even notice this
thread until I noticed weirdness in my mysql upgrade from slotted back
to unslotted.  For gods sake, don't get rid of this feature just because
a few users don't want to read some docs.




signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] SLOTed MySQL or not?

2006-03-15 Thread Jeremy Huddleston
 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 multiple copies of 
 the application available on one box, when i am only ever going to connect to 
 one running copy.

Maybe I'm misreading your comment here, but I don't see how I only want
to install one version is an argument against having the _ability_ to
install multiple versions.  Just because you neither need nor desire it
doesn't mean it's not extremely useful to many other users.

 H...a feature flag that (where applicable) disabled retaining other slots
 might be nice come to think of ithijack thread accidentlydisabled 
 for the packages you need multiples of (berkdb?) but optionally enabled for 
 packages like WM's and relational DB's where you just might not want more 
 copies...or to remember to go back and unmerge and track the stray files 
 for/end accidental hijack

That seems like a lot of work for something that is easily done through:

emerge --prune -p
then
emerge --unmerge the ones you want




signature.asc
Description: This is a digitally signed message part


[gentoo-dev] compiler-config-2.0_alpha1

2005-09-16 Thread Jeremy Huddleston
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 the wrapper.
Users can have their own settings rather than use the system compiler.
Multilib archs will be able to have more control over the compilers used
for each ABI.  For example, you can install x86_64-*-gcc-3.4.4 and
i686-*-gcc-3.3.6 and choose to use either 3.4.4 or 3.3.6 when compiling
code with i686-*-gcc

Also, many thanks to sekretarz for writing the config file parser.

Requirements:
Emerge eselect before you install this.

Notes:
This is alpha.  It might break; the eselect module still needs cleaning
up and functionality added; yada yada yada.  There's no migration script
yet from the 1.3.x config files, and also toolchain.eclass doesn't make
config files for it either which means you need to make the config files
yourself.  You can find sample config files for gcc-3.4.4 on amd64 in
the conf directory of the tarball.  Just copy them
to /etc/eselect/compiler and edit them appropriately.  If anyone wants
to help with the migration script or anything else for that matter,
please let me know.

I'm not making an ebuild for it because there's no migration script for
it, and I'd like to get it cleaned up and finished more before it
reaches cvs (even in a package.mask state).

http://dev.gentoo.org/~eradicator/gcc/compiler-config-2.0_alpha1.tar.gz

--Jeremy


signature.asc
Description: This is a digitally signed message part


[gentoo-dev] eselect modules

2005-08-16 Thread Jeremy Huddleston
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 eselect devs on how to best include modules in the
tree, so I'd like to let other devs chime in as well.

Firstly if you don't know what eselect is, check out:
http://www.gentoo.org/proj/en/eselect/index.xml 

The eselect developers want to keep all eselect modules in their svn
repository and distributed through a single package (app-admin/eselect).
Their main reasons for this are better QA and less overhead for releases
and merging.

I have a problem with this policy because:
1) Stability of the modules should not be tied to stability of the core
package.  Basically, I'd like to determine when my modules get pushed
into stable without considering how it'll effect the eselect modules of
other developers.  Similarly, I don't want bugs in another module
holding up my module from going into stable.

2) Not all users will want all modules.  The goal of the eselect project
is to provide a framework to replace java-config, motif-config,
gcc-config, binutils-config, opengl-update, etc, but not all users will
need all modules.

3) Some modules require extra files (opengl-update installs header
files, gcc-config installs a wrapper, etc), and the app-admin/eselect
package is not the correct place to provide these files.

Also, what should the correct way to introduce these modules into
portage?
Should we keep them in the packages they're replacing
(x11-base/opengl-update)?
Should we place them in a new package in the same category as the script
they're replacing (x11-base/eselect-opengl)?
Should we place them in app-admin/eselect-module name or perhaps
app-eselect/module name?

Note that for backwards compatibility in all cases,
x11-base/opengl-update will RDEPEND on this eselect module and install a
backwards-compatible frontend to the eselect module until all packages
in portage have been updated to use the eselect module instead.



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`

2005-08-16 Thread Jeremy Huddleston
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 arbitrary number of commit 
 messages.  if you really want to keep a commit message out of the changelog, 
 then we come up with a simple policy of prefixing the message with a period 
 (to keep it hidden :P).

I like the idea.  This should force people to actually make their cvs
commit statements worth something.


signature.asc
Description: This is a digitally signed message part