Re: [gentoo-dev] Re: rejecting unsigned commits

2011-03-28 Thread Kumba
On 03/27/2011 22:47, Kumba wrote:
 Rather than mounting an expedition to find it, it's probably easier for me to
 generate a new key, but this raises a few questions, because I'm a complete
 idiot when it comes to GPG/PGP stuff:

This is all fixed.  My new key is published, but the old one will remain on the
key servers until I can hunt down the drive w/ the old revocation cert.

Will have to play with manifest signing next time I update mips-sources...

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org

The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between.

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Re: rejecting unsigned commits

2011-03-27 Thread Kumba

On 03/25/2011 14:30, Mike Frysinger wrote:

for people who dont have a key yet:
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=6

for people interested, bugs to get repoman extended to make the gpg
process smoother:
http://bugs.gentoo.org/360459
http://bugs.gentoo.org/360461
-mike


So I'm one of those that became a dev before GPG keys were required (I think). 
at some point, though, I created one on an old machine I had, which was my 
primary dev machine at the time.  But the machine died, and I never got the key 
off (I never used it).  The drive is still good, but it's lost in a pile of 
boxes somewhere.


Rather than mounting an expedition to find it, it's probably easier for me to 
generate a new key, but this raises a few questions, because I'm a complete 
idiot when it comes to GPG/PGP stuff:


1. How can I revoke the old key?  The revocation cert is probably on the same 
drive.

2. The dev manual states not to create a key with an expiration longer than 6 
months.  How does this impact items signed already if the key has to be replaced 
bi-annually? (I suspect I'm not fully grasping something here w/r to GPG).


3. If I'm going to start using GPG, I might as well use it for a few things. 
Anyone got pointers for cross-platform use, i.e., Thunderbird on Windows?


--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org

The past tempts us, the present confuses us, the future frightens us.  And our 
lives slip away, moment by moment, lost in that vast, terrible in-between.


--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-28 Thread Kumba

Kumba wrote:


I was talking to Alec last night in -dev (yes, I'm still alive), and I 
tossed out the idea of using metadata.xml instead of mangling the ebuild 
filename or even sticking it as the first line in the ebuild (as a 
hashbang or something gentoo-specific, for example).


Fleshing out more (And to solicit more thought on this idea -- insane?).

Using mips-sources as an example:

# ls -l /usr/portage/sys-kernel/mips-sources/*.ebuild

total 116K
-rw-r--r-- 1 root root  19K Jan  9 04:10 mips-sources-2.6.20.18.ebuild
-rw-r--r-- 1 root root  18K Jan  9 04:10 mips-sources-2.6.27.10.ebuild
-rw-r--r-- 1 root root  18K Feb 23 16:43 mips-sources-2.6.28.7.ebuild


Would, to specify them as EAPI=2 in metadata.xml, be encoded as (just an example 
-- suggest other formats):


eapi pv=2.6.20.18 ver=2 /
eapi pv=2.6.27.10 ver=2 /
eapi pv=2.6.28.7 ver=2 /

pv = specifies the package version
ver = eapi version.

Better names for these values? Suggest!  I didn't want to re-use 'api' or 
anything.  Maybe pms pv=2.6.28.7 eapi=2 / ?



Anyways, after commiting to gentoo-x86 CVS, a backend script, similar to or the 
same as whatever parses out the use tags will run and extract this data, and 
update /usr/portage/profiles/eapi.list  (example name).


/usr/portage/profiles/eapi.list will resemble something like this:

sys-kernel/mips-sources-2.6.20.18:2
sys-kernel/mips-sources-2.6.27.10:2
sys-kernel/mips-sources-2.6.28.7:2


Upon installing the package by whatever package manager (portage is my example), 
it will process this eapi.list, much like it does use.desc and use.local.desc, 
and therefore know all it needs to know, then it can source the ebuild and use 
whatever logic it needs to follow that specific EAPI.  That is if my assumption 
is correct that the usr.desc/use.local.desc stuff is parsed prior to the ebuild 
itself being sourced.  If not, well, I dunno then.  I'm guessing here.



The pros of this that I can see:
- No changes to the current filename structure.  Things stay the name, CVS 
history is retained because existing files aren't renamed (we're not on git just 
yet).
- No special markers, comments, or bash vars inside the ebuild.  Covers some of 
the other cons that were presented.
- Older package managers won't read eapi.list, and can resume their default 
behavior of EAPI=0.  Allows backwards compatibility.
- Newer package managers will assume a non-entry in eapi.list to equal EAPI=0, 
so there won't be a big rush to update every package/metadata in the tree. 
Allows for slow, controlled adoption.


Cons that I can see:
- metadata.xml gets updated more frequently because specific versions can get 
cited (workaround idea, see below)
- Backend has to do extra work (minimal?  Can infra comment on the feasibility 
of this?)


I'm suggesting this mostly because both ideas of embedding the EAPI value in the 
filename and inside the ebuild seem like ugly workarounds.  Others are also 
noting other problems with both of these approaches.  EAPI also feels more like 
a metadata-type thing anyways.  I mean, if we're already storing local USE flags 
in it, why not EAPI stuff?  I'm a tad behind on the whole discussion, I know, 
but why not toss the idea out there.



Some other thoughts on the first con, of metadata being updated more frequently 
-- we allow the use of wildcards:


eapi pv=* ver=2 /
Would mark every ebuild in the directory for a given EAPI value (EAPI=2 in this 
case)


eapi pv=2.6* ver=1 /
Marks every ebuild version lower than 2.6 as EAPI=1.

Basically, the wildcard modifiers Portage currently understands would apply.  Or 
we could limit it to a subset of these wildcards (say, *, , , =, and =).



Obviously, tools like repoman would need to be able to read metadata as well 
(can it?  I don't know) and make sure that the versions specified in the 'pv' 
value exist in the directory before commit.  Either by specific value or by 
expanding the wildcard notation and then cross-referencing the files listed in 
the directory and with CVS/git/whatever.



But to be honest, none of the ideas, even my own, seems like the best idea.  I 
think of mine as less intrusive to the tree and less visible to the end users 
and the package managers, but maybe there's other options not thought of yet?


--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org

The past tempts us, the present confuses us, the future frightens us.  And our 
lives slip away, moment by moment, lost in that vast, terrible in-between.


--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-25 Thread Kumba

Petteri Räty wrote:

Let's try something new. I would like to get opinions from as many
people as possible about GLEP 55 and alternatives listed here in order
to get some idea what the general developer pool thinks. Everyone is
only allowed to post a single reply to this thread in order to make it
easy to read through. The existing thread should be used for actual
discussion about the GLEP and the alternatives. This should be a useful
experiment to see if we can control ourselves :)


I was talking to Alec last night in -dev (yes, I'm still alive), and I tossed 
out the idea of using metadata.xml instead of mangling the ebuild filename or 
even sticking it as the first line in the ebuild (as a hashbang or something 
gentoo-specific, for example).


It's nothing fully fleshed out, and I know parsing XML is about as much fun as 
sticking your tongue into a cross-cut paper shredder, but I figured why not toss 
it out there?


Add a tag like this to metadata.xml

eapi pv=2.6.28.7 version=1 /

pv = Package Version (incl. revision if needed).
v = EAPI version.

Other variants:
eapi version=1mips-sources-2.6.28.7/eapi
eapi pv=2.6.28.71/eapi

and such.

This allows portage or whatever to associate the chosen/desired EAPI level with 
a given ebuild version in portage (so the above examples would match 
mips-sources-2.6.28.7.ebuild)


I think there's some other magic going on after metadata is updated in portage, 
like the whole use.local.desc auto-updating.  I figure something like this could 
also be implemented, maybe even in the same way whereby a backend script parses 
this out and create a /usr/portage/profiles/eapi.list file that links package 
revisions with the set eapi level.  Then let the various package managers do 
whatever it is that they do to make use of this information.


Call it random brainstorming.  No idea on the pros  cons -- I haven't even 
looked at g55 just yet.



--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org

The past tempts us, the present confuses us, the future frightens us.  And our 
lives slip away, moment by moment, lost in that vast, terrible in-between.


--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] Of Mips and Devs [Was: Monthly Gentoo Council Reminder for January]

2008-01-10 Thread Kumba

Mike Frysinger wrote:


that certainly sounds reasonable to me.  if the stable cant be maintained, let 
the common workflow of developers transition it back to ~arch until someone 
has the time to keep arch usable.  changing profiles.desc accordingly should 
be done ahead of time.  perhaps a new category for profiles.desc ?  exp for 
such ports ?  i could see all *-fbsd ports being moved there.  tweak repoman 
to be less verbose about dep issues for such profiles and we're set.


Sounds like a plan.  'exp' would be the 'status' field?  I need to remove 
2006.1, as that profile has been a big holdup due to it not being glibc-2.4 
friendly (or one of the newer glibcs back in that era; I forget).  Even 
pondering just outright booting 2007.0, as I've been using 2007.1-dev since I 
commited it long ago, and haven't had an issue with it really.  I can then put 
2008.0-dev together and use it as a launch platform for ~arch migration.




i see dropping keywords as a very last resort.  getting a port *back* into the 
tree is a *tremendous* amount of work (i went through it and it was hell), 
while keeping ~arch alive is a sliver of effort and generally not a blocker 
for package maintainers.


Aye, I believe that was sh's removal and subsequent re-add?

Part of the hangup lately has been our kernel support.  O2 systems are dead in 
the water in 2.6.24, and only work in 2.6.23 if you apply a hack to serial_core 
(a hack that only masks a problem rather than fixes it).  Octane's I can still 
forward port, but with the upstream author having moved onto other interests, if 
something breaks badly enough from one version to the next, then I run the risk 
of getting stuck on a particular version permanently.


Indigo2 R1's may wind up getting resurrected, as support for that is 
actually headed into upstream now, so it'll be the end of patching for that 
system.  Though the gcc patch needs fixing.


And I'm really considering dropping our mips3 (Indigo2/Indy R4x00) support to 
cut back on the number of stages and netboots pumped out (-3 and -1, 
respectively, when they get pumped out).  R4x00 is an odd CPU, with a ton of 
variations, and of them, only the R4400 ever seems to work well at all.


The hard part is finding time and motivation.  My attention span lately has been 
worse than a goldfish's.  That said, however, profiles should be doable come the 
weekend, at least for removing 2006.1, renaming 2007.1, and pondering 2007.0's fate.



--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

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



Re: [gentoo-dev] Of Mips and Devs [Was: Monthly Gentoo Council Reminder for January]

2008-01-09 Thread Kumba
 we support (but to make it easy, just acquire an Octane), so e-mail me 
and ask whatever questions you need to know.




3. Should Gentoo even continue to support mips?  Do people even *use* mips?

My opinion is that yes, we should continue to support mips.  Ultimately, I'll 
leave that decision to the higher authority, but I think if a new team can be 
assembled, and I can be allowed to step aside to more of an advisory role, that 
mips can function normally again.  And maybe, regain some of the respect we've 
lost over the years for various reasons.


As for whether we even have users, I can say affirmatively that we do.  Not many 
for sure, like say Sparc or PPC, but we do.  Part of the problem with this is 
our area of focus.  The Mips Team really only focuses on SGI Hardware, because 
this hardware is readily available on eBay, and usually at good prices.  Mips as 
an architecture spans a swamp-load more of various devices.  Everything from a 
PSP to your cable modem is usually run by some variant of a mips processor.


However, I made the decision long ago to only focus on the workstation hardware 
because I wanted Gentoo to be the User's Distro on these machines.  I didn't 
want us to run off and support these obscure development boards that cost an arm 
and a leg, and are only available to very specific individuals who just happen 
to know the right people.  Lord knows the SGI machines alone keep things 
interesting as far as support matrices go.


But largely, Linux/MIPS leaves people with two choices for a distribution: 
Debian or Gentoo.  And while I give props to the Debian people for keeping the 
mips binary world alive, I don't think it'd be right for us to pull out and 
reduce those choices to one.  After all, Gentoo is all about letting the users 
have choices, right?





So there you all have it.  My thoughts, my opinions, my apologies.  In the end, 
I'll go along with whatever the rest of the distribution wants to do to rectify 
things.  After all, most of it stems from my own inactivity, by and large, and 
that hasn't made us a lot of friends around here.  So it's time to fix that, and 
put an end to all this pointless, utterly stupid bickering that drives away some 
of the best talent we have.


Besides, BSG returns in two months.  I will probably become more scarce than 
George Carlin at Catholic Mass when that happens, permanently affixed to my 
television trying to grok whatever crazy stuff Moore throws out in this final 
season.


So, thoughts?


--Kumba

--
Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

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



Re: [gentoo-dev] New lists and their usage

2007-07-20 Thread Kumba

Chris Gianelloni wrote:


gentoo-projects: This list is for... what exactly?  I've not really
figured that one out just yet.  I know it is supposed to be pretty much
anything that doesn't fit into gentoo-dev or another project-specific
list.  Am I correct here?  Is this what everyone thinks this list is
supposed to be used for?


I figured my explanation in Bug #181368 was enough to get the idea across, in 
that, anything non-technical goes here.  Loosely translated, and based on my 
understanding from a debian developer on what winds up on their debian-project 
list, it pretty much means everything else.


Whether that's what really becomes of the list, I dunno.  That's part of the fun 
for me.  I guess what I current envision is it becoming what -dev is today, 
minus all the technical discussions.



--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] have any developers subscribed to -project?

