[gentoo-dev] (Not so) New Developer - The Paya
Hi Guys, I've been very slack about announcing some of our new guys recently, and not least Javier Villavicencio. Javier, known on IRC as The_Paya, joined us to work on all aspects Gentoo/FreeBSD plus anything else he can throw his skills at! Coming from Argentina he has an interest in fishing, high end hardware and playing with imaging apps. Javier has also done a great job of infiltrating yet another company with production servers running Gentoo :) I'm sure I'm not the only one to throw thank-you's and welcome him on board! Here's to a long and enjoyable involvement with Gentoo! -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpgN7QPT6GIz.pgp Description: PGP signature
Re: [gentoo-dev] [QA] Incomplete IUSE for useflags in {,R,P}DEPEND, SRC_URI etc...
On Wed, Jul 12, 2006 at 03:23:06PM +0200, Matthias Schwarzott <[EMAIL PROTECTED]> wrote: > On Wednesday 12 July 2006 15:16, Danny van Dyk wrote: > > Hi all, > > > > thanks to djm's efforts i was just able to scan the whole tree using > > qualudis. For a start, i'll attach a list of QA violations on missing > > entries in IUSE. As this is a minor change to the ebuilds, I'll go on > > and fix all the listed ebuilds myself. > > > > There are 505 ebuilds which are missing use flags in IUSE that they use > > in other places. > > > While reading your list I have seen pcmcia often. e.g. on my ebuild > v4l-dvb-hg > not supporting pcmcia as conditional. A bit digging showed that > linux-mod.eclass contains this code: > > --cut-- > IUSE="" # don't put pcmcia here, rather in the ebuilds that actually support > pcmcia > SLOT="0" > DESCRIPTION="Based on the $ECLASS eclass" > RDEPEND="kernel_linux? ( virtual/modutils > pcmcia? ( virtual/pcmcia ) )" > --cut-- > > I don't know if pcmcia should then be added to every ebuild including > linux-mod.eclass. > > Please solve this before adding pcmcia on every kernel-module-ebuild. > > Matthias > > -- > Matthias Schwarzott > Gentoo Developer > http://www.gentoo.org This is actually on my TODO list, but has been for some time now. I'll reprioritise and get this out the way I think :) -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpHli4liTK4d.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-core] Resignation
On Tue, Jun 27, 2006 at 03:21:49PM +0200, Andrej Kacian <[EMAIL PROTECTED]> wrote: > On Tue, 27 Jun 2006 13:07:45 +0200 > Enrico Weigelt <[EMAIL PROTECTED]> wrote: > > > > As I have been swamped with emails, private messages and phone calls > > > from certain people, I will retract my resignation for the final time. > > > > I'm fairly new to Gentoo, but I'd like to help. > > So, what shall I do ? > > You can start by not hijacking mailing list threads. Or am I the only one > failing to see how is this connected to Jory's (retracted) resignation ? Having not yet read the rest of this thread I'm sorry if this is going to repeat anything else thats being said, however... This is a prime example of one of the reasons which is making people leave gentoo, either as a developer or as a user. Having someone email to show their appreciation for peoples work and equally as important to also be willing to commit their own time to help as well being shot down with such an ignorant comment is upsetting to say the least. I suggest the next time someone wants to offer their help you think twice before you flame for off-topic. However, on that note... Enrico, Please find some reading on the subject here: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=2 If you need any further help please feel free to join IRC and ask in #gentoo-userrel Best Regards, John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpdrA1OgQFtA.pgp Description: PGP signature
Re: [gentoo-dev] Pending Removal of $KV
On Tue, Jun 20, 2006 at 02:32:36PM +0200, "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote: > > >>This is duplicating the superb efforts of the kernel team and of > > >>linux-info eclass. As such I would like to deprecate $KV in favor > > >>of using linux-info eclass. I don't see the need for portage to > > >>export $KV into the environment for all packages. > > Yes please. linux-info.eclass is great; does (almost) exactly what > should be done, i.e. depend on user-supplied kernel source & object > locations. Firstly, thanks for using it :) If you have any suggections (speculating based off the "Almost" part please feel free to talk to me about them and I'll see what I can do :) > > >>There are a few packages left that use this. There will be a > > >>tracker bug shortly. Mostly this mail is just a heads up ;) > > > But any kind of checks against something in $KERNEL_DIR are just > > > wrong, wrong, wrong. The only exception being when the ebuild is > > > building something *against* those sources (kernel modules, and > > > that's it). > > > > > > It's annoying to have virtual/linux-sources pulled as a dep of > > > gnupg, iptables or any other package that can do fine without them. > > I do agree virtual/linux-sources shouldn't be a dependency. The > ebuilds should depend on the existence of the kernel sources or > objects against which the package will be built, which can only be > detected in pkg_setup. To this end I think DEPEND should not be set in > linux-info.eclass. Additional to this linux-info is close to useless outside of an available linux-source tree. We do provide an interface which should very very rarely be used for running kernels get_running_version() and in this case I can see why the source-tree can be dropped, but I dont plan on doing so any time soon. Really this all stems back to gentoo policy regarding building/testing against kernel srctree/objtree which is as simple as anything requiring or depending on kernel sources should always use those which are pointed to by the "/usr/src/linux" symlink. This enabls us to build packages against a target, rather than current. Cross-compiling would be a nice example here. > > In many cases those packages are looking for a specific kernel > > feature to make sure support is enabled for it. > > > > You could argue that in the case where you aren't compiling against > > the kernel that support being enabled isn't critical, but that is a > > discussion you need to have with the package maintainers. > > I think it's wrong for ebuilds to refuse to build if support is missing > from the build system kernel. ebuilds should not be using the > configuration of the build system to decide whether to build pieces for > the target system (such decisions should be made via USE), and > certainly shouldn't die if run-time support isn't built on the build > system (unless the support is actually needed for the build process > itself, such that the build would fail). With linux-info.eclass you can They can optionally be non-fatal, and you can also call the API directly and handle it as required. > specify the location of the kernel tree to build against > (KBUILD_OUTPUT) and thus build for different kernel configurations as > appropriate (the default being the build system kernel, which makes > things simple for the common case where the target is the build system). > > In summary, I agree that $KV should disappear from portage, and that > anything that depends on kernel configuration should use > linux-info.eclass. Also I'd like to see the dependency on > virtual/linux-sources removed from linux-info.eclass. I've tried to clarify my point fairly well above, but the dependancy is fairly strict by design. What in linux-mod except for my specific example above would continue to work if there were no kernel sources present? (I do of course know the answer but its rhetorical) To that end is the reason why the dependancy still exists. That said, I'm open to persuasion. - John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpoFe9vpVj0r.pgp Description: PGP signature
Re: [gentoo-dev] Pending Removal of $KV
On Mon, Jun 19, 2006 at 11:13:33AM +, Alec Warner <[EMAIL PROTECTED]> wrote: > Portage currently exports $KV as the current kernel version. We detect > this by attempting to mess around with the things in /usr/src/linux > (.config, make files, etc...) > > This is duplicating the superb efforts of the kernel team and of > linux-info eclass. As such I would like to deprecate $KV in favor of > using linux-info eclass. I don't see the need for portage to export $KV > into the environment for all packages. > > There are a few packages left that use this. There will be a tracker > bug shortly. Mostly this mail is just a heads up ;) I've been after this for quite a long time (I opened a bug but cant seem to find it) as not only is it horrifically broken, it also should never have been the job of portage internals anyways. $KV is currently being exported by linux-info purely for legacy support and as such I would like to suggest that if these ebuilds inherit linux-info as well as use $KV, then it should not require any maintainer changes. Anything I can do to encourage this move please let me know, and many thanks for raising this again. Best Regards, John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgppBTaSFSiXx.pgp Description: PGP signature
Re: [gentoo-dev] Packages that need maintainers
On Thu, May 04, 2006 at 06:09:39PM -0500, Daniel Goller <[EMAIL PROTECTED]> wrote: Assuming there are no objections I can take over the following. > ./app-benchmarks/cpuburn > ./app-benchmarks/bonnie++ Regards, John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpVc3TRSJ3l7.pgp Description: PGP signature
[gentoo-dev] New Developer Mike Auty (ikelos)
Hi All, Its with great pleasure that I announce a new vict^W^W^W^Wdeveloper to the ranks, Mike Auty. I'm sure you'll all make him feel very welcome :) Mike's been around helping many of us for a long time now, most recently with the excellent work he's been doing on vmware. Mike has this to say: "I came from Lancaster originally but now live in Worcester in the UK. I mostly enjoy spending my time chatting to my close friends and exploring crazy ideas with them, or being on my own and looking for new tools and ideas on the Internet. I'm interested in loads of areas, so I guess that makes me a generalist, and if you've got something new and interesting you need help with then I'd love to hear about" So for all you mad scientist folk out there with crazy ebuilds waiting to go into the tree, you're finally in luck! All the best to you Mike, Regards, John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpJGXxx1iraU.pgp Description: PGP signature
[gentoo-dev] New Developer: squinky86
OK, You got me. Not really *new* but meh! I'd like to welcome back Jon Hood (squinky86) who has returned after a prolonged hiatus. If you wish to cheer or throw underwear, this is your cue. Jon hails from Huntsville, AL, but its not his fault, bless. Jon will be mostly working on accessibility and net-p2p. A few words from the horses mouth: "I'm Jon Hood from Huntsville, AL. I was a Gentoo developer before, but some problems came up and now I'm returning. All my spare time is put into developing applications for voip (esp. Asterisk), Gentoo, and last but DEFINITELY not least, my wonderful girlfriend, Caitlyn (who KingTaco wanted to make a dev instead of me). I am good with c++, java, assembly, php, and sql. Feel free to ask me about Asterisk, too. It's good to be returning to Gentoo!" I'll be uploading photos of Caitlyn to hotornot.com shortly, I'm sure she will score very highly :) So on that note, hurrah for Jon, and welcome back to the party. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpsogaAB5Uqr.pgp Description: PGP signature
[gentoo-dev] adding INSTALL_MASK to info_vars
Hey guys, Anyone got any objections to this? If you do, please speak up now, else I will add this in the close to immediate future. Cheers, John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpFWya9vzb55.pgp Description: PGP signature
Re: [gentoo-dev] Change layout of distfiles
On Mon, Mar 06, 2006 at 12:36:22PM -0500, Alec Warner <[EMAIL PROTECTED]> wrote:
> Taking the earlier comment ( changing files only on the mirrors ) there
> are no portage changes that are technically required. However, you'd
> need to change about 1 ( random number I pulled out of my ass, but
> there are many affected ) SRC_URI's to point to the new format, or
> produce some sort of hack that translates between the two, and I
> wouldn't be to fond of the latter effort, mostly because it would
> probably rot in the tree for way too long ;)
For the time being, whats stopping us from doing something like the
following on the mirrors?
for i in `find . -type f`; do
dir=${i:2:1};
// I guess we REALLY want case sensitivity, but thats not for me
// to decide.
dir=`echo ${dir} | tr [:upper:] [:lower:]`
mkdir -p ${dir};
mv ${i} ${dir};
ln ${dir}/${i:2} ${i};
done
> And you need to modify policy for placing files on the mirrors, but
> thats not a portage problem either; from the portage POV the change is
> relatively seamless.
Modifying the mirror code to do something like the above shouldn't be
complicated at all.
--
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key: gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515
pgp56Ngme8Idj.pgp
Description: PGP signature
Re: [gentoo-dev] Gentoo on VMWare - few ideas
On Mon, Mar 06, 2006 at 12:23:21AM +0100, Jose Alberto Suarez Lopez <[EMAIL PROTECTED]> wrote: > I think that it's a nice idea. > Maybe 2 versions: with X and w/o X just to reduce the space needed. How would shipping twice the number of images save space? However, at the last count there was 1.8GB of space free on the torrent tracker/mirrors dedicated for this kind of stuff, and my personal gnome images easily fit in 500Mb. > Can be great to try gentoo inside any other linux or win machine. Can > be great too to try new systems ebuilds or to test things. Yeah, it's not a bad idea at all. I'd actually be fairly comfortable in keeping a semi-up to date image anyways, but at release time I generally don't have the time. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpapCSaMmiiw.pgp Description: PGP signature
Re: [gentoo-dev] Re: Gratuitous useflaggery (doc and examples)
OK sorry, all those Re:'s were really getting to me :) -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpZltaagIJyM.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, Feb 27, 2006 at 05:30:27PM +, Stephen Bennett <[EMAIL PROTECTED]> wrote: > (Yes, I'm taking that sentence out of context, but the fact that it > comes up at all says something, to my mind.) Your mind is a dark and twisted place! -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpcif7cymuGN.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, Feb 27, 2006 at 04:37:52PM +, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > On Mon, 27 Feb 2006 09:09:01 +0000 John Mylchreest <[EMAIL PROTECTED]> > wrote: > | In this specific instance, impossible is effectively a point of view. > | For me the question comes down to this.. If QA trump maintainer, then > | who picks the QA staff? If anyone can become QA staff, then this is > | questionable in itself. is QA becoming another council with a sole > | purpose? If so I'd like to see an election again. At the end of the > | day the pack have to have faith in the team doing the work, and > | disagreements are obviously contrary to that. > > QA consists of whoever is on the QA project page. To be added, you must > convince the existing QA team that you know what you're doing. My point was the more along the lines that the existing QA team need to convince the rest of the development community that they know what they're doing first. Whats stopping the existing QA team disregarding all new applicants because they enjoy having authority? Especially when its mis-placed authority. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpe2CwZZJnYv.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Sun, Feb 26, 2006 at 07:12:52PM -0500, Mark Loeser <[EMAIL PROTECTED]> wrote: > Alec Warner <[EMAIL PROTECTED]> said: > > This is meant to prevent the case where the QA team ( or a subset; "the > > established QA members" ) decides to make unilateral changes to the tree > > ( or large subset thereof ) without even necessarily talking to the > > affected developers. > > > > While you may not think that soliciting comments is useful ( and in some > > limited cases I would agree with you ) giving people the opportunity to > > comment also means you just covered your ass, in terms of people going > > "where the hell did that come from?" > > We don't plan on going around and making changes without discussing > issues with the maintainers. We put this in so that if the maintainer > is unwilling to work with us for some reason, that we are able to come > up with what we believe to be the best fix. As I said earlier in the > document, we plan to work as much with maintainers as possible, but > sometimes that may prove to be impossible. In this specific instance, impossible is effectively a point of view. For me the question comes down to this.. If QA trump maintainer, then who picks the QA staff? If anyone can become QA staff, then this is questionable in itself. is QA becoming another council with a sole purpose? If so I'd like to see an election again. At the end of the day the pack have to have faith in the team doing the work, and disagreements are obviously contrary to that. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpgTcm5SZaCd.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Sun, Feb 26, 2006 at 07:09:29PM -0500, Mark Loeser <[EMAIL PROTECTED]> wrote: > > > The problem with that is, it usually ends up with too many pointless > > > comments from people saying how things could be fixed in the distant > > > future, or whining that it isn't explicitly forbidden by policy on > > > situations where the screwup was too weird to be documented previously. > > > > This is very much a case-by-case thing. I still feel the debate should > > be better answered outside of conflicting qa members. > > Well, instead of putting the debate into an even larger crowd, this > enables the QA team to act in the way it sees best first. If people > believe we were wrong, then we give them the option to talk to the > council about one of our changes. Also, we aren't unwilling to hear > alternatives and we hope to work with the maintainer on these problems. I've yet to read the rest of this subthread this morning, but while its fresh in my mind I would also like to see less of a requirement from the council. They are there purely for technical direction and not for a teams beck and call. Regardless, I can see your point - although I would still prefer to see a little more public discussion when the QA team are unable to satisfactorily come to an answer between themselves and the maintainer in question. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpLXBkh7cAFg.pgp Description: PGP signature
Re: [gentoo-dev] Putting all log related packages into it's own category (sys-logging)
On Mon, Feb 20, 2006 at 02:13:46PM +0100, Bjarke Istrup Pedersen <[EMAIL PROTECTED]> wrote: > I was thinking, how about putting all log related packages into their > own category? > This should be logging daemons, log viewers, logrotate etc. > > Maybe creating a logging herd would be an idea to, to remove the load > from the base-system herd. > > What do you think? I think this is a great idea, as long as it doesnt get abused. There are quite a lot of log handling packages anyways, although would there be enough to warrant a new category as well as a new herd? My brief suggestion of packages which would be good for this: app-admin/analog app-admin/cronolog app-admin/fetchlog app-admin/klogview app-admin/logmon app-admin/logrotate app-admin/logsentry app-admin/metalog app-admin/modlogan app-admin/newsyslog app-admin/phpsyslogng app-admin/socklog app-admin/sysklogd app-admin/syslog-ng app-admin/ulog-acctd app-admin/ulogd app-misc/logserial net-firewall/fwanalog net-mail/qlogtools net-mail/qmailanalog sys-apps/gluelog sys-apps/logwatch x11-misc/paralogger Regards, John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgp50aBPGXFyN.pgp Description: PGP signature
Re: [gentoo-dev] Re: /etc/rc.conf
On Mon, Feb 13, 2006 at 08:15:23PM -0500, Mike Frysinger <[EMAIL PROTECTED]> wrote: > On Monday 13 February 2006 20:07, Forrest Voight wrote: > > How is that wrong? If it isn't, eselect would be a great way to switch > > EDITOR and XSESSION. > > jesus, talk about over engineering > > using eselect to manage some default variables instead of simply editing your > ~/.bashrc file is like using a backhoe to dig a hole for a bonsai tree ... > sure it'll work, but who the hell wants a goddamn bonsai tree > -mike I have 2 :) But on topic, I totally agree with Mike. OK, Possibly EDITOR and XSESSION are better suited to somewhere else other than rc, but atm that place doesn't exist, and imo doesn't warrant creation. /etc/env.d/ (when it comes to setting a default editor) just seems very odd to me. It's not easily managed from a package perspective. It can easily just throw some random behaviour. Of course, user specific EDITOR etc, is much better set in the appropriate ~/dotfiles. System wide, all we need is a workable default. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpujO1RGFPSU.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Request for Comment
On Sat, Feb 11, 2006 at 11:09:07AM -0700, Duncan <[EMAIL PROTECTED]> wrote: > > Duncan, you make some valid points but for the sake of ease for the rest > > of us, could you please try condense the mails down from several pages? :) > > I've been proud of myself, even managing a couple one-liners, lately. =8^) Keep up the excellent work ;) -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpIK95zcZ8h5.pgp Description: PGP signature
Re: [gentoo-dev] Re: Request for Comment
On Fri, Feb 10, 2006 at 10:41:04PM -0700, Duncan <[EMAIL PROTECTED]> wrote: > Klaus-J. Wolf posted <[EMAIL PROTECTED]>, excerpted > below, on Sat, 11 Feb 2006 03:37:25 +0100: > > > Would you please discuss a GLEP draft, which I believe it might improve > > the usability of Gentoo? > > > > Text at: > > > > http://www.seismic.de/gentoo/gentoo_mask_proposal.html > > I'm just a user, not a dev, myself, so take this as you will, but the > general idea is the same sort of ultra-stable enterprise stability > targeted system that comes up for discussion here every so often, and > already has various levels of workable and not-quite-so-workable proposals > floating around. This particular one's in the not-quite-so-workable camp, > mainly because (1) it doesn't work /with/ portage or the way things work > now, but against it, in a number of ways (2) it doesn't consider the > different speeds at which different packages move (this is the big one, > there's likely never /been/ ten or even five versions of some packages > that have existed since there /was/ a Gentoo), and (3) it doesn't really > consider the way devs work. Point of fact, it's particularly from a user > perspective, not understanding a /lot/ about the "supply" side of the > distribution mechanism, only the /user/ or /demand/ side. Duncan, you make some valid points but for the sake of ease for the rest of us, could you please try condense the mails down from several pages? :) -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgp4rydH55vyM.pgp Description: PGP signature
Re: [gentoo-dev] Manifest2 decision delayed
On Sat, Feb 11, 2006 at 11:38:05AM +0200, Alin Nastac <[EMAIL PROTECTED]> wrote: > When you have thousands of small files (1-4 blocks), the space saved by > removing all unnecessary whitespaces is minimal at best. > Minimizing the number of files is another story. Unifying manifests with > digest files will save a considerably amount of disk space. not to mention inodes. Thats one of my pet-hates about the tree' size. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpMi8VmuXsjM.pgp Description: PGP signature
Re: [gentoo-dev] relocation.
On Fri, 2005-12-30 at 13:06 -0500, Philip Webb wrote: > 051230 John Mylchreest wrote: > > as of tonight I pack up my most valued of possessions -- my computer kit -- > > and get ready to board a one-way ticket to York. > > York of the Minster & bright new archbishop or our own Muddy York ? Minster and the slightly odd-lookin' clergyman. I do fancy a holiday though ;) -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515 -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] relocation.
Hi All, Just to let you know that as of tonight there is no guarantees on when I will be back online. I pack up my most valued of possessions (in case you never guessed, its my computer kit ;)) and get ready to board a one-way ticket to York. Anyone in the area who fancies meeting up for a drink is welcome to email me and I will read it when I'm back, but I would like to wish everyone a fantastic new years (replace with appropriate holiday) and all the best. I move into the new flat on the 3rd, so I suspect net access of some variety will exist at some point around the 20th, but I will be having withdrawal so the sooner the better :) Anything urgent I'm sure you can find someone with my mobile number in #gentoo-uk, but I'm sure that's not going to happen. Happy Holidays Campers, John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515 -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Wanted: AMD MP2400+
Hey all, Sorry for asking on this list but if anyone has an MP2400+ which they are willing to get rid of (I can pay P&P and a reasonable asking price) on the cheap, please let me know. Please email me off-list on this mail if you can help me. It will certainly help me out a LOT! Many thanks, John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-core] Re: [gentoo-dev] Possible virtual/alsa change
On Thu, 2005-10-27 at 14:28 -0400, Stephen P. Becker wrote: > The problem is that *all* mips-sources ebuilds do not provide alsa. > Only the mips-sources-2.6.* versions do this, and then only if > USE="ip30" (Octane users). This makes sense, although not the USE flag. > I'm just worried about folks running 2.4 systems (only Indys at this > point) with mips-sources "providing" alsa, but not really. This could > get even more tricky because I happen to know somebody is working on an > alsa driver for Indy, and it will be for 2.6 only. We're trying really > hard to get everything to where we can just get rid of 2.4, but until > that time, setting the virtual to mips-sources is technically broken. Of course, 2.4 kernels are technically broken because they dont support alsa, and this is fixed in other profiles with the inclusion of a 2.4 (or 2.6) sub profile. However.. if nothing actually works with alsa, then I dont see the problem in that case of making the profile default mips-sources. if it happens to install 2.4 sources, then so be it. it might be a technically incorrect provide.. but nothing else can fill it any better. At least at this moment in time. If it were me, thats what I would do. But of course, this change doesn't really make any difference to mips one way or the other. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-core] Re: [gentoo-dev] Possible virtual/alsa change
On Mon, 2005-10-24 at 15:41 -0400, Stephen P. Becker wrote: > Currently, we have two machines with alsa drivers (only one of which > *really* works, but that is beside the point), and the working driver is > applied to our mips-sources-2.6.* ebuilds along with the patchset for > octane. However, this information is pretty irrelevent from my point of > view. The real problems are that A) alsa-driver doesn't contain any > mips drivers, B) 2.4 kernel sources do not contain the alsa drivers > while 2.6 do, and C) that mips-sources included both 2.4 and 2.6. > Therefore, we really do not have anything generic that can be changed to > the default virtual for us without being broken (until such time as we > can finally get rid of 2.4). I don't have a solution at this point in > time either...I'm just saying how things are. I dont see this as a real reason to not change the default personally. mips-sources exists in the tree for a reason, and are being actively maintained. by setting the default virtual for alsa-sound to gentoo-sources surely wont effect you anyways, considering alsa-drivers doesn't work, gentoo-sources likely dont work, and mips-sources provide virtual/alsa? If at some point alsa-drivers decides to work, then can you not just redefine the virtual in the mips profile? Anyways, I see no real point here to prevent the move, however I found it educational re: alsa-driver :) -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Suggestion: ebuilds linked to kernel upgrade
On Wed, 2005-10-19 at 17:31 -0400, Chris Gianelloni wrote: > Actually, genkernel does have the --callback option, which runs an > external command before finalizing the build. We use it for building > external modules and packages that require a configured kernel when > building the releases, but I think adding an option to genkernel > wouldn't be bad to do this for you. We could add a command-line switch > to genkernel to automatically rebuild any external modules after it has > built the kernel. We could use something like --autorebuild. You could > then do something like "genkernel --autorebuild all" to build your new > kernel and automatically rebuild all of your external modules. My thoughts exactly. And I'm sure a welcome addition. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Suggestion: ebuilds linked to kernel upgrade
> 2005/10/19, Herbert G. Fischer <[EMAIL PROTECTED]>:
> Perhaps the modules-update could be extended to detect new
> kernels and warn users or automatically update modules. This
> could also be documented in Gentoo docs since this is a basic
> and common problem that almost every Gentoo user may have.
module-rebuild shouldn't really have this task. it isn't the right place
to do it. It will of course quite happily do what you need it to do,
rebuild anything which installs a kernel module from portage.
>
> 2005/10/19, John Myers <[EMAIL PROTECTED]>
> if [ -n "$(which module-rebuild 2>/dev/null)" ] ;
> then
> if [ -n "${AUTO_MODULE_REBUILD}" ] ; then
> echo "Rebuilding external modules:"
> module-rebuild ${MODULE_REBUILD_OPTIONS}
> rebuild
> else
> echo "You might want to rebuild the following
> external modules:"
> module-rebuild -XC list | tail -n +2
> echo
> echo "You can use module-rebuild to do that."
> echo "If you want to have your external
> modules automatically rebuilt"
> echo "when making a kernel's modules_install
> target, set"
> echo "AUTO_MODULE_REBUILD in your environment.
> You can set"
> echo "MODULE_REBUILD_OPTIONS to options to
> pass to module-rebuild."
> echo "(-X for example)"
> fi
> else
> echo "You might want to emerge
> sys-kernel/module-rebuild to keep track of"
> echo "kernel modules you've installed with
> emerge"
> fi
>
I don't particular feel comfortable doing this. the only place I can
actually see this being of some use is with the pkg_config since an
ebuild postinst is far too soon, and patching up Kbuild to do this is
far too intrusive (let alone high maintenance).
A possibility (although I wouldnt like to promote it through portage)
would be to have a wrapper/helper script which would do all of this for
you. build-kernel or some such. But then... whats genkernel for right?
- John
--
Role:Gentoo Linux Kernel Lead
Gentoo Linux:http://www.gentoo.org
Public Key: gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515
Web:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] linux-info.eclass and $CONFIG_CHECK
On Wed, 2005-09-21 at 12:03 -0400, Chris Gianelloni wrote: > The current /usr/src/linux method works quite well for releases. The > only issue we're having is a non-fatal check being fatal, which is going > to be fixed. OK, so being the huy who wrote and looks after all this stuff, here is my 2c and reasoning. First of all, falling back on `uname -r` isn't going to happen for several reasons. I can understand for some why this might seem sensible (what happens if you remove your kernel sources for example). But the fact remains that testing the currently running kernel is not a viable option in my mind. Why? well, 1: the running kernel bares absolutely no relevance on the environment which you're building this for. 2: you can pass KERNEL_DIR manually, so if you refuse to work in the expected way then set KERNEL_DIR to point to the right location. Secondly, I have thought about this some more during the day, just as I did at initial implementation (The code could do with a tidy-up anyways). After much deliberation I feel the actual best way to deal with this, is to have an override envvar which will bypass a die, and simply warn instead. This will mean that those people who cross-compile regularly, or building stages etc will work fine, and normal operation would continue to refuse a build if the environment its building for doesn't seem sane. At the end of the day, the true root cause of something die'ing when it shouldn't is at the ebuild. That.. and if its really not that important, then surely the ebuild can call the config check itself, and handle it as it feels fit. I'll update the bug also with this. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] USE="minimal" for kernel sources
On Thu, 2005-09-08 at 22:14 +0200, Jan Kundrát wrote: > Er, but why is this a problem? Does it matter that the package will > install different files on x86 than on mips? Or am I just overlooking > the point? In general, there is no obvious technical reason against individual installs differing from one another, however from a support and QA point of view it makes it a much less trivial issue. At the end of the day, when it comes to USE=minimal no-one can fully confirm what does, and does not exist (can cause breakages may I add) when it comes to supporting a bug, and also we can't promise it wont destroy an arch tree which you need. I'm thinking obscure (or not quite so) architecture. Pegasos, Sun, Sparc, SH, arm, etc. Although Kbuild is more than capable of functioning with only the required arch tree, what happens when it comes to things like cross-compile, not just of the sources but of anything else which might use them later on? ipw2200? nvidia? alsa-drivers? Just a bit of a worry to me, and not something I would really like to endorse. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] USE="minimal" for kernel sources
For the record, there is a bug open for this. (#64009) Personally, I'm not keen on the idea. the only way which we can do this is by detecting which arch we are installing the sources, for, which immediately means many installs of USE=minimal are not the same. There are plenty of other reasons I can go into, but if anyone feels strongly to push this change, then feel free to reply with justification as to why. Technical info to back it up as well please :) - John On Thu, 2005-09-08 at 20:17 +0200, Diego 'Flameeyes' Pettenò wrote: > On Thursday 08 September 2005 20:10, solar wrote: > > Perhaps you can simply just take advantage of tar's > > --exclude=/-e options in the unpack() function of ebuild.sh when > > USERLAND == GNU > tar --exclude/-e is supported by both bsdtar and gtar. > -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] devfs is dead, let's move on
On Wed, 2005-07-06 at 15:46 -0700, Greg KH wrote: > If we can move away from some of our devfs-like names, we stand to > reclaim a lot of memory from everyone's machines. As an example, if we > drop all of the tty/pts/vc/vcc symlinks, and just go with the default > kernel name, we save 2.5Mb of space in tempfs/ramfs. I've done this on > my machines and everything seems to work just fine (it looks like > everything that was trying to use a tty node was just using the symlink > anyway.) > > So, anyone have any objections to me changing the default udev naming > scheme in this manner? 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. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 38: Status of forum moderators in the Gentoo project
On Tue, 2005-06-28 at 17:49 -0400, Olivier Crete wrote: > On Tue, 2005-28-06 at 07:20 -0400, Jon Portnoy wrote: > > On Tue, Jun 28, 2005 at 12:57:46PM +0200, Ioannis Aslanidis wrote: > > > On 6/28/05, Shyam Mani <[EMAIL PROTECTED]> wrote: > > > > > > Does it really matter you if we are called developers instead of staff? > > > > > > > Yes. You don't develop anything > > Neither do infra devs or doc devs... I'd beg to differ there actually. Infra developers are more often than not package maintainers etc as well, and have cvs rights. if they don't have cvs rights, they look after core infrastructure which is vital to Gentoo's survival. Documentation devs, develop rather large and quite excellent online (and offline) documentation. Not to take away from the importance (or lack of depending on view) of moderating the forums, but they are not as critical as official literature and infrastructure, and also do not necessarily require in depth knowledge of the technical aspects of any post. Regardless, I would prefer the term "Staff." Also, I don't really see the need in having shell access to the developer boxes. what use would this be? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last chance to save media-plugins/bmp-outlame
On Sun, 2005-05-08 at 18:14 +0100, Tony Vroon wrote: > > > It has been masked since March 12. > > It was scheduled for removal for a long time, I really think that anyone > interested in picking it up would have let me know by now. > Do you want me to wait longer? (I take it this is about the mail > deadline, not about the masking). yeah its just about the email. It would be nice if you waited until say, Tuesday, 20:00GMT before removal. It will then give those possibly interested in it enough time to look at it. Regards, John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last chance to save media-plugins/bmp-outlame
Although I am not interested in looking after this, is 4 hours and 20 minutes notice enough to claim a new maintainer? On Sun, 2005-05-08 at 15:38 +0100, Tony Vroon wrote: > bmp-outlame causes instability with large playlists, and may seriously > impair BMP's ability to play MP3 files. > It has been masked since March 12. > > Should you want to save it, a patch is expected that makes it behave > correctly. If you're a dev, I expect you to maintain this package > afterwards. > > If I don't hear anything by 20:00 GMT, it's a goner. > > Tony (Chainsaw). -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] OffTopic: VMWare ESX
Unfortunately it has to be vmware. Xen is excellent fro many things, but this ESX server is considerably different to most things. Anyways, aside from that the choice of product has been made. Just not the decision to go with it. So that's what this is for. Some real life feedback. On Wed, 2005-05-04 at 23:37 +0200, Jan KundrÃt wrote: > John Mylchreest wrote: > > basically, What I was wanting to know is actual hands-on experience. > > Whats it like? Pros? Cons? What to watch out for? what its exceptionally > > good at? whats it exceptionally bad at? bugs? all the normal kind of > > questions really. How is it so different to vmware workstation? what big > > management (of guest OS and resource allocation) features are there? > > *Really* OT here, but you may find Xen (http://xen.sourceforge.net/) > interesting. > > -jkt > -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] OffTopic: VMWare ESX
Hi there, thanks for getting back to me. basically, What I was wanting to know is actual hands-on experience. Whats it like? Pros? Cons? What to watch out for? what its exceptionally good at? whats it exceptionally bad at? bugs? all the normal kind of questions really. How is it so different to vmware workstation? what big management (of guest OS and resource allocation) features are there? Also, if you can, how you use it. what it is you do with it? Application clustering? etc etc. All the stuff which doesnt come out of press releases, reviews and promos :) Cheers, in anticipation :) Regards, John P.S. DK, what happened last fall is water under the bridge. Misconceptions all around, and glad to see your still here. On Wed, 2005-05-04 at 15:12 -0400, Omkhar Arasaratnam wrote: > John Mylchreest wrote: > > >Hi All, > > > >Apologies for posting my question to such lists, but it hits the exact > >audience I'm after a response from :) > > > >Does anyone at work run Vmware ESX Server? If so, could they please get > >in touch with me so that I might talk about experiences? > > > >Regards, > >John > > > > > > > John, > > I've worked with it before and have a number of colleagues in the field > - what's up? > > -- > > Omkhar Arasaratnam - Gentoo PPC64 Developer > [EMAIL PROTECTED] - http://dev.gentoo.org/~omkhar > Gentoo Linux / PPC64 Linux: http://ppc64.gentoo.org > -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515 signature.asc Description: This is a digitally signed message part
[gentoo-dev] OffTopic: VMWare ESX
Hi All, Apologies for posting my question to such lists, but it hits the exact audience I'm after a response from :) Does anyone at work run Vmware ESX Server? If so, could they please get in touch with me so that I might talk about experiences? Regards, John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] module-rebuild
I thought about this, but not wanting to depend on gentoolkit makes using equery for example a little awkward. This, I'm sure isn't fully feature-rich yet - and something like this will be the next addition to go in. On Wed, 2005-05-04 at 15:24 +0900, Georgi Georgiev wrote: > maillog: 04/05/2005-00:00:38(+0100): John Mylchreest types > > Hi All, > > > > Can I please introduce into the tree sys-kernel/module-rebuild. > > This tracks linux-mod installed kernel modules, and also gives you the > > ability to remove/add/toggle the list of modules to rebuild. > > > > Basically.. following a kernel upgrade running: module-update rebuild, > > will install all modules installed via portage. > > > > If you experience any problems, please file a bug at bugzilla. Likewise, > > please file a bug and assign it to [EMAIL PROTECTED] if you have any > > ideas about the tool. > > I personally think that the following is sufficient: > > # emerge -pv $(equery b /lib/modules | sed -e 's:^:>=:' ) > > These are the packages that I would merge, in order: > > Calculating dependencies ...done! > [ebuild R ] media-sound/alsa-driver-1.0.9_rc2 -debug -doc +oss -pcmcia 0 > kB > [ebuild R ] media-video/nvidia-kernel-1.0.7174 -pcmcia 0 kB > [ebuild R ] sys-fs/cdfs-2.6.3a 0 kB [1] > > Total size of downloads: 0 kB > Portage overlays: > [1] /usr/portage-chutz > [2] /usr/portage-maildir > > I am not trying to shoot down your idea, but you could probably use > something similar to automatically generate the list of packages to > rebuild if the database is empty? > -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515 signature.asc Description: This is a digitally signed message part
[gentoo-dev] module-rebuild
Hi All, Can I please introduce into the tree sys-kernel/module-rebuild. This tracks linux-mod installed kernel modules, and also gives you the ability to remove/add/toggle the list of modules to rebuild. Basically.. following a kernel upgrade running: module-update rebuild, will install all modules installed via portage. If you experience any problems, please file a bug at bugzilla. Likewise, please file a bug and assign it to [EMAIL PROTECTED] if you have any ideas about the tool. On a side-note, give it an hour before you sync and merge this thing :) Regards, John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515 signature.asc Description: This is a digitally signed message part
[gentoo-dev] kernel-mod.eclass deprecation and effected ebuilds
Hi all, For some time now kernel-mod has been deprecated in favour of linux-mod (or linux-info in some cases). linux-mod is much tidier, accurate, and portable. Most of our ebuilds have already been migrated to using the new eclass, but the following still remain. As some good template examples please look at: ipw2200-1.0.3, nvidia-kernel, hostap-driver-0.3.7 If you are willing to update this, or you are the official maintainer please shout out the ebuilds you're claiming. We can address the rest then. The list of effected ebuilds are as follows: app-laptop/acerhk/acerhk-0.5.18.ebuild media-libs/svgalib/svgalib-1.9.19-r3.ebuild media-sound/emu10k1/emu10k1-0.20a-r7.ebuild media-sound/emu10k1/emu10k1-0.20a-r6.ebuild media-sound/emu10k1/emu10k1-0.20a-r5.ebuild media-sound/alsa-driver/alsa-driver-1.0.3.ebuild media-tv/linuxtv-dvb/linuxtv-dvb-1.1.1-r1.ebuild media-tv/rivatv/rivatv-0.8.5-r2.ebuild media-video/mplayer/mplayer-1.0_pre7.ebuild media-video/mplayer/mplayer-1.0_pre5-r5.ebuild media-video/mplayer/mplayer-1.0_pre6-r4.ebuild media-video/mplayer/mplayer-1.0_pre6-r6.ebuild media-video/mplayer/mplayer-1.0_pre6-r5.ebuild media-video/qc-usb/qc-usb-0.6.0.ebuild net-firewall/tuxfrw/tuxfrw-2.58-r1.ebuild net-misc/cisco-vpnclient-3des/cisco-vpnclient-3des-4.6.02.0030.ebuild net-misc/cisco-vpnclient-3des/cisco-vpnclient-3des-4.0.5.ebuild net-misc/cisco-vpnclient-3des/cisco-vpnclient-3des-4.6.00.0045-r1.ebuild net-misc/cisco-vpnclient-3des/cisco-vpnclient-3des-4.0.3b-r4.ebuild net-misc/cisco-vpnclient-3des/cisco-vpnclient-3des-4.0.1a-r1.ebuild net-misc/zaptel/zaptel-1.0.3.ebuild net-misc/zaptel/zaptel-1.0.0.ebuild net-misc/zaptel/zaptel-1.0.2.ebuild net-misc/zaptel/zaptel-1.0.1.ebuild net-wireless/hostap-driver/hostap-driver-0.2.5-r1.ebuild net-wireless/rfswitch/rfswitch-0.1.ebuild net-wireless/madwifi-driver/madwifi-driver-0.1_pre20041019.ebuild net-wireless/madwifi-driver/madwifi-driver-0.1_pre20050106.ebuild net-wireless/orinoco/orinoco-0.15_rc2.ebuild sci-misc/comedi/comedi-0.7.68.ebuild sci-misc/comedi/comedi-0.7.67.ebuild sys-apps/realtime-lsm/realtime-lsm-0.8.2_pre20041022.ebuild sys-apps/realtime-lsm/realtime-lsm-0.8.3.ebuild sys-apps/realtime-lsm/realtime-lsm-0.8.5.ebuild sys-fs/cloop/cloop-0.68.ebuild sys-fs/cloop/cloop-2.01.5.ebuild sys-fs/cloop/cloop-2.00.ebuild sys-fs/cloop/cloop-1.0.ebuild sys-fs/cloop/cloop-1.02.ebuild sys-fs/cryptsetup/cryptsetup-0.1.ebuild sys-fs/cryptsetup/cryptsetup-0.1-r1.ebuild Regards, John -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515 signature.asc Description: This is a digitally signed message part
