[gentoo-dev] (Not so) New Developer - The Paya

2006-09-06 Thread John Mylchreest
Hi Guys,

I've been very slack about announcing some of our new guys recently, and
not least Javier Villavicencio.

Javier, known on IRC as The_Paya, joined us to work on all aspects
Gentoo/FreeBSD plus anything else he can throw his skills at! Coming
from Argentina he has an interest in fishing, high end hardware and
playing with imaging apps.

Javier has also done a great job of infiltrating yet another company
with production servers running Gentoo :)

I'm sure I'm not the only one to throw thank-you's and welcome him on
board! Here's to a long and enjoyable involvement with Gentoo!

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgpgN7QPT6GIz.pgp
Description: PGP signature


Re: [gentoo-dev] [QA] Incomplete IUSE for useflags in {,R,P}DEPEND, SRC_URI etc...

2006-07-14 Thread John Mylchreest
On Wed, Jul 12, 2006 at 03:23:06PM +0200, Matthias Schwarzott [EMAIL 
PROTECTED] wrote:
 On Wednesday 12 July 2006 15:16, Danny van Dyk wrote:
  Hi all,
 
  thanks to djm's efforts i was just able to scan the whole tree using
  qualudis. For a start, i'll attach a list of QA violations on missing
  entries in IUSE. As this is a minor change to the ebuilds, I'll go on
  and fix all the listed ebuilds myself.
 
  There are 505 ebuilds which are missing use flags in IUSE that they use
  in other places.
 
 While reading your list I have seen pcmcia often. e.g. on my ebuild 
 v4l-dvb-hg 
 not supporting pcmcia as conditional. A bit digging showed that 
 linux-mod.eclass contains this code:
 
 --cut--
 IUSE= # don't put pcmcia here, rather in the ebuilds that actually support 
 pcmcia
 SLOT=0
 DESCRIPTION=Based on the $ECLASS eclass
 RDEPEND=kernel_linux? ( virtual/modutils
 pcmcia? ( virtual/pcmcia ) )
 --cut--
 
 I don't know if pcmcia should then be added to every ebuild including 
 linux-mod.eclass.
 
 Please solve this before adding pcmcia on every kernel-module-ebuild.
 
 Matthias
 
 -- 
 Matthias Schwarzott
 Gentoo Developer
 http://www.gentoo.org

This is actually on my TODO list, but has been for some time now. I'll
reprioritise and get this out the way I think :)

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgpHli4liTK4d.pgp
Description: PGP signature


Re: [gentoo-dev] Pending Removal of $KV

2006-07-09 Thread John Mylchreest
On Mon, Jun 19, 2006 at 11:13:33AM +, Alec Warner [EMAIL PROTECTED] wrote:
 Portage currently exports $KV as the current kernel version.  We detect 
 this by attempting to mess around with the things in /usr/src/linux 
 (.config, make files, etc...)
 
 This is duplicating the superb efforts of the kernel team and of 
 linux-info eclass.  As such I would like to deprecate $KV in favor of 
 using linux-info eclass.  I don't see the need for portage to export $KV 
 into the environment for all packages.
 
 There are a few packages left that use this.  There will be a tracker 
 bug shortly.  Mostly this mail is just a heads up ;)

I've been after this for quite a long time (I opened a bug but cant seem
to find it) as not only is it horrifically broken, it also should never
have been the job of portage internals anyways.

$KV is currently being exported by linux-info purely for legacy support
and as such I would like to suggest that if these ebuilds inherit
linux-info as well as use $KV, then it should not require any maintainer
changes.

Anything I can do to encourage this move please let me know, and many
thanks for raising this again.

Best Regards,
John

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgppBTaSFSiXx.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [gentoo-core] Resignation

2006-07-09 Thread John Mylchreest
On Tue, Jun 27, 2006 at 03:21:49PM +0200, Andrej Kacian [EMAIL PROTECTED] 
wrote:
 On Tue, 27 Jun 2006 13:07:45 +0200
 Enrico Weigelt [EMAIL PROTECTED] wrote:
 
   As I have been swamped with emails, private messages and phone calls
   from certain people, I will retract my resignation for the final time.
  
  I'm fairly new to Gentoo, but I'd like to help.
  So, what shall I do ?
 
 You can start by not hijacking mailing list threads. Or am I the only one
 failing to see how is this connected to Jory's (retracted) resignation ?