2007-07-20 Thread Kumba

Jakub Moc wrote:


 _   _   _   _ _
| | | |/ ___| | | | |
| | | | |  _| |_| | |
| |_| | |_| |  _  |_|
 \___/ \|_| |_(_)



Stop flooding my mailbox as well with this irrelevant junk finally, it's
totally off-topic here; if you want to complain that noone loves you,
then go to your nanny, I'm not interested.



Steev Klimaszewski wrote:

No, we complain about non-technical posts showing up here... and guess
what  is... please take it to -project if it isn't technical.



Mike Doty wrote:

In case you're too clueless to understand my sarcasm, get this shit off the
list and somewhere appropriate.  /dev/null would be a good start.  When there
are topics devs are interested in on -project then they will join and
participate.  You complaining isn't something anyone other than yourself is
interested in.



Guys, this is unnecessary.  He asked a legitimate questions, even if it *was* 
offtopic.  The -project list was created only a few days ago.  We've had -dev 
for years.  Changes are not going to happen overnight, or even in a week.  It'll 
take some time, and require some education on our part to point people (devs and 
users alike) to the right lists.  Yelling at them, or otherwise cursing (even if 
it was sarcasm) is not gonna get the job done.


Let's try to be cordial about it, k?  Besides, I saw this neat little blurb 
looking at debian's ML CoC:


* Do not use foul language; besides, some people receive the lists via packet 
radio, where swearing is illegal.


* Try not to flame; it is not polite.


So yeah, stop swearing before the authorities come after us for swearing over 
packet radio! :P




--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] So...

2007-07-17 Thread Kumba

Doug Goldstein wrote:

So it's 97 degrees outside.. it's pretty hot... Since everyone loves to
debate non-technical things on this list.. Let's debate Fahrenheit vs
Celcius...

Discuss!


Pft.

Rankine and Kelvin, FTW!


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Getting -project started

2007-07-17 Thread Kumba

Petteri Räty wrote:

I have seen no real opposition for the creation of the -project mailing
list and even this ML changes thread itself involved the creation of the
-project mailing (the thread itself is a prime example on why we need
-project in the first place) so how about we just get that mailing list
going right no and let the rest of it fall into place later. My guess is
that if we would have had -project for ages, the need for moderating
-dev would have never come about. I bet there are devs who have talked
about creating this kind of a list months, even years ago. This time
it's not about show me the code but show me the mailing list!


I'm not sure on the history of a non-technical ML itself, but I cooked up the 
idea of gentoo-politics originally, thinking the similarly-themed debian ML was 
debian-politics.  After a debian developer pointed out that it was actually A) 
debian-project, and B) He intentionally stays off that list (obviously for good 
reason), I figured the name and non-requirement for developers was most 
appropriate for our needs as well.


Hence, Bug #181368 was born.

And apparently, so was ML Changes.  Guess the doctor neglected to mention that 
I was having twins, and that one of them was gonna grow up to be overweight and 
ugly, yet incredibly hot.


Healthcare really has gone down the drain here in the UDG, hasn't it? (United 
Developers of Gentoo).  Anyone care to recruit Moore as a developer?


Anyone???



--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Getting -project started

2007-07-17 Thread Kumba

George Prowse wrote:


So that would mean that welcoming new developers would be on the 
-project list?


My thinking, I think they would fit better over there, since it is somewhat 
non-technical.  However, machine-generated notices of dev arrival or dev 
departure could be directed to other lists.  There's been talk of a 
-dev-announce list as well; perhaps such automated messages of dev changes could 
be sent there in a fashion (either individually as one joins or one leaves, or 
in a weekly digest form summarizing the changes).



Would package removals be on it because it seems to be somewhere in the 
middle?


I think package additions/removals should stay there, since they are development 
related, such as the removal due to bitrot or an unfixiable security flaw, etc. 
 Such messages might also be candidates for the above mentioned -dev-announce 
ML as well.




--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: Nominations open for the Gentoo Council 2007/08

2007-07-17 Thread Kumba

Ryan Hill wrote:

Torsten Veller wrote:

| for the quick low down:
|  - nominations are from July 1 through July 31
|  - anyone can nominate
|  - only Gentoo devs may be nominated
| 
| so get with the nominating people !


I noticed Kumba isn't nominated, so I'll throw him into the ring.


I'll decline for this year; I'm content to hide over in MIPS land and toss out 
random ideas from behind the safe shadows of an Origin 2000 cluster...


Thanks for the nomination, though!


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Getting -project started

2007-07-17 Thread Kumba

Philip Webb wrote:


To this user since 2003, who plans to install Gentoo in the new machine
which I am presently designing, this sounds like a very welcome development.
I shall continue to subscribe to -dev , but not to -project.
Should I also subscribe to -dev-announce
or will its msgs be duplicated on -dev ?


Think of it as a filter; important things that are announcement-worthy will get 
sent to -dev-announce, for people who want to keep on top of things w/o the 
background noise.




Hopefully, all the devs can now get back to making Gentoo even better,
for which volunteer work I continue always to be grateful.


I, for one, welcome our new volunteering developer Overlords! /slashdot



--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] laying out arch profiles

2007-07-15 Thread Kumba

Chris Gianelloni wrote:

On Thu, 2007-07-05 at 18:47 -0400, Mike Frysinger wrote:
you proposing we rearchitect it all or just for testing purposes before going 
live ?  i can see both ...


I am proposing rethinking all of it.  My current thoughts run something
like this:

arch/amd64
arch/ppc (not ppc/ppc64 or ppc/ppc32)
base
default/linux
default/freebsd
default/macos
kernel/darwin
kernel/linux
kernel/freebsd
release/2007.1
target/desktop
target/server
userland (these aren't all the same type of thing)
userland/32-bit
userland/64-bit
userland/multilib
userland/freebsd
userland/hardened
userland/linux (this could be glibc, instead)
userland/macos
userland/no-nptl (not sure we really need this, at all)
userland/nptl (this either)
userland/selinux
userland/uclibc

Of course, this is just my rough outline.  What you would end up with,
as a profile, is something like this:

default/linux/amd64/2007.1/desktop (not much different from now)


I kinda thought up a system like this long ago, but it was more in line with 
node-based profiles.  And wou;d've required gutting the current profile code in 
portage entirely.  The idea being that, you construct the profile up in nodes 
from the top level (much like one does their PATH variable), and the profiles 
would be re-arranged into things like arch/, libc/, kernel/, etc..  In a way, I 
re-organized mips' 2007.1-dev profiles to quasi reflect how we'd look in such a 
layout.


But I like this idea -- it goes halfway towards nodes to some extent (at least 
lines things up for nodes or some other implementation that maybe treats parents 
better).


antarus even had a small draft document up on it that's better in detail:
http://dev.gentoo.org/~antarus/essays/mixin-profiles.txt
(later on, it was decided that there would have to be a pre-defined order for 
the first four nodes: base:arch:kernel:userland, and these first four nodes 
could not repeat.  Everything thereon after was swappable and allowed to be 
placed in any order, such as base:mips:linux:glibc:ip30:o32 (where o32/ip30 can 
be swapped around))


But I definitely see this as a 2008.0 thing at the earliest.  I also see no 
problem with mips joining in on the fun to play with things either!



--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: ML changes

2007-07-15 Thread Kumba

Duncan wrote:


I like the gentoo-project (yes, that's better than politics) idea as 
well, and believe it /could/ solve the problem here, given a couple 
conditions are met.


One, -project is not to be required reading for devs as -dev is.  Devs 
(and others) can ignore it if they wish.


Two, people be consistent about telling folks to go to -project when it 
goes OT, setting the followup-to/reply-to.  Telling folks much of the 
current discussion doesn't belong in -dev doesn't help now, because 
there's nowhere to send them.  Once there is, simple no further replies 
here, this belongs on the gentoo-project list, no name calling, no 
further discussion, just that, if enough current regulars do it, should 
dramatically decrease the noise level here.


Already since the idea was proposed, I've wished the other list was up 
and running, as there are posts I'd have posted there rather than here, 
this whole thread could have gone there (except one would hope it 
wouldn't be needed then), etc.  I really think it can work... because 
I've seen it work on other groups and mailing lists before.  It just has 
to be implemented.  Then, if after a month or two it's not working, /
then/ I'd say it's time to consider bringing in the big moderation guns.  
But I think it can and will work without those guns, provided we give it 
the chance and effort to make it so.



Just a reminder, Bug #181368 is the bug I filed for the -project ML over a month 
ago.  I just updated it with a suggestion that -project not be required 
subscription for new devs, just that new devs need to be informed of both its 
existence and purpose (this was left out of my original submission).


Those interested may want to add themselves to the CC list to track any 
developments that happen there (assuming the fire doesn't spread).



@Council
As for the rest of thisthread..., mayhaps it would be wise for Council and 
Infra to postpone the moderation idea for a few months? (let 2007-2008 council 
handle the matter)  As this really isn't the kind of thing we should be pulling 
during a council/trustee switch out (just look at the size of the thread).


@Infra
In what may be appropriately considered a vain attempt to end this thread, can 
we just go ahead and create -project, and give it a few weeks to see what 
happens?  Worry about -dev and moderation later on.



Cheers,


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] ML changes

2007-07-13 Thread Kumba

Robin H. Johnson wrote:


I won't leave just because I disagree with some management decision that
Council makes. I might be stubborn and disenchanted for some time
(witness the many murmurs of discontent), but it's against my own best
interests to leave Gentoo. As it was put before, if you leave, the Fungi
will win.


for (i = 0; i  SOME_BIG_NUMBER; i++) {
plusplus();
}


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] ML changes

2007-07-12 Thread Kumba

Olivier Crête wrote:

On Thu, 2007-12-07 at 13:24 -0700, Mike Doty wrote:

We're going to change the -dev mailing list from completely open to where only
devs can post, but any dev could moderate a non-dev post.  devs who moderate in
 bad posts will be subject to moderation themselves.  in addition the
gentoo-project list will be created to take over what -dev frequently becomes.
 there is no requirement to be on this new list.


What are the proposed guidelines for the different between -project and
-dev? What goes where?


See Bug # 181368, where I initially proposed gentoo-project.


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] ML changes

2007-07-12 Thread Kumba
 sparingly. 
Not used as a blanket cover, with the occasional someone lifting up that blanket 
to peek outside (save that for the monster under the bed).  That said, however, 
I don't think we should totally dismiss the idea of blanket moderation.


Rather, I think we should first implement -project, put out enough information 
to get people to use it, and watch it for a few months.  By and large, we may 
discover that simply giving another list for the non-technical discussions may 
fix the problems on -dev, and moderation won't be needed on either list.  If, on 
the other hand, problems still arise on -dev that -project did not address (or 
may've been potentially created by -project's creation), then we can revisit the 
option of blanket moderation then.


Simply put: One Step At A Time.



Cheers,

--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands
do them because they must, while the eyes of the great are elsewhere.  --Elrond
--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] ML changes

2007-07-12 Thread Kumba

Kevin Lacquement wrote:


I'm not sure about stuff in -core becoming publicly accessible.  After 
all, isn't it in the private list for a reason?  Perhaps summaries of 
-core discussions being forwarded to -dev would be a better option. 
However, I'm new to -dev, so if this is what already happens I don't know.



It's been a topic debated off and on on whether or not to keep -core locked away 
forever, but face it, even the CIA declassifies its dirty laundry every so 
often.  Now I'm not saying we should hold onto -core material for 30+ years, but 
I see no point in forever locking up the information on -core.  At minimum, it 
provides a historical look into how developers used to think.  Equally, this is 
why we need a sufficient time gap to let a majority of topics die off on -core 
before they become fodder for public consumption.  And why a marker being 
available to permanently lock certain threads/messages as needed.





Here's where we want the non-devs to get access.  After all, not all 
development and debugging is done by devs.  All the current devs were, 
at one point, users.  Where did they get their start?  My bet is they 
entered via the -dev mailing list, learned the ropes here, and 
eventually earned their dev status.  If the -dev list is closed, where 
do the new dev-wannabes learn the ropes and get their voices heard?


You missed the small mention of open in my first sentence.  I probably should 
have clarified what my definition of what open is, but it pretty much means no 
moderation on the -dev list so that users and developers could post.





Would it perhaps be better to send announcements to -dev-announce, and 
have that list forward to -dev?  That way we avoid issues if a subject 
starts with [ANNONUCEMENT], for example



