Re: [gentoo-dev] Re: rejecting unsigned commits
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
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=2&chap=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
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): 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 ? Anyways, after commiting to gentoo-x86 CVS, a backend script, similar to or the same as whatever parses out the 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: Would mark every ebuild in the directory for a given EAPI value (EAPI=2 in this case) 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
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 pv = Package Version (incl. revision if needed). v = EAPI version. Other variants: mips-sources-2.6.28.7 1 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]
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]
eren't exactly designed with "energy conservation" in mind. People who want to help bring us closer to the rest of Gentoo, rather than off in our own little world, as we are oft found to be. I'll fill those interested in all the dirty information they need to hunt down a machine 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] have any developers subscribed to -project?
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] New lists and their usage
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] Getting -project started
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! --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
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
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] Getting -project started
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] So...
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] Re: ML changes
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] laying out arch profiles
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] ML changes
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
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] ML changes
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
e. Basically, moderation is a tool to me, a tool that should be used 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
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] setarch and util-linux (amd64/mips/ppc/sparc)
Mike Frysinger wrote: the new util-linux package has merged the setarch binary. for the upgrade path, i figure we do: - drop sys-apps/setarch from profiles - add sys-apps/setarch to util-linux-2.12 based on arch?() - add !sys-apps/setarch to util-linux-2.13+ any input ? -mike None here. You may fire at will. --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
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
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
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
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 > AD&D. 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
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 t
Re: [gentoo-dev] [RFC]: gentoo-politics ML
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
Re: [gentoo-dev] [RFC]: gentoo-politics ML
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
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
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] [RFC]: gentoo-politics ML
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
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
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
[gentoo-dev] [RFC]: gentoo-politics ML
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] Fact Injection (was: Living in a bubble)
nagers on the fly in a single stage3, irregardless of what package manager built that stage. Now wouldn't freakin' rock a zergling's socks? Anyways, we're off the crab guys. Really. We're pulling in blank pots, the crew is getting restless, and we're 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.
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 --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
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] Re: Bye2u Gentoo
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] Bye2u Gentoo
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] A User's View of the Code of Conduct
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] A User's View of the Code of Conduct
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] Gentoo World Domination. a 10 step guide
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
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
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
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] Herds suck, fix them
Alec Warner wrote: So apparently they suck, anyone have a new shiny idea on how to group packages and maintaining developers? Sure -- take the current herds implementation, and rename it to 'gaggle'! Then we can call things the base-system gaggle, the toolchain gaggle, etc... Even metadata.xml will look much better, i.e.: Current sample: base-system New sample: base-system 'herds' also implies say, a group of cows just standing around in the middle of a grassy field, doing nothing but eating grass and staring at little green men demanding to be taken to Earth's leaders. Oh, and contributing to global warming. 'gaggle' implies a much more active nature, like a gaggle of geese chasing down a pedestrian with a load of bread, and honking at him until the bread is surrendered and, terrified, he takes off running. Hey, taking the same old idea and giving it a new name works for the US Congress --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
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
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
Re: [gentoo-dev] Catalyst{,2} and 2006.0
Kalin KOZHUHAROV wrote: Yes, thes examples are quite good, however as I said before, real (=working) examples weere needed. (note to /me => `emerge -s livecd && emerge -a livecd-specs livecd-kconfigs`) Working specs can be found in our ViewCVS in gentoo/src/releng/specs. Therein are contained the specs used to build prior releases for most archs. --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
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
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
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] devfs is dead, let's move on
Greg KH wrote: Ok, 064-r1 version of udev does this for tty and console devices. The old devfs names are now gone. Because of this, and some other config file tweaks, starting udev now only takes .5 seconds on my old, slow laptop, instead of 5 seconds. Hopefully others will also see such an increase. Now to implement the persistent block device names that we showed everyone at OLS... Does this happen to also fix the bus error on sparc mentioned in Bug #99290? I see in the Changelog a reference to a sparc fix, but the bug hasn't been updated regarding the status. --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
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
`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
Greg KH wrote: I understand that other arches need to stay at 2.4 for various reasons. Hopefully those issues will be fixed so that this situation doesn't stay that way for much longer. You're not the only one hoping they're fixed soon :) I am supprised that Sparc64 is stuck with 2.4, as the main kernel developers of that tree work on 2.6 everyday. As for mips, I thought the recent (few kernel versions ago) merge brought you all up to speed? Anything that I can do to help this, please let me know. Yeah, it's a bit surprising really. It depends heavily on the machine, and upon certain options in the machine. I run a Blade 100 with 1 IDE and 1 SCSI drive, and 2.6.7 is the last "good" kernel for me. 2.6.8.1 -> early 2.6.11 apparently had something nasty that buggered up the scsi subsystem to the point where heavy disk activity brought a system to its knees in minutes. I haven't tested anything newer as I usually wait for a grsec release before building a new kernel for my non-mips systems (and they haven't released anything for 2.6.12 yet). The current issue going on, I haven't followed too closely, but it appears to cause various issues on several machines. In one case, a Netra 1450 with 4x CPUs keels over on 2.6.1 and up within several minutes of doing anything on it. squash is going to go back and test all the 2.5.x kernels to try and find the point at which it all started happening. The thread regarding all of this (and has davem participating in) started here: http://marc.theaimsgroup.com/?l=gentoo-sparc&m=111967071008611&w=2 As for mips, the only system gentoo-supported that still has a link to 2.4 are the old IP22 (SGI Indy/SGI Indigo2 R4x00) systems. When I run ~2.6.10 on it, I can usually hang the box after a couple hours of building something (like glibc), whereas geoman can run his Indy for days on 2.6.x w/o incident. Likely, there's probably some tricky bugs left that hinge on a specific CPU revision, and I just happen to have the one revision that causes the bug. I just haven't fired the system up and really taken a good look at it. --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
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
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] use.desc and use.local.desc cleanup
Sven Wegener wrote: Unused local flags: sys-kernel/mips-headers: cobalt It's used, it just looks like I forgot to add it to IUSE in the 2.6.11-r1 ebuild. Should be fixed. --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
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] Updating the list of non-SPARC herd devs keywording for SPARC
Chris Gianelloni wrote: Arches: MIPS (I just got an Indy and a Challenge S, haven't loaded them up yet) Drop us a note if/when you get these running. If you're up for helping us out on releng stuff, I can provide oodles of info (and ideas) on how we have to do Netboots and my random forays into the liveCD structure (as you've seen me yammer on about in -releng) --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
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] linux-2.6.12
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] use.force support
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
[gentoo-dev] Gentoo/MIPS SGI LiveCD RC4 (a.k.a., Round 2)
Alright ladies and germs^Wgentlemen, here we go, round #2 of the Mips LiveCD attempt. This time, it works a heck of a lot better than before. Most of theory behind this CD is made possible by Stanislaw Skowronek and his rather revolutionary new bootloader, ARCLoad. Coming soon to a portage tree near you! See the README file at the top level of the livecd directory for a far more thorough description of how it works, how it boots, and how it's more or less put together. the cdboort-ip* files are example sof how the CD boots on my available systems. Your's should more or less closely follow what's shown there. Please report bugs, glitches, feedback, suggestions for improvementm etc, to Bug #95631 at http://bugs.gentoo.org All that said, you can find everything here: http://dev.gentoo.org/~kumba/mips/releases/livecd-rc4/ Tools, mainly just the miniroot (embedded into the kernel) and the CD "real root" can be found in the tools/ subfolder. Other bits and pieces used to make this CD Image will probably appear there over time as well. --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