Having not yet read the rest of this thread I'm sorry if this is going to 
repeat anything else thats being said, however...

This is a prime example of one of the reasons which is making people
leave gentoo, either as a developer or as a user. Having someone email
to show their appreciation for peoples work and equally as important to
also be willing to commit their own time to help as well being shot down
with such an ignorant comment is upsetting to say the least.

I suggest the next time someone wants to offer their help you think
twice before you flame for off-topic. However, on that note...

Enrico, 

Please find some reading on the subject here:
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1chap=2

If you need any further help please feel free to join IRC and ask in
#gentoo-userrel

Best Regards,
John

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgpdrA1OgQFtA.pgp
Description: PGP signature


[gentoo-dev] New Developer Mike Auty (ikelos)

2006-05-03 Thread John Mylchreest
Hi All,

Its with great pleasure that I announce a new vict^W^W^W^Wdeveloper to
the ranks, Mike Auty. I'm sure you'll all make him feel very welcome :)

Mike's been around helping many of us for a long time now, most recently
with the excellent work he's been doing on vmware.

Mike has this to say:
I came from Lancaster originally but now live in Worcester in the UK.  I
mostly enjoy spending my time chatting to my close friends and exploring
crazy ideas with them, or being on my own and looking for new tools and
ideas on the Internet.  I'm interested in loads of areas, so I guess that
makes me a generalist, and if you've got something new and interesting you
need help with then I'd love to hear about

So for all you mad scientist folk out there with crazy ebuilds waiting
to go into the tree, you're finally in luck!

All the best to you Mike,

Regards,
John

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgpJGXxx1iraU.pgp
Description: PGP signature


[gentoo-dev] New Developer: squinky86

2006-04-18 Thread John Mylchreest
OK, You got me. Not really *new* but meh!
I'd like to welcome back Jon Hood (squinky86) who has returned after a
prolonged hiatus. If you wish to cheer or throw underwear, this is your
cue. Jon hails from Huntsville, AL, but its not his fault, bless.

Jon will be mostly working on accessibility and net-p2p.

A few words from the horses mouth:

I'm Jon Hood from Huntsville, AL. I was a Gentoo developer before, but
some problems came up and now I'm returning. All my spare time is put
into developing applications for voip (esp. Asterisk), Gentoo, and last
but DEFINITELY not least, my wonderful girlfriend, Caitlyn (who KingTaco
wanted to make a dev instead of me).
I am good with c++, java, assembly, php, and sql. Feel free to ask me
about Asterisk, too. It's good to be returning to Gentoo!

I'll be uploading photos of Caitlyn to hotornot.com shortly, I'm sure
she will score very highly :)

So on that note, hurrah for Jon, and welcome back to the party.


-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgpsogaAB5Uqr.pgp
Description: PGP signature


[gentoo-dev] adding INSTALL_MASK to info_vars

2006-04-01 Thread John Mylchreest
Hey guys,

Anyone got any objections to this?
If you do, please speak up now, else I will add this in the close to
immediate future.

Cheers,
John

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgpFWya9vzb55.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Gratuitous useflaggery (doc and examples)

2006-03-05 Thread John Mylchreest
OK sorry, all those Re:'s were really getting to me :)

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgpZltaagIJyM.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] QA Team's role

2006-02-28 Thread John Mylchreest
On Mon, Feb 27, 2006 at 05:30:27PM +, Stephen Bennett [EMAIL PROTECTED] 
wrote:
 (Yes, I'm taking that sentence out of context, but the fact that it
 comes up at all says something, to my mind.)

Your mind is a dark and twisted place!

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgpcif7cymuGN.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] QA Team's role

2006-02-27 Thread John Mylchreest
On Sun, Feb 26, 2006 at 07:09:29PM -0500, Mark Loeser [EMAIL PROTECTED] wrote:
   The problem with that is, it usually ends up with too many pointless
   comments from people saying how things could be fixed in the distant
   future, or whining that it isn't explicitly forbidden by policy on
   situations where the screwup was too weird to be documented previously.
  
  This is very much a case-by-case thing. I still feel the debate should
  be better answered outside of conflicting qa members.
 
 Well, instead of putting the debate into an even larger crowd, this
 enables the QA team to act in the way it sees best first.  If people
 believe we were wrong, then we give them the option to talk to the
 council about one of our changes.  Also, we aren't unwilling to hear
 alternatives and we hope to work with the maintainer on these problems.