-dev-announce is a list proposed by another developer, and it's got its own bug 
number someplace (don't have it on hand ATM, however).  And technically, you 
wouldn't be forwarding the -dev-announce messages to -dev, because -dev-announce 
is essentially acting as a filter to -dev.  -dev would, in theory, contain ALL 
technical discussion related to the project.  -dev-announce would contain all 
announcements of certain, specific, technical things occurring within the 
project (and already talked about on -dev).  As a result, someone posting to 
-dev and wishing that post to also be forwarded to -dev-announce would attach 
[ANNOUNCEMENT]: to their subject line.  Not all devs are gonna wanna get into 
discussions, even technical ones.  Thus they can still monitor -dev-announce to 
keep abreast of things.


This method is no different really from the art of prefixing [PATCH]: to the 
subject line of an email on a kernel development list (or development list for 
any other software project) to indicate that the contents of the email includes 
a patch.  Even for LKML and linux-mips, there are tools in git that can target 
emails marked at patches, and automatically perform various feats of magic on 
them (such as stuffing the patches into a git queue of sorts).


This is why I don't think we could expect many problems from an announcement 
message.  Presumably, an announcement message would not be put out unless it'd 
already been discussed.  History, however, shows us that this is not always the 
case.  Thus, if some kind of a discussion were to arise from some kind of 
announcement, it likely wouldn't get forwarded to -dev-announce anyways (since 
replying to a mail would read as Re: [ANNOUNCEMENT], and it wouldn't get 
picked up by the automated mailer).  Furthermore, the -dev-announce list can 
probbaly be locked to only accept inbound mail from a specific host or address, 
itself tied to a script or bot of some kind.  If someone accidentally sent a 
message to -dev-announce, they would get a bounce back of some kind.





If these messages will be machine-like, why not have them 
machine-generated?  When you become a dev, someone (you?  the person 
that -dev-ifie's you?) fills out a form, and the information from the 
form is forwarded to the list.


We could automate it possibly, pulling data from the LDAP system used to auth 
devs to a number of gentoo systems.  Or someone in devrel could just take a few 
seconds to fill out a few fields in an email template and hit send.  I said 
impersonal because my mind is thinking technical == dry, white-paper-like 
material.  Either method works. but it's just a suggestion.  The more personal, 
emotion-filled (and I don't mean negative emotion-filled either) ones could go 
elsewhere, like to -project or such.



Cheers,


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] ML changes

2007-07-12 Thread Kumba

Kevin Lacquement wrote:


Sorry, I should have made it clear - I was agreeing with you there.  I'm 
not a -dev yet, but if I continue to have the time to work towards it, I 
don't want to be blocked because someone decided that users couldn't 
give insights to the developers list.


Ah ha, then yeah, some of our devs come from the list, and if it becomes more 
technical by shuffling non-technical discussions elsewhere (mostly), it might 
help to filter out good candidates for new devs.


Course, the mailing lists alone aren't the only source; I've picked up devs 
straight off IRC, and I know of others who came on board solely through bugzilla 
contributions.  So there are many alternatives.



Cheers,


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] glibc-2.6 / gcc-4.2 going into ~arch

2007-07-07 Thread Kumba

Mike Frysinger wrote:

get your waaait dont do it votes in now, i plan on pushing:
glibc-2.6 ~amd64 ~ppc ~ppc64 ~x86
gcc-4.2.0 ~amd64 ~x86
in the next day or so
-mike


FYI, seems one of the R10K patches fails for mips after all (compile failure 
below).  Probably a define that shifted and I'll have to go trace it down.  So 
no unstable for us for now.



