Re: [gentoo-dev] Future developer
On Sat, 1 Jul 2006 20:00:46 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: On Saturday 01 July 2006 00:31, Seemant Kulleen wrote: Paul, Congratulations! What did you and your wife name him? When exactly was he born, etc? Give us details!! :) Official name: Tom Wei Calling name: Tom Last name: de Vrieze Gender: male Nationality: Dutch and Chinese (PRC) Birthdate: 26-06-2006 Time of Birth: 10:22am (Netherlands time) Place of Birth: Radboud University Hospital (Nijmegen) Commendable choice of forename. Congratulations, -- Tom Martin, http://dev.gentoo.org/~slarti AMD64, net-mail, shell-tools, vim, recruiters Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] TreeCleaner June Removals
Alec Warner wrote: dev-libs/nana bug # 32672 - Removed x11-wm/blwm bug # 71479 - Removed app-editors/gnotepad+ bug # 122993 - Removed net-misc/powerd bug # 70373 - Removed dev-lisp/cl-clx-sbcl bug # 134623 - Removed app-office/gnofin and gnome-extra/gnobog bug # 134624 - Removed net-p2p/dc-gui bug # 134630 - Removed dev-lisp/cmucl-source bug # 134633 - Removed package.mask - Cleaned (also removed perforce from pmask for bug # 123923 Just wanted to say what a great job you've been doing with the Tree Cleaners Project. Keep up the good work, we all appreciate it. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Re: GPL and Source code providing
On Sat, 2006-07-01 at 11:12 +, Duncan wrote: For example, if we hand out CDs at conventions etc, we would have to also hand out source CDs. As my reply there, however, Gentoo does still have it better than most, in that the LiveCDs contain relatively few binaries, and they tend to be relatively core packages to which sources should still be available even for historic releases, should we wish to continue distributing the historical LiveCDs. The packages CDs OTOH... Umm... The LiveCD has almost 700 packages on it. Perhaps you mean the InstallCD? Again as I mentioned there, I'd suggest retiring package CDs 30 days after the next release is out, thus eliminating the largest share of the problem. With the limited binaries on the LiveCDs, it may be worth keeping the sources around as well as the LiveCDs, for historical reasons. Elsewise, I'd suggest retiring them 30 days after the /second/ release to come out after them. That should reduce Gentoo's sources requirement to a manageable level. Beyond that, whether those current minus-one packages, and current minus-two liveCDs, sources should be hosted on an archive server or continue on the mirrors is for Infra to decide. I'd suggest a policy that has RelEng archiving sources to an archive host as part of the RelEng process, as the most reliable and least hassle. Then they'd be there, and could be removed at any point after the parallel CDs using their binaries had been removed. However, others may have more workable ideas, and I'm not a dev let alone Infra, so wouldn't wish to pretend to decide what's best for them. Please don't pretend that you can decide what's best for Release Engineering, either. =] -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for July
On Sat, 2006-07-01 at 19:23 +0200, Stefan Schweizer wrote: Hi, Can we have another Sunrise discussion please? I would love to have some feedback about Sunrise, about our progress and where we are still lacking. What exactly is there to discuss about this? It is not an official project anymore, so the council really has no bearing on it. I'm guessing you would like for it to become an official project. If I were asked, some of the things I would bring up are: What has the existence of Sunrise done for Gentoo? What new packages are now in the tree because of it? What new developers have been recruited because of it? What packages that were previously without maintainers in the tree have found maintainers due to Sunrise? I think you fail to see that for something like Sunrise to prove itself as a viable Gentoo project, it has to actually accomplish some of its stated goals. That being said, if the council wants to discuss it, they're more than welcome to. I just personally feel it wouldn't be time well spent. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: GCC 4.1.1 testing/stablization and glibc 2.4
On Sat, 2006-07-01 at 12:18 -0600, Ryan Hill wrote: Chris Gianelloni wrote: OK, guys, I was speaking with vapier earlier about the possibility of getting gcc 4.1.1 stable for the 2006.1 release. We've managed to build some release media with it, and are planning on doing more testing with it. What we really need is for more people to test this on various platforms and to get all of the bugs worked out that we can. We're already ramping up our release cycle, and would like to get this included, so we don't have to wait until 2007 for a release with = GCC 4.1 in it. Should arch testers start working with 4.1.1 then? And do you want bugs to block #117482? Arch testers should contact their architecture's leads or Release Engineering Architecture Coordinator. As for bug reports, yes. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Last rites: net-wireless/bluez-kernel
On Wed, Jun 21, 2006 at 05:25:45PM +0200, Henrik Brix Andersen wrote: If nobody objects I'll package.mask net-wireless/bluez-kernel in 7 days, pending removal 30 days later. Added to package.mask pending removal, bug #132600. ./Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpqxyWEXFZbE.pgp Description: PGP signature
Re: [gentoo-dev] Last rites: net-wireless/bluez-kernel
All what that package provides is already in the vainilla kernel. That's why it isn't being updated anymore. Personally, and due to the fact that it is even advised to not use bluez-kernel, I would proceed with the masking and removal asap. On 7/2/06, Henrik Brix Andersen [EMAIL PROTECTED] wrote: On Wed, Jun 21, 2006 at 05:25:45PM +0200, Henrik Brix Andersen wrote: If nobody objects I'll package.mask net-wireless/bluez-kernel in 7 days, pending removal 30 days later. Added to package.mask pending removal, bug #132600. ./Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd -- Ioannis Aslanidis deathwing00[at]gentoo.org 0xB9B11F4E -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for July
Chris Gianelloni wrote: What exactly is there to discuss about this? Evaluating our progress with hashing out the details etc. It is not an official project anymore, so the council really has no bearing on it. I'm guessing you would like for it to become an official project. correct. If I were asked, some of the things I would bring up are: What has the existence of Sunrise done for Gentoo? - We have formed a #gentoo-sunrise channel with an atmosphere of help and friendliness - We are teaching many people how to write ebuilds correctly and how to use repoman to check for QA problems, etc. What new packages are now in the tree because of it? For example I have added a fix for ftpd and libvc to the tree. I also bumped media-video/dvd-slideshow. Markus Ullman added net-analyzer/wireshark from a sunrise contributor, drchandra, to portage. What new developers have been recruited because of it? Recruiting is a long-term goal. We already have a two people that have done the ebuild quiz, one other is working on it. It is like release work: they will be released as developers when they are ready. I do not want alpha-developers on the tree. And no, we will not reveal the release date ;) What packages that were previously without maintainers in the tree have found maintainers due to Sunrise? I mentioned a few packages above where I fixed bugs because of sunrise people, that does not mean they found maintainers, but people care about it and I can commit their fixes if needed. I think you fail to see that for something like Sunrise to prove itself as a viable Gentoo project, it has to actually accomplish some of its stated goals. Looking up the stated goals in the cvs log: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/sunrise/index.xml?hideattic=0view=markup encourage users to write ebuilds find new recruits make maintainer-wanted ebuild access and development easier work with users on new ebuilds and explain them what they can do better We have only found potential recruits but at least those four have been reached. That being said, if the council wants to discuss it, they're more than welcome to. I just personally feel it wouldn't be time well spent. Not discussing is not a solution either. The last userrel-meeting about sunrise was very successfull. If you want we can make another meeting and talk about it together before the council meeting? I would love that, to hear some more about your ideas for the stated goals of Sunrise and get issues sorted out without (perceivedly) offensive mails on the developer mailing list. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for July
On Sunday 02 July 2006 10:10, Chris Gianelloni wrote: On Sat, 2006-07-01 at 19:23 +0200, Stefan Schweizer wrote: Can we have another Sunrise discussion please? I would love to have some feedback about Sunrise, about our progress and where we are still lacking. What exactly is there to discuss about this? the answer to this is really quite obvious What has the existence of Sunrise done for Gentoo? What new packages are now in the tree because of it? What new developers have been recruited because of it? What packages that were previously without maintainers in the tree have found maintainers due to Sunrise? why do any of these matter at this point of time ? you cant kill a project for failing to accomplish any of its goals when it hasnt been given real time yet to actually accomplish them -mike pgp3qcExZ3ECz.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: [experiment] Sunrise try 2
Stefan Schweizer wrote: Serverside checks are overkill imo since we check that later ourselves when reviewing. It is also harder to implement in general and especially now because the administrator of the server, jokey, has exams this week. Nope, you need them to avoid smart stupid situation: - smart enough to circumvent the checks - stupid enough to commit something that doesn't pass the checks or just because I'm paranoid and you may add $bad_stuff in the global scope, bypass the checks clientside and let people have fun once they fetch the stuff.. just a check that prevents commands in global scope and/or shutting down sandbox is a must. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 15968 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 196 minutes.
--
gentoo-dev@gentoo.org mailing list