I've yet to read the rest of this subthread this morning, but while its
fresh in my mind I would also like to see less of a requirement from the
council. They are there purely for technical direction and not for a
teams beck and call. Regardless, I can see your point - although I would
still prefer to see a little more public discussion when the QA team are
unable to satisfactorily come to an answer between themselves and the
maintainer in question.

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgpLXBkh7cAFg.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] QA Team's role

2006-02-27 Thread John Mylchreest
On Sun, Feb 26, 2006 at 07:12:52PM -0500, Mark Loeser [EMAIL PROTECTED] wrote:
 Alec Warner [EMAIL PROTECTED] said:
  This is meant to prevent the case where the QA team ( or a subset; the
  established QA members ) decides to make unilateral changes to the tree
  ( or large subset thereof ) without even necessarily talking to the
  affected developers.
  
  While you may not think that soliciting comments is useful ( and in some
  limited cases I would agree with you ) giving people the opportunity to
  comment also means you just covered your ass, in terms of people going
  where the hell did that come from?
 
 We don't plan on going around and making changes without discussing
 issues with the maintainers.  We put this in so that if the maintainer
 is unwilling to work with us for some reason, that we are able to come
 up with what we believe to be the best fix.  As I said earlier in the
 document, we plan to work as much with maintainers as possible, but
 sometimes that may prove to be impossible.

In this specific instance, impossible is effectively a point of view.
For me the question comes down to this.. If QA trump maintainer, then
who picks the QA staff? If anyone can become QA staff, then this is
questionable in itself. is QA becoming another council with a sole
purpose? If so I'd like to see an election again. At the end of the day
the pack have to have faith in the team doing the work, and
disagreements are obviously contrary to that.

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgpgTcm5SZaCd.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] QA Team's role

2006-02-27 Thread John Mylchreest
On Mon, Feb 27, 2006 at 04:37:52PM +, Ciaran McCreesh [EMAIL PROTECTED] 
wrote:
 On Mon, 27 Feb 2006 09:09:01 + John Mylchreest [EMAIL PROTECTED]
 wrote:
 | In this specific instance, impossible is effectively a point of view.
 | For me the question comes down to this.. If QA trump maintainer, then
 | who picks the QA staff? If anyone can become QA staff, then this is
 | questionable in itself. is QA becoming another council with a sole
 | purpose? If so I'd like to see an election again. At the end of the
 | day the pack have to have faith in the team doing the work, and
 | disagreements are obviously contrary to that.
 
 QA consists of whoever is on the QA project page. To be added, you must
 convince the existing QA team that you know what you're doing.

My point was the more along the lines that the existing QA team need 
to convince the rest of the development community that they know what 
they're doing first. Whats stopping the existing QA team disregarding
all new applicants because they enjoy having authority? Especially when
its mis-placed authority.

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgpe2CwZZJnYv.pgp
Description: PGP signature


Re: [gentoo-dev] Putting all log related packages into it's own category (sys-logging)

2006-02-20 Thread John Mylchreest
On Mon, Feb 20, 2006 at 02:13:46PM +0100, Bjarke Istrup Pedersen [EMAIL 
PROTECTED] wrote:
 I was thinking, how about putting all log related packages into their
 own category?
 This should be logging daemons, log viewers, logrotate etc.
 
 Maybe creating a logging herd would be an idea to, to remove the load
 from the base-system herd.
 
 What do you think?

I think this is a great idea, as long as it doesnt get abused. There are
quite a lot of log handling packages anyways, although would there be
enough to warrant a new category as well as a new herd?

My brief suggestion of packages which would be good for this:

app-admin/analog
app-admin/cronolog
app-admin/fetchlog
app-admin/klogview
app-admin/logmon
app-admin/logrotate
app-admin/logsentry
app-admin/metalog
app-admin/modlogan
app-admin/newsyslog
app-admin/phpsyslogng
app-admin/socklog
app-admin/sysklogd
app-admin/syslog-ng
app-admin/ulog-acctd
app-admin/ulogd
app-misc/logserial
net-firewall/fwanalog
net-mail/qlogtools
net-mail/qmailanalog
sys-apps/gluelog
sys-apps/logwatch
x11-misc/paralogger