../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
libbackend.a(options.o):(.data.rel.ro+0x4774): undefined reference to 
`TARGET_R10K_SPECEX'
libbackend.a(options.o):(.data.rel.ro+0x4914): undefined reference to 
`TARGET_R10K_SPECEX'
libbackend.a(options.o):(.data.rel.ro+0x4934): undefined reference to 
`TARGET_R10K_SPECEX'

libbackend.a(mips.o): In function `check_p_pattern_for_store':
mips.c:(.text+0x3520): undefined reference to `TARGET_R10K_SPECEX'
libbackend.a(mips.o): In function `mips_reorg':
mips.c:(.text+0x6a64): undefined reference to `TARGET_R10K_SPECEX'
collect2: ld returned 1 exit status
make[3]: *** [cc1-dummy] Error 1


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] gentoo-dev-announce list

2007-06-21 Thread Kumba

Donnie Berkholz wrote:

Hi all,

I'm back for my yearly posting about creating a gentoo-dev-announce
list [1]. Fedora recently created a fedora-devel-announce list with a
great description of how it works, what's posted to it, etc [2], which
got me excited about making this happen in Gentoo.

Last time the issue came up, numerous people supported it, but nobody
followed through to get the list created. This time, I'm going to file
a bug to the infra team to make it happen.

What's this mean for you? If you want to ignore -dev, you can just
subscribe to -dev-announce. But you will lose your ability to
participate in discussions leading toward decisions. If you have an
announcement relevant to development, post it to both -dev
and -dev-announce. Replies will go only to -dev.

Thanks,
Donnie

1. http://archives.gentoo.org/gentoo-dev/msg_136761.xml
2.
https://www.redhat.com/archives/fedora-devel-announce/2007-June/msg0.html


++ here.

Heck, I'm aiming for a -project list, and I see benefits in this too (details of 
reply-to munging discussions aside).  So what's the harm in subscribing to a few 
more MLs?



--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: [RFC]: gentoo-politics ML

2007-06-12 Thread Kumba

Duncan wrote:

Kumba [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted
below, on  Mon, 11 Jun 2007 21:25:14 -0400:


It's competition, at the core.  No one likes draws, ties, or even photo
finishes, let alone losing.  They like to win, and win by a large
margin.  If someone tries to slip the last word in to get them over that
virtual finish line, rest assured someone else is gonna fire off an even
more last word just to one up them, and when we're talking mere microts
from the finish line, sometimes the gloves come off.

Besides, it's not like a +2 Great Darkwood Crossbow of Acid is all
_that_ expensive.  Probably a pain in the neck to load (and the kickback
has to hurt), but well it just means you need to level up some more :)


Wow, talk about mixed metaphors!  Foot-racing  boxing  ADD.  You've 
got gumption to try and pull /that/ off! =8^)  I guess it works, tho, if 
you don't try to stretch any of them beyond the limited area they were 
applied to (which this sort of case begs... resist... resist... =8^) .


Metaphors tend to be my palette; sometimes I create art, and other times I 
create things that make goatse look tame :P




(And yes, this'd go on the other list, if we had it.)


It's in Infra's hands now.  They've got a bug filed, and so, I leave it up to 
them.

Regardless on if it's created or not, this thread has made people think, I hope. 
 And maybe that's all we really need in the end, is for a few people to simply 
stop and think.


I hope.


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: [RFC]: gentoo-politics ML

2007-06-12 Thread Kumba

Steev Klimaszewski wrote:


So this other list would allow non-civil discussions to continue and
rage on?  I mean, you wouldn't have to be civil to others on it, you
could just join and start trolling everyone?


Read the bug I filed with infra.  You'll find the answer to this there.


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: [RFC]: gentoo-politics ML

2007-06-11 Thread Kumba

Brian Harring wrote:


Guess I'll be the killjoy, and throw in the -1 on it.

Reasons are pretty straightforward (at least to me):

1) Creating such channels is just attempting to shift the problem out 
of sight.


Not out of sight, just to an arena where it is more suitable.  When I joined 
Gentoo long ago, I was told that there were two required mailing lists that we 
had to be on: gentoo-core, for private, developer-only discussion whose contents 
are (normally) kept from the prying eyes of our endearing public, and 
gentoo-dev, a developer/user mailing list for development-related questions 
regarding all things Gentoo.


When -dev evolved/de-evolved (your pick) into being technical  non-technical 
in nature, I'm not sure.  I was either asleep, or entertaining myself with other 
things.  If I had to haphazard a guess, I think it simply Just Happened 
because all devs are automatically subscribed, therefore, when someone has 
something to say, they stand a high probability of it getting heard by a lot of 
people.  No point in tootin' off your horn if no one's around to hear, ja ne?



2) Shifting said problem into a concentrated arena means the incidence 
of idiot conflicts/trolling/needling/whatever is likely to increase


This is possible, but I'll point out that one can also have non-technical talk 
about all things Gentoo without everyone de-evolving into little charmanders 
about it.  Quipping an example from the debian-project ML, a discussion on the 
validity of Condorcet voting would be a non-technical topic of discussion that 
can be discussed (hopefully without igniting).  And that is a topic I know we've 
broached before.


If people just act like adults for once, we can actually keep the flames 
controlled.  Note that I'm not saying it'll stop the flames, only that they can 
be controlled.



3) said increase means proctors/devrel have more work (meaning more 
random outbursts at the proctors/devrel when folks realize that they 
*are* going to enforce the behaviour rules, and that the outburstes 
can be punished too).


Not many people like authoritative figures, no matter the uniform or creed.  I 
guess it's just how we're wired.  Free Will and all that jazz.  Frankly, no 
matter what an authority-empowered group does, whether it is for good intentions 
or not, someone out there will cry foul about it, and raise a whole lot of 
ruckus over it.  devrel's not perfect, but they're not inherently evil or 
anything either.  They're given a task to do, and why people make such a fuss 
over it baffles me.  I guess that's why I tend to not pay attention to those cases.



4) look through -dev history; the issue isn't OT discussion, it's 
people needling/harassing/trolling/(chose your verb) kicking off yet 
another mine is bigger last word battle on the ml.


It's competition, at the core.  No one likes draws, ties, or even photo 
finishes, let alone losing.  They like to win, and win by a large margin.  If 
someone tries to slip the last word in to get them over that virtual finish 
line, rest assured someone else is gonna fire off an even more last word just to 
one up them, and when we're talking mere microts from the finish line, sometimes 
the gloves come off.


Besides, it's not like a +2 Great Darkwood Crossbow of Acid is all _that_ 
expensive.  Probably a pain in the neck to load (and the kickback has to hurt), 
but well it just means you need to level up some more :)



Basically, what does this solve?  If the intention is to create an OTW 
equivalent for the forums, sure, go nuts, but I strongly doubt it'll 
improve things on -dev.


So what is the explicit purpose of this?  Honestly assumed it was just 
a joke at debians expense initially, but folks seem to be serious 
about it...


I didn't intend it as a joke.  Yes, I interspersed some sarcasm in my original 
response (As I often do in many of my responses), but that doesn't detract from 
the seriousness of it.  Put honestly, I don't really read -dev any more.  I 
barely even glance at -core.  I've missed stuff like new USE flags, interesting 
GLEPs, new devs coming in, old devs going out, etc.  Why?, because the signal to 
noise ratio was worse than my cable connection on a bad day, and at some point, 
I just got turned off by it all.  Probably much in the same way why I don't pay 
much attention to the wars going on the world.  Right now, I find news reports 
on changes in traffic patterns to be more exciting.


And I looked to debian for inspiration on this because they've had problems like 
this before.  A few of their developers sit in the linux-mips channel, and while 
I don't know what lists they're all on, one of their devs told me debian-project 
is one he stays away from.  I guess I'm a bit like them; I like the technical 
discussions more than the expertly-crafted responses tossed back and forth in 
the many flame wars that pop up on here.  And so, I decided to do something 
about it for once.



--Kumba

--
Gentoo/MIPS

Re: [gentoo-dev] [RFC]: gentoo-politics ML

2007-06-08 Thread Kumba

Philip Webb wrote:

070607 Kumba wrote:

what should we call it?  Vote on this!


If users have votes ...


Since I'm pretty much the pikachu-loving nutball that proposed this, I don't see 
why not.  Users are as much a part of Gentoo as the developers are.



--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [RFC]: gentoo-politics ML

2007-06-08 Thread Kumba

Kumba wrote:


So I'm told debian has one of these types of MLs, probably where the 
flames burn bright enough to have earned a star designation from the 
IAU.  Given what's been going on lately, and with calls from myself and 
others (i.e., mcummings) to get back on track and actually like, you 
know, develop something, I think it's high time we create this list 
ourselves.

[snip]


Anyways, thoughts?


Bug #181368 is filed.  Those seeking this reply-to non-munging will probably 
want to post a note there and let infra decide on that matter.


Lets try and make this work, k?


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [RFC]: gentoo-politics ML

2007-06-08 Thread Kumba

Mike Doty wrote:

George Prowse wrote:

Kumba wrote:

Kumba wrote:

So I'm told debian has one of these types of MLs, probably where the
flames burn bright enough to have earned a star designation from the
IAU.  Given what's been going on lately, and with calls from myself
and others (i.e., mcummings) to get back on track and actually like,
you know, develop something, I think it's high time we create this
list ourselves.

[snip]

Anyways, thoughts?

Bug #181368 is filed.  Those seeking this reply-to non-munging will
probably want to post a note there and let infra decide on that matter.

Lets try and make this work, k?


--Kumba


I say, just to be ironic, let the proctors decide and not infra :D

just to be ironic, infra makes the decision on new lists :Q



0wned.


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



[gentoo-dev] [RFC]: gentoo-politics ML

2007-06-07 Thread Kumba


So I'm told debian has one of these types of MLs, probably where the flames burn 
bright enough to have earned a star designation from the IAU.  Given what's been 
going on lately, and with calls from myself and others (i.e., mcummings) to get 
back on track and actually like, you know, develop something, I think it's high 
time we create this list ourselves.


What goes on it?, why the flames of course.  Every last ember, hot coal, glowing 
developers, and any kittens having reached critical mass.  We leave the new 
developer introductions on -dev, but any developer leaving and wanting to say 
goodbye, should consider posting their bit on -politics, because that's lately 
been the reason for leaving.  Anything hot button, hot topic, divisive, 
non-development, etc.  Especially license debates.  Ohhh yes, the license 
debates definitely belong here.


This'll probably kill -dev off completely, unless we start developing again. 
But hey, I for once wouldn't mind a quiet gentoo-dev folder in my thunderbird 
client.




So who's up for it?  We can even divide ourselves into Red Devs and Blue Devs! 
Blue Devs will, of course, be liberal, very energy conservative (i.e., no 
Octanes for you guys!), Pro-Choice (Portage or Paludis or Pkgcore, it's a dev's 
right to choose!), and most importantly, they'll favour any legislation from the 
Council that bans devs from smoking.  You know, the kind of smoldering that 
happens before a dev bursts into flames?


And the Red Devs?  Well, they'll be on the other side of the fence.  They'll 
blow the electric bill like the space shuttle burns fuel.  They'll also be 
Anti-Portage (it's Paludis/Pkgcore or else).  And the flames?  We're talking 
Firebats from StarCraft here.  Need a light?


See, this is fun already!  We can hold debates where one side rips the other, 
conventions where the egos of one side get inflated bigger than the Hindenburg 
(and lots of confetti is thrown about), And maybe even a few scandals, like 
discovering one die-hard Blue Dev secretly runs a 8-way Opteron system with a 
15-disk RAID6 array and 5 CRT monitors, or something.


We will have to fill a few positions, though.  We'll need a flip-flopper for 
starters (the one dev who randomly changes his opinion when cornered).  We'll 
also need a dev who skipped the Freenode War a year or two ago (when Bantown 
attacked, and they ran away screaming because of the netsplits and Squits and 
lilo impersonators).  And maybe a dev who secretly dabbles in another OSlike 
Wind...err, Ubuntu!



So anyways, I'm all for this list, humour aside.  It's blatantly obvious people 
need a place to vent at times, and I think that by separating the politics from 
the technical discussion, it might help in some way.  Yes, it'll also be the 
source of many problems too.  I can't envision what they might be, but I know 
they'd exist.



Anyways, thoughts?


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [RFC]: gentoo-politics ML

2007-06-07 Thread Kumba

Christian Parpart wrote:


+1 here too


possible alternative names: gentoo-soap, gentoo-gossip ( not to be
confused with net-im/gossip )


gentoo-soap, lol!


And these are the Flames of our Lives...


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [RFC]: gentoo-politics ML

2007-06-07 Thread Kumba

Luca Barbato wrote:


I'm ok with it, just I'd like to have it available as gentoo-fortune please.

(btw I'd like to see the quotebot back from the old ages!)


Oh, I could easily see the quote package for gentoo-politics (or whatever its 
called) raising much laughter (among other things).


And yes, the quote bot needs to return!  So I can stop storing quotes in my bot 
hiding off on another network :P



--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [RFC]: gentoo-politics ML

2007-06-07 Thread Kumba

Marius Mauch wrote:


Do you really think people would voluntarily use it? That's an honest question, 
maybe people are fair enough to do it, but I have serious doubts about it. It's 
of no use if people have to be told to move threads from -dev to that new list.



Most of what I wrote was tongue-in-cheek, but the point was that -dev is far too 
often filled with non-technical issues that ultimately result into flame wars of 
the likes that'd humble mighty Troy herself.  It is also our primary list for 
discussion of all-things gentoo, and so the -dev moniker doesn't even really fit 
right now.


By separating the technical and non-technical, and allowing people to 
voluntarily subscribe to the -politics one or not (since -dev is basically a 
requirement for devship), My hope is that -dev finally gets back on track as 
being purely technical.  That is, PMS discussions, ebuild additions/removals, 
new developer intros, why quoting variables like ${S} is safer than not quoting 
them in ebuilds, questions about bash-fu, and so on.  These belong on -dev.


The rest, the non-technical, can go elsewhere, IMHO, and people are free to 
subscribe to it if they wish to participate in the discussions there or not.  I 
 myself would likely stay off that list, because I care more about technical 
things.  I live ~30mi outside of the DC Beltway; I get enough politics as it is.


Think about it -- I'm 30mi away from Wolf Blitzer.  Scary stuff man.


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] [RFC]: gentoo-politics ML

2007-06-07 Thread Kumba

Ilya A. Volynets-Evenbakh wrote:

We might need some sort of enforcement for that particular purpose.
While I think that behavior proctors are inappropriate, I think that
people with ability to say move this thread to gentoo-politics or else..
for non-technical threads, as well as stop failing to use logic in your
technical discussion or else... with power to temporarily ban people
for non-compliance could be a useful thing.



IMHO, any enforcement needs to come from the developer community themselves.  We 
have to be careful when designating small groups of people with power, because 
the dark side of power is that can can be misused.  The model of developers 
collectively enforcing works well already: the Portage Tree.  While we've had 
small mishaps here and there, largely, the honesty system used on the tree has 
worked quite well.  I think that can easily extend to keeping -dev technical in 
nature only.  After all, it already works for the wayward users who posts a 
-user question to -dev.  Just a simple, courteous note that such a question is 
better asked on -user, and off they go.  Nothing precludes the same response for 
a fellow developer posting a non-technical mail into -dev.


But anyways, we've got unanimous support so far, so next up: What to call it.

My two choices are gentoo-politics or gentoo-project.  After looking at 
debian-project a bit, I think there's no harm in recycling the same moniker[1] 
for our use as well.  Amusingly enough, there's even a thread on their ML today 
about discussion of of-topic topics.  The rest of the content there seems to be 
right in line with what's been on here too as of late.


So, what should we call it?  Vote on this!  I think the current popular names 
are the following (in no particular order, just what I've already seen suggested):


gentoo-politics
gentoo-circuits
gentoo-soap
gentoo-project
gentoo-gossip


[1]: http://lists.debian.org/debian-project/


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Fact Injection (was: Living in a bubble)

2007-06-05 Thread Kumba
 almost out of coffee and nicotine.  Let's 
get our heads on straight, our asses in gear, fill our tanks and get back to 
port so we can get paid and go home.


Don't make me write another mail like this in a few months' time, k?



--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] net-www/apache-1* masked.

2007-06-02 Thread Kumba

Luca Longinotti wrote:

Hi all!
As announced in the 30 April 2007 edition of GWN [1], net-www/apache-1*
as well as all packages depending/using it were masked, pending removal
on 12 June 2007.
I fixed all packages, dependencies, etc. I could find to work correctly
after the masking (generally removing Apache 1.X support from them).
If you find any issue still, please open a bug about it, assign it to
[EMAIL PROTECTED] and make it block bug #178189 [2].
If you use or plan on using the apache-module or depend.apache eclasses,
be aware that the need_apache function doesn't anymore export the
apache2 USE flag to IUSE, since now it directly depends on Apache 2.X,
so be sure to declare it in your ebuilds IUSE (I fixed the few cases
where this wasn't already done).
Thanks and happy upgrading to Apache 2.X!

[1] http://www.gentoo.org/news/en/gwn/20070430-newsletter.xml
[2] https://bugs.gentoo.org/show_bug.cgi?id=178189



pfft, so now I'm gonna have to upgrade my antiquitated apache-1.3.x install 
after all? :P


/late to the game


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: Bye2u Gentoo

2007-06-01 Thread Kumba

Christian Faulhammer wrote:

Kumba [EMAIL PROTECTED]:


Christian Faulhammer wrote:

 Damn!  Who can I bash now regarding MIPS?

You really wanna bash the arch whose supported machines are made from
100% American-grade Steel, usually require two people to lift, and
suck more energy than a Metroid in a daycare? :P


 You just gave me some more reasons. :)

V-Li

P.S.: Interesting how many answers one can provoke with mentioning MIPS.


Well, it's really quite simple:

One does not simply MIPS their way into Mordor!


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Bye2u Gentoo

2007-05-31 Thread Kumba

Samuli Suominen wrote:

On Thu, 31 May 2007 15:21:10 -0400
Stephen Becker [EMAIL PROTECTED] wrote:


On 5/31/07, Ned Ludd [EMAIL PROTECTED] wrote:

On Thu, 2007-05-31 at 11:21 -0700, Ilya A. Volynets-Evenbakh wrote:

Grmbl Can you do us a favor and provide us with a clone, for
doing MIPS keywording?

I believe much of that had to do with trying to get a new X livecd
released.


About that, MIPS/X/Xfce/LiveCD..

Kumba said there are issues with Thunar, and possible with
xfce4-session or xfdesktop. I could use .xsession-errors (or plain
startx spits those messages to stdout/stderr) outputs from those
when built with USE=debug. And backtraces from gdb.

Are there are any developers with MIPS and X installed?

- drac



I've got a CD built w/ gdb and the debugging on in the appropriate Xfce stuff, I 
just haven't had time to boot and try it out yet.  Work has this amazing ability 
to sap time and energy away :P


Now to just figure how to get this UPS battery out...


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Re: Bye2u Gentoo

2007-05-31 Thread Kumba

Christian Faulhammer wrote:

Alexander Færøy [EMAIL PROTECTED]:


I am really going to miss a lot of you guys. Especially the ones I met
during FOSDEM. Hope to see you there next year as well!


 Damn!  Who can I bash now regarding MIPS?

V-Li


You really wanna bash the arch whose supported machines are made from 100% 
American-grade Steel, usually require two people to lift, and suck more energy 
than a Metroid in a daycare? :P


Bring it! :P


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] A User's View of the Code of Conduct

2007-03-15 Thread Kumba

M. Edward (Ed) Borasky wrote:

And that's precisely because a whole generation of RHCEs knows *exactly* 
where everything is on a Red Hat or Fedora system, and Gentoo puts 
everything somewhere else. :) If I were an RHCE, I'd have just as much 
trouble customizing and tweaking a Gentoo (or Debian) box as you would 
on a Fedora system. I know ... I've flunked the dang RHCE exam *twice* 
for that very reason! :) It's about repetition, muscle memory, rote 
learning, etc. -- not about Red Hat being better than Gentoo or the 
other way around.


Well, FWIW, those poor guys have to deal with RPMs.

'Nuff said, IMHO.


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] A User's View of the Code of Conduct

2007-03-15 Thread Kumba

M. Edward (Ed) Borasky wrote:
I joined this list mostly to talk about the proposed code of conduct. 


This oughta stir the pot a little, but way back when I was just a wee lil o' 
geek in a Star Wars club, we had a developed Code of Conduct.  Now for the most 
part, it worked and worked well.  Occasionally, you had some tart come along and 
not play by the rules, and when that happened, a High Court of Inquisitors 
took up the case and handed down judgment upon the individual.  Oftentimes, this 
HCI was comprised of former club members.  Jokingly, twas referred to as the 
Old Man's Club.  But, by and large, I'll have to admit both the CoC and the 
HCI tended to work, more or less.


All in all, twas fun times.  But what the entire point of this rare response 
from me is about is to make sure that the following clause is inserted into this 
CoC, from the CoC of the above mentioned SW Club.  Plainly put, this single 
clause was the most used  abused, loved  hated, and hotly debated rule amongst 
the members.  Oh, do I remember the days...


[Annoyance Clause]:  As different people have different annoyance levels, it is 
up to the discretion of any present ops or sub-ops as to what action is to be 
taken and when. Someone can be considered annoying when a person or persons are 
disgusted with the persons behaviour, actions or conversation.



And yeah, it probably needs a little tweaking, as it was targeted mostly at a 
chatroom crowd, but for the most part, it can still serve as a most effective 
tool...


*giggle*


--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Gentoo World Domination. a 10 step guide

2006-10-07 Thread Kumba

Thomas Cort wrote:

There have been a number of developers leaving Gentoo in the past 6
months as well as a number of news stories on DistroWatch, Slashdot,
LWN, and others about Gentoo's internal problems. No one seems to have
pin pointed the problem, but it seems glaringly obvious to me. We
simply don't have enough developers to support the many projects that
we have. Here are my ideas for fixing this problem:

- Cut the number of packages in half (put the removed ebuilds in
community run overlays)


I doubt this'll work.  I sorta see the portage tree like a starfish -- cut it in 
half, and within time, you get two starfish.  Cut it into three parts, and you 
eventually get three starfish.  You wind up back at square one with double the 
trouble and none of the fun.





- Formal approval process (or at least strict criteria) for adding
new packages


This might work, but it depends on what criteria/process, and how well its 
enforced.



- Make every dev a member of at least 1 arch team


This won't work -- especially if the dev lacks access to the hardware.  Some 
arches are so complex, you need several types of hardware.  In mips, for 
example, if a dev's got access to a low-end box like an Indy or an O2, then 
letting them help out on basic keywording on common packages probably won't 
hurt, but it would be much better if they had access to say, more than one type 
of mips hardware (say, an Octane, and a Cobalt).


Also, not every dev would want to have to maintain another box of some 
obscure/strange arch.  It's opposite in my case -- I have 1 x86 box running 
Linux (not counting my main desktop since its in windows), and everything else 
is an SGI box (or my one cobalt).  I've got spare parts lying around to build 
two more functional x86 systems, but I've never seen a need to put'em together 
and run them continuously.




- Double the number of developers with aggressive recruiting


This can become a slippery slope real fast.



- Devs can only belong to 5 projects at most


I can see this having its uses, but this is more of a personal thing on a 
per-dev basis.




- Drop all arches and Gentoo/Alt projects except Linux on amd64,
ppc32/64, sparc, and x86 


Uh, no?  Although we sometimes seem as inactive as hell, mips is very much an 
alive arch.  We're a tad guilty of going off and doing our own thing sometimes, 
but then again, most of us are guilty of that at some point in our devship.


I would instead opt for more interaction among archs, probably through dev 
sharing and such.  sparc and mips share several developers (or did, I think I'm 
one of the few left), and encouraging more publicity for the lesser archs.  I 
occasionally post an announcement about some neat new whizbang thing I do (like 
the X LiveCD for SGI systems I might post about tomorrow), and though I rarely 
see a response, I feel it gets the word out.




- Reduce the number of projects by eliminating the dead, weak,
understaffed, and unnecessary projects


Depends on the definition of unnecessary.



- Project status reports once a month for every project


Hmm, could be useful.  Depends on whether one defines a report as needing to 
match some obscure DoD specification, or whether a simple paragraph or two works 
fine.




--Kumba

--
Gentoo/MIPS Team Lead

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: multiple inheritance support for profiles

2006-08-12 Thread Kumba

Andrew Gaffney wrote:


This is pretty much exactly what Kumba was talking about. I didn't like 
the idea simply because it allowed the user to shoot themselves in the 
foot way too easily. It will also cause QA problems, since the profiles 
wouldn't be strictly controlled by the arch teams and releng anymore.


Just so it's clear, this is mostly what I was thinking up a few years ago when 
what is the current profiling system was being figured out (back when we had 
separate profile folders for everything -- ~2004.x timeframe).  ferringb quickly 
pointed a few flaws with letting the user have complete control over the 
ordering, and so I revised my idea to have the base components fixed in a 
specific order like so:


base:os:arch:userland

So a mips-unknown-linux-uclibc user would set a profile much like:
PORTAGE_PROFILE=base:linux:mips:uclibc:

FreeBSD/x86 user might use:
PORTAGE_PROFILE=base:freebsd:x86:bsdlibc

And so on.  This would fix the core components' order in a specific way.  Once 
the four base elements are set, the user is free to add on extra nodes that 
add or enhance the functionality of the core profile.  Like hardened or 
embedded, for example. (base:linux:x86:glibc:hardened)


Antarus added another idea on earlier today that'd make it more robust by making 
the nodes have depends, and via that, portage can yell at the user if they mix 
something improperly, say they have a glibc userland, and they try to add the 
embedded profile.  Since the idea of embedded with glibc is a bit silly 
(Although not impossible), portage can do one of two things: yell at the user 
that they need to switch to a uclibc userland, or ignore using the embedded 
node, because embedded depends on uclibc.


My thinking in all of this is to make the profile/ folder layout a little saner, 
but this idea has really only existed as just an idea.  It's not had a really 
good looking at by some of the portage experts aside from ferringb or antarus -- 
and they quickly highlighted several shortcomings.  In a way, though, I kind of 
envision profiles/ looking somewhat like this (Sample):


profiles/
  |
  |--base/
  |
  |--abi/
  |   |
  |   |--n32/
  |   |--o32/
  |   |--v9/
  |
  |--arch/
  |   |
  |   |--mips/
  |   |--sparc/
  |   |--x86/
  |
  |--endian/
  |   |
  |   |--be/
  |   |--le/
  |
  |--os/
  |   |
  |   |--linux/
  |   |--freebsd/
  |
  |--threads/
  |   |
  |   |--linuxthreads/
  |   |--nptl/
  |
  |--userland/
  |   |
  |   |--bsdlibc/
  |   |--glibc/
  |   |--uclibc/
  |
  |--xtra/
  |   |
  |   |--embedded/
  |   |--hardened/

Most arches I can imagine won't make use of half the nodes listed here, as some 
are restricted in what they can do.  Most of it is based on my experiences in 
trying to devise future expandibility for the mips arch, as there are about a 
zillion different ways to string things together for us, like so:


base:linux:mips:glibc:n32:nptl:be (mips big-endian, glibc, NPTL, N32 ABI)
base:linux:mips:uclibc:o32:linuxthreads:le:embedded (mips little-endian, uclibc, 
linuxthreads, embedded, O32 ABI)

base:linux:mips:uclibc:n32:nptl:be (mips big-endian, uclibc, NPTL, N32 ABI)

And so on.  Of course, not all of them are used, but it's a bad habit of mine to 
think that far ahead into the future.  Most of this is made up as I go along. 
None of it has ever really been put down in writing, except one version that 
Antarus examined a few months ago in what he called Mix n' Match, or Mixin 
form, and as more people ponder this idea and either shoot holes through it or 
add on more ways to better implement it, I guess will determine whether or not 
it'll ever be feasible.


I think if properly implemented right, it might allow for some degree of control 
by the user while letting the devs keep users from completely shooting their own 
legs off at the knee joint, and make the profile system more robust and saner to 
manage.



Thoughts?


--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Nominations open for the Gentoo Council 2007

2006-07-30 Thread Kumba

Thierry Carrez wrote:


Those were nominated but did not (yet) confirm their participation :

`Kumba