Regards,
John

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgp50aBPGXFyN.pgp
Description: PGP signature


Re: [gentoo-dev] Re: /etc/rc.conf

2006-02-14 Thread John Mylchreest
On Mon, Feb 13, 2006 at 08:15:23PM -0500, Mike Frysinger [EMAIL PROTECTED] 
wrote:
 On Monday 13 February 2006 20:07, Forrest Voight wrote:
  How is that wrong? If it isn't, eselect would be a great way to switch
  EDITOR and XSESSION.
 
 jesus, talk about over engineering
 
 using eselect to manage some default variables instead of simply editing your 
 ~/.bashrc file is like using a backhoe to dig a hole for a bonsai tree ... 
 sure it'll work, but who the hell wants a goddamn bonsai tree
 -mike

I have 2 :)

But on topic, I totally agree with Mike. OK, Possibly EDITOR and
XSESSION are better suited to somewhere else other than rc, but atm that
place doesn't exist, and imo doesn't warrant creation.

/etc/env.d/ (when it comes to setting a default editor) just seems very odd to 
me. It's not easily managed from a package perspective. It can easily just 
throw some random behaviour.

Of course, user specific EDITOR etc, is much better set in the
appropriate ~/dotfiles. System wide, all we need is a workable default.

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgpujO1RGFPSU.pgp
Description: PGP signature


Re: [gentoo-dev] Manifest2 decision delayed

2006-02-11 Thread John Mylchreest
On Sat, Feb 11, 2006 at 11:38:05AM +0200, Alin Nastac [EMAIL PROTECTED] wrote:
 When you have thousands of small files (1-4 blocks), the space saved by
 removing all unnecessary whitespaces is minimal at best.
 Minimizing the number of files is another story. Unifying manifests with
 digest files will save a considerably amount of disk space.

not to mention inodes. Thats one of my pet-hates about the tree' size.

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgpMi8VmuXsjM.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Re: Request for Comment

2006-02-11 Thread John Mylchreest
On Sat, Feb 11, 2006 at 11:09:07AM -0700, Duncan [EMAIL PROTECTED] wrote:
  Duncan, you make some valid points but for the sake of ease for the rest
  of us, could you please try condense the mails down from several pages? :)
 
 I've been proud of myself, even managing a couple one-liners, lately. =8^)

Keep up the excellent work ;)

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



pgpIK95zcZ8h5.pgp
Description: PGP signature


[gentoo-dev] relocation.

2005-12-30 Thread John Mylchreest
Hi All,

Just to let you know that as of tonight there is no guarantees on when I
will be back online. I pack up my most valued of possessions (in case
you never guessed, its my computer kit ;)) and get ready to board a
one-way ticket to York.

Anyone in the area who fancies meeting up for a drink is welcome to
email me and I will read it when I'm back, but I would like to wish
everyone a fantastic new years (replace with appropriate holiday) and
all the best.

I move into the new flat on the 3rd, so I suspect net access of some
variety will exist at some point around the 20th, but I will be having
withdrawal so the sooner the better :)

Anything urgent I'm sure you can find someone with my mobile number in
#gentoo-uk, but I'm sure that's not going to happen.

Happy Holidays Campers,
John

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515 
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515
Web:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x9C745515

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] relocation.

2005-12-30 Thread John Mylchreest
On Fri, 2005-12-30 at 13:06 -0500, Philip Webb wrote:
 051230 John Mylchreest wrote:
  as of tonight I pack up my most valued of possessions -- my computer kit --
  and get ready to board a one-way ticket to York.
 
 York of the Minster  bright new archbishop or our own Muddy York ?

Minster and the slightly odd-lookin' clergyman.
I do fancy a holiday though ;)

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515 
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515
Web:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x9C745515

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Wanted: AMD MP2400+

2005-12-05 Thread John Mylchreest
Hey all,

Sorry for asking on this list but if anyone has an MP2400+ which they
are willing to get rid of (I can pay PP and a reasonable asking price)
on the cheap, please let me know.

Please email me off-list on this mail if you can help me.
It will certainly help me out a LOT!

Many thanks,
John

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515 
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515
Web:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x9C745515

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-core] Re: [gentoo-dev] Possible virtual/alsa change

2005-10-27 Thread John Mylchreest
On Mon, 2005-10-24 at 15:41 -0400, Stephen P. Becker wrote:
 Currently, we have two machines with alsa drivers (only one of which 
 *really* works, but that is beside the point), and the working driver is 
 applied to our mips-sources-2.6.* ebuilds along with the patchset for 
 octane.  However, this information is pretty irrelevent from my point of 
 view.  The real problems are that A) alsa-driver doesn't contain any 
 mips drivers, B) 2.4 kernel sources do not contain the alsa drivers 
 while 2.6 do, and C) that mips-sources included both 2.4 and 2.6. 
 Therefore, we really do not have anything generic that can be changed to 
 the default virtual for us without being broken (until such time as we 
 can finally get rid of 2.4).  I don't have a solution at this point in 
 time either...I'm just saying how things are.

I dont see this as a real reason to not change the default personally.
mips-sources exists in the tree for a reason, and are being actively
maintained. by setting the default virtual for alsa-sound to
gentoo-sources surely wont effect you anyways, considering alsa-drivers
doesn't work, gentoo-sources likely dont work, and mips-sources provide
virtual/alsa?

If at some point alsa-drivers decides to work, then can you not just
redefine the virtual in the mips profile?

Anyways, I see no real point here to prevent the move, however I found
it educational re: alsa-driver :)

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515 
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515
Web:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x9C745515

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-core] Re: [gentoo-dev] Possible virtual/alsa change

2005-10-27 Thread John Mylchreest
On Thu, 2005-10-27 at 14:28 -0400, Stephen P. Becker wrote:
 The problem is that *all* mips-sources ebuilds do not provide alsa. 
 Only the mips-sources-2.6.* versions do this, and then only if 
 USE=ip30 (Octane users).

This makes sense, although not the USE flag.

 I'm just worried about folks running 2.4 systems (only Indys at this 
 point) with mips-sources providing alsa, but not really.  This could 
 get even more tricky because I happen to know somebody is working on an 
 alsa driver for Indy, and it will be for 2.6 only.  We're trying really 
 hard to get everything to where we can just get rid of 2.4, but until 
 that time, setting the virtual to mips-sources is technically broken.

Of course, 2.4 kernels are technically broken because they dont support
alsa, and this is fixed in other profiles with the inclusion of a 2.4
(or 2.6) sub profile. However.. if nothing actually works with alsa,
then I dont see the problem in that case of making the profile default
mips-sources. if it happens to install 2.4 sources, then so be it. it
might be a technically incorrect provide.. but nothing else can fill it
any better. At least at this moment in time.

If it were me, thats what I would do. But of course, this change doesn't
really make any difference to mips one way or the other.

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515 
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515
Web:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x9C745515

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Suggestion: ebuilds linked to kernel upgrade

2005-10-20 Thread John Mylchreest
On Wed, 2005-10-19 at 17:31 -0400, Chris Gianelloni wrote:
 Actually, genkernel does have the --callback option, which runs an
 external command before finalizing the build.  We use it for building
 external modules and packages that require a configured kernel when
 building the releases, but I think adding an option to genkernel
 wouldn't be bad to do this for you.  We could add a command-line switch
 to genkernel to automatically rebuild any external modules after it has
 built the kernel.  We could use something like --autorebuild.  You could
 then do something like genkernel --autorebuild all to build your new
 kernel and automatically rebuild all of your external modules.

My thoughts exactly. And I'm sure a welcome addition.

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515 
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515
Web:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x9C745515

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Suggestion: ebuilds linked to kernel upgrade

2005-10-19 Thread John Mylchreest

 2005/10/19, Herbert G. Fischer [EMAIL PROTECTED]:
 Perhaps the modules-update could be extended to detect new
 kernels and warn users or automatically update modules. This
 could also be documented in Gentoo docs since this is a basic
 and common problem that almost every Gentoo user may have.