Arrr me mateys!

err, that's not until Sept. 19thmy bad.  Reading over the current nominees, 
the field looks pretty varied.  It'll be a fun race.  So I suppose I'll throw my 
hat into the mix to make the race even more fun!


My campaign pledges:

 - Pikachu Petting zoo (great for kids)
 - Cement mixer in the lavatory (don't ask)
 - Orange sherbert dispenser in the lounge (after we expand it to
   accommodate all the other proposed vending machines)

But the best is for last: A MIPS Roller coaster!
- 4 different styles of roller coaster with 3 separate tracks each
- One track will be simple, yet quite mundane, another semi-functional,
  but a bit unstable, and the third wholly untested.
- They'll range in size from some of the biggest coasters you've ever
  seen to some being embedded in the lounge (after expansion, of course)
- All the parts will be requisitioned from eBay, so the price should be
  quite cheap.


--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Test request: linux-mod support for arches with 64-bit kernel/32-bit userland

2006-07-04 Thread Kumba

Robin H. Johnson wrote:


Notes.
1. Mips: with your triple ABI stuff, you might want to look very closely
   at this.


The triple ABI stuff doesn't really affect things.  o32 userland on a 64bit box 
is the only case where you have to worry about split compilers.  In a 
theoretical n32 or n64 userland, your system compiler (and therefore CHOST) is 
already 64bit, so it's one compiler for both kernel and userland.



--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list



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

2006-06-08 Thread Kumba

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



Just a heads up: if anyone runs crossdev (even with -p), then finds a broken 
gcc-config, the reason lies in Bug #136140.



In a similar vein, will this eselect tool eventually supplant the functionality 
of binutils-config as well (and thus need its own wrapper script)?



--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Split ebuilds for GCC

2006-01-08 Thread Kumba

Dirk Heinrichs wrote:

Hi,

there has been a lengthy discussion on bugzilla ([1]), about the best 
packaging method for the gnat Ada compiler. The outcome seems to be that 
gnat will still have its own ebuild in the future and not be part of the 
GCC ebuild. It also has a mention that gcj will eventually be split out 
from the GCC ebuild in the future.


So my question is: Would it be a good idea to generally turn GCC into split 
ebuilds (like KDE/X.org)? Pros/Cons?


The only case where we actually split anything is for the few C-only kernel 
compiler packages, gcc-mips64, gcc-sparc64, gcc-powerpc64, etc..  These disable 
everything else but C, as this compiler is explicitly only for kernel building.


Anything else...good luck.  Aim for manipulating USE flags properly, though, to 
disable features of gcc you don't want or need.  This works better than 
splitting everything.



--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Gentoo/MIPS SGI LiveCD RC5 release

2005-10-19 Thread Kumba


After lots of tinkering, testing and other odd n' ends, I released on Tuesday a 
new revision of the SGI LiveCD.  Like its predecessor, RC4, this is a single CD 
that will boot and bring up several completely different SGI systems to a state 
where an install can be started.


This is one of those golden states long desired in the Linux/MIPS community, as 
previously, the only other bootable CD's capable of doing this is IRIX install 
media.  This CD is still considered RC for the time begin as several of the 
supported systems can be tricky at times to get started.  Most notably, the SGI 
Origin (IP27) series.


Perhaps the most interesting aspect of this CD is in its creation -- it was 
largely built using the upcoming 2.0 release of gentoo's release engineering 
tool, Catalyst.  Much thanks goes to Eric Edgar (rocket) and Chris Gianelloni 
(wolf31o2) of the gentoo-releng team for their assistance on the Catalyst2 side 
of things (this helped to nail several bugs in cat2 as well).


Additional thanks is extended to Stanislaw Skowronek (Skylark) for his ARCLoad 
(sys-boot/arcload) [bootloader], sgibootcd (sys-boot/sgibootcd) [CD Image 
Creator], and getdvhoff (sys-boot/getdvhoff) [utility] tools used in this CD, or 
in its creation, as well as to 'learath' of #mipslinux for SGI Origin testing 
access.


More info can be found in the README regarding questions, comments and bugs.

Initially, this can be found in my dev directory here:
http://dev.gentoo.org/~kumba/mips/releases/livecd-rc5/

But it will soon be up onto the mirrors under the experimental/mips folder.


--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: remove

2005-09-08 Thread Kumba

Mike Frysinger wrote:


we know it's retarded, but not everyone is a ninja ... no reason to rant about 
it


/me drags from the pile of dead conversations

But it's easy to become a Ninja, all you need is a simple t-shirt:
http://homepage.ntlworld.com/philbooth/How_To_Be_A_Ninja.jpg


--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] devfs is dead, let's move on