module-rebuild shouldn't really have this task. it isn't the right place
to do it. It will of course quite happily do what you need it to do,
rebuild anything which installs a kernel module from portage.
 
 2005/10/19, John Myers [EMAIL PROTECTED]

 if [ -n $(which module-rebuild 2/dev/null) ] ;
 then 
 if [ -n ${AUTO_MODULE_REBUILD} ] ; then
 echo Rebuilding external modules:
 module-rebuild ${MODULE_REBUILD_OPTIONS}
 rebuild
 else
 echo You might want to rebuild the following
 external modules: 
 module-rebuild -XC list | tail -n +2
 echo
 echo You can use module-rebuild to do that.
 echo If you want to have your external
 modules automatically rebuilt 
 echo when making a kernel's modules_install
 target, set
 echo AUTO_MODULE_REBUILD in your environment.
 You can set
 echo MODULE_REBUILD_OPTIONS to options to
 pass to module-rebuild. 
 echo (-X for example)
 fi
 else
 echo You might want to emerge
 sys-kernel/module-rebuild to keep track of
 echo kernel modules you've installed with
 emerge 
 fi
 
I don't particular feel comfortable doing this. the only place I can
actually see this being of some use is with the pkg_config since an
ebuild postinst is far too soon, and patching up Kbuild to do this is
far too intrusive (let alone high maintenance).

A possibility (although I wouldnt like to promote it through portage)
would be to have a wrapper/helper script which would do all of this for
you. build-kernel or some such. But then... whats genkernel for right?

- John


-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515 
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515
Web:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x9C745515

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK

2005-09-21 Thread John Mylchreest
On Wed, 2005-09-21 at 12:03 -0400, Chris Gianelloni wrote:
 The current /usr/src/linux method works quite well for releases.  The
 only issue we're having is a non-fatal check being fatal, which is going
 to be fixed.

OK, so being the huy who wrote and looks after all this stuff, here is
my 2c and reasoning.

First of all, falling back on `uname -r` isn't going to happen for
several reasons. I can understand for some why this might seem sensible
(what happens if you remove your kernel sources for example). But the
fact remains that testing the currently running kernel is not a viable
option in my mind. Why? well, 1: the running kernel bares absolutely no
relevance on the environment which you're building this for. 2: you can
pass KERNEL_DIR manually, so if you refuse to work in the expected way
then set KERNEL_DIR to point to the right location.

Secondly, I have thought about this some more during the day, just as I
did at initial implementation (The code could do with a tidy-up
anyways). After much deliberation I feel the actual best way to deal
with this, is to have an override envvar which will bypass a die, and
simply warn instead. This will mean that those people who cross-compile
regularly, or building stages etc will work fine, and normal operation
would continue to refuse a build if the environment its building for
doesn't seem sane. At the end of the day, the true root cause of
something die'ing when it shouldn't is at the ebuild. That.. and if its
really not that important, then surely the ebuild can call the config
check itself, and handle it as it feels fit.

I'll update the bug also with this.

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



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


Re: [gentoo-dev] USE=minimal for kernel sources

2005-09-08 Thread John Mylchreest
For the record, there is a bug open for this. (#64009)
Personally, I'm not keen on the idea.
the only way which we can do this is by detecting which arch we are
installing the sources, for, which immediately means many installs of
USE=minimal are not the same.

There are plenty of other reasons I can go into, but if anyone feels
strongly to push this change, then feel free to reply with justification
as to why. Technical info to back it up as well please :)

- John

On Thu, 2005-09-08 at 20:17 +0200, Diego 'Flameeyes' Pettenò wrote:
 On Thursday 08 September 2005 20:10, solar wrote:
   Perhaps you can simply just take advantage of tar's
  --exclude=/-e options in the unpack() function of ebuild.sh when
  USERLAND == GNU
 tar --exclude/-e is supported by both bsdtar and gtar.
 
-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



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


Re: [gentoo-dev] USE=minimal for kernel sources

2005-09-08 Thread John Mylchreest
On Thu, 2005-09-08 at 22:14 +0200, Jan Kundrát wrote:

 Er, but why is this a problem? Does it matter that the package will
 install different files on x86 than on mips? Or am I just overlooking
 the point?

In general, there is no obvious technical reason against individual
installs differing from one another, however from a support and QA point
of view it makes it a much less trivial issue. At the end of the day,
when it comes to USE=minimal no-one can fully confirm what does, and
does not exist (can cause breakages may I add) when it comes to
supporting a bug, and also we can't promise it wont destroy an arch tree
which you need. I'm thinking obscure (or not quite so) architecture.
Pegasos, Sun, Sparc, SH, arm, etc.

Although Kbuild is more than capable of functioning with only the
required arch tree, what happens when it comes to things like
cross-compile, not just of the sources but of anything else which might
use them later on? ipw2200? nvidia? alsa-drivers?

Just a bit of a worry to me, and not something I would really like to
endorse.

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515



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


Re: [gentoo-dev] GLEP 38: Status of forum moderators in the Gentoo project

2005-06-28 Thread John Mylchreest
On Tue, 2005-06-28 at 17:49 -0400, Olivier Crete wrote:
 On Tue, 2005-28-06 at 07:20 -0400, Jon Portnoy wrote:
  On Tue, Jun 28, 2005 at 12:57:46PM +0200, Ioannis Aslanidis wrote:
   On 6/28/05, Shyam Mani [EMAIL PROTECTED] wrote:
   
   Does it really matter you if we are called developers instead of staff?
   
  
  Yes. You don't develop anything
 
 Neither do infra devs or doc devs...

I'd beg to differ there actually.
Infra developers are more often than not package maintainers etc as
well, and have cvs rights. if they don't have cvs rights, they look
after core infrastructure which is vital to Gentoo's survival.

Documentation devs, develop rather large and quite excellent online (and
offline) documentation.

Not to take away from the importance (or lack of depending on view) of
moderating the forums, but they are not as critical as official
literature and infrastructure, and also do not necessarily require in
depth knowledge of the technical aspects of any post.

Regardless, I would prefer the term Staff.

Also, I don't really see the need in having shell access to the
developer boxes. what use would this be?


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


[gentoo-dev] OffTopic: VMWare ESX

2005-05-04 Thread John Mylchreest
Hi All,

Apologies for posting my question to such lists, but it hits the exact
audience I'm after a response from :)

Does anyone at work run Vmware ESX Server? If so, could they please get
in touch with me so that I might talk about experiences?

Regards,
John

-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515 
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515
Web:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x9C745515


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


Re: [gentoo-dev] OffTopic: VMWare ESX

2005-05-04 Thread John Mylchreest
Hi there, thanks for getting back to me.

basically, What I was wanting to know is actual hands-on experience.
Whats it like? Pros? Cons? What to watch out for? what its exceptionally
good at? whats it exceptionally bad at? bugs? all the normal kind of
questions really. How is it so different to vmware workstation? what big
management (of guest OS and resource allocation) features are there?

Also, if you can, how you use it. what it is you do with it? Application
clustering? etc etc.

All the stuff which doesnt come out of press releases, reviews and
promos :)

Cheers, in anticipation :)
Regards,
John

P.S. DK, what happened last fall is water under the bridge.
Misconceptions all around, and glad to see your still here.

On Wed, 2005-05-04 at 15:12 -0400, Omkhar Arasaratnam wrote:
 John Mylchreest wrote:
 
 Hi All,
 
 Apologies for posting my question to such lists, but it hits the exact
 audience I'm after a response from :)
 
 Does anyone at work run Vmware ESX Server? If so, could they please get
 in touch with me so that I might talk about experiences?
 
 Regards,
 John
 
 
 
 John,
 
 I've worked with it before and have a number of colleagues in the field
 - what's up?
 
 --
 
 Omkhar Arasaratnam - Gentoo PPC64 Developer
 [EMAIL PROTECTED] - http://dev.gentoo.org/~omkhar
 Gentoo Linux / PPC64 Linux: http://ppc64.gentoo.org
 
-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515 
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515
Web:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x9C745515


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


Re: [gentoo-dev] OffTopic: VMWare ESX

2005-05-04 Thread John Mylchreest
Unfortunately it has to be vmware. Xen is excellent fro many things, but
this ESX server is considerably different to most things. Anyways, aside
from that the choice of product has been made. Just not the decision to
go with it. So that's what this is for. Some real life feedback.


On Wed, 2005-05-04 at 23:37 +0200, Jan Kundrt wrote:
 John Mylchreest wrote:
  basically, What I was wanting to know is actual hands-on experience.
  Whats it like? Pros? Cons? What to watch out for? what its exceptionally
  good at? whats it exceptionally bad at? bugs? all the normal kind of
  questions really. How is it so different to vmware workstation? what big
  management (of guest OS and resource allocation) features are there?
 
 *Really* OT here, but you may find Xen (http://xen.sourceforge.net/)
 interesting.
 
 -jkt
 
-- 
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key:  gpg --recv-keys 9C745515 
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515
Web:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x9C745515


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