2005-08-01 Thread Kumba

Greg KH wrote:


Oops, yes, the 064 release fixed that.  Sorry for not updateing the
bugzilla entry.  That is now taken care of.


Just out of curiosity, know what happened to cause that?


--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] DOWNTIME/upgrade for bugs.g.o at 2000 UTC

2005-07-17 Thread Kumba

Jeffrey Forman wrote:

Hey all,

It's that time again...the time you get to get up from your
chairs/couches/bathtubs and grab a drink from the fridge because I am
bringing down bugs.g.o for about 30 minutes at 2000UTC, give or take. I
am applying the 2.18.1 - 2.18.3 upgrade as evidenced by some recently
discovered and patched bugs in bugzilla itself.

Things also to be done:
1. I will also be fixing a bunch of bugs that were closed as duplicates,
but for some reason the DUPLICATE resolution tag never was applied.
2. I am applying a spiffy new autolink feature. Just like being able to
cite bug # and a link is created, now glsa #-Y will be
active so that our security folks can more easily reference glsa's.

anything else i've forgotten, i credit to the bugzilla devs and their
uber-helpful nature over in irc.mozilla.org.

just to recap:
1. bugzillza downtime at 2000UTC (thats 4pm EDT, 1pm PDT) for about 30
minutes
2. get up, get preferred beverage, and consume
3. wait until i bring bugs.g.o back up with spiffy new version.

Regards,
Jeffrey

-jeff


For kernel bugs, is it possible to be able to do something like:
`Pikachu cve #CAN-2005-1912
GenBot `Pikachu: Bug #123456; CAN-2005-1912: Kernel infested with
  Pokemon; [Gentoo Linux :: Kernels]; {RESOLVED:PIKA!}; Wile E.
  Coyote-kernel herd; http://bugs.gentoo.org/123456

Maybe applicable to other apps that get assigned CVE/CAN IDs.

Possible?


--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] devfs is dead, let's move on

2005-07-08 Thread Kumba

John Mylchreest wrote:


No objections here. I've been waiting fort his move for a little while
now. The only real problems will be with those 2.4 (devfs) users who
refuse to move, maybe this is good enough incentive.


Just to make sure on a few things, we're talking x86 users here being the 
hardcore 2.4 types, right?


While I'm all for 2.6, mips-side, we've still got some issues on IP22 
(Indy/Indigo2) systems that forces me to keep a 2.4.31 ebuild around.  Sparc is 
also in a similar, although much bigger boat, where a whole lot of 2.6.x 
releases just don't work for various systems, thus they have to stick with 2.4.x 
as well.


Any of these changes that may affect 2.4/devfs usage need to keep this in mind 
that some of us who still use 2.4/devfs may not be doing so out of choice, 
simply because it's the only option we have.



--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] src_configure

2005-07-06 Thread Kumba

Diego 'Flameeyes' Pettenò wrote:


That will be very very interesting but... but not everything uses ./configure, 
so we should add a bunch of dummy src_configure, and a call to econf || die 
 for those packages not fixed to use that will return a bunch of erroneous 
packages not compiling.


I know some packages off the top of my head, like Perl and OpenSSL use their own 
odd variants of configure.  There are likely many others.


Kernel ebuilds probably need special treatment, as they don't really go through 
a configure and compile phase.



--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Software patents

2005-07-05 Thread Kumba

twofourtysix wrote:


Not being privy to -core either, I am wondering about the apparently
hypocritical stance being taken on this issue.


I'm not sure if you caught the last few mails, but as stated, opinions posted on 
the Planet/Blog/Bathroom Stall are simply _opinions_ of individual entities. 
They are _not_ opinions of the entire organization, no matter how many opinions 
for or against there may be.


As such, the following events can be expected to occur:
1) Software will _not_ be removed from the tree simply because
   it is made by a company who just so happens to favour
   software patents.

2) This pointless debate will eventually die, because if it doesn't
   I'm going to start quoting select excerpts from Vogon Poetry.

3) If the Vogon Poetry fails, I'll start reading excerpts from
   Grunthos the Flatulent's Ode To A Small Lump Of Green Putty
   I Found In My Armpit One Midsummer Morning.

4) If that happens to fail, which it shouldn't, I'll be forced to
   depths I haven't visited in quite a long time: Poetry from
   Paul Neil Milne Johnstone.

5) Everyone will become happy, and help Save the Pikachus.


--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] linux-2.6.12

2005-06-18 Thread Kumba

Jason Wever wrote:


The ChangeLog[1] is your friend.  Live it, love it, use it!

[1] - http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.12


Thankfully, I see no mention of reiserfs4 in it.  So we may yet be spared 
another release before the post-processed organic material hits the proverbial 
high-speed turbine.


Yeah, I'll probably get flamed for this, but I 3 my ext3 :P


--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] linux-2.6.12

2005-06-18 Thread Kumba

Andrew Muraco wrote:



keep your wity comments to yourself -lol i dont think ext3 is going
anywhere for a long time..


I usually think this is why alot of people still rely on it.  It's solid, and 
doesn't change very often, so people working in environments that require solid 
stability on Linux likely go with this.




reiserfs4 will merely be an option for
those of us that like post-proscessed organic material..


Just remember, bugs in vanilla-sources go here: http://bugzilla.kernel.org/

Any other -sources buggers up, try a variant of vanilla-sources to see if the 
problem exists there.  If it does fire the bug upstream to the mainline kernel 
devs.  If not, might be a patch we added in.


I'm just stating this, because once reiserfs4 goes mainline (I believe it's in 
-mm currently), we are bound to have users hitting various bumps and ruts in the 
road using it, and if they file bugs to our bugzilla that aren't related to 
patches we produce, then they'll likely wind up closed as invalid and such. 
This saves the users time, and may get them the answers they seek (or at least a 
resolution of some kind).  It also saves our bug-wranglers time by now having to 
deal with more invalid bugs.



--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] use.force support

2005-06-13 Thread Kumba

Sami Näätänen wrote:

On Monday 13 June 2005 23:54, Sven Wegener wrote:


On Mon, Jun 13, 2005 at 03:40:34PM -0500, Kito wrote:


what about just a use.env?


I find that a little bit misleading. Sounds like use this
environment or so.



How about use.lock, which would lock the listed use flags from normal 
usage.


Something like this would be useful for some arch profiles (including subarch 
profiles), where we may need to set specialized USE flags.  Like n32 in 
mips/mips64/n32, or cobalt in mips/cobalt, or ip28 in mips/mips64/ip28.  These 
make sure that these specific profiles work as intended, and despite how much 
notice we may put out regarding USE flags in these specific profiles, there is 
always someone out there that will think otherwise and try to disable them, then 
wonder why things break.


I'm all for choice, but a very specific, very limited set of USE flags that need 
to be forced on if using a specific profile would be great.  make.defaults works 
for the most part, but people can override it with USE=-* blah1 blah2 foo bar 
IIRC.



--Kumba

--
Gentoo/MIPS Team Lead
Gentoo Foundation Board of Trustees

Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere.  --Elrond

--
gentoo-dev@gentoo.org mailing list