[gentoo-dev] Summer of code!
Hi potential students! I wanted to give you all a heads up, as of today we are accepting student applications for Summer of Code. So if you are a student and you fancy writing some code this summer you should go check out Google's Student FAQ[1], Gentoo's project ideas[2] (keep in mind that you can come up with your own idea, if it's great then we'll dance with joy and accept it!) and if you are eligible and keen, you should head over to http://code.google.com/soc/student.html and apply! I hope to see plenty of new applications filling up our mentor interface! I can promise that it will be a fun and worthwhile experience for all who participate! Are you already a Gentoo developer but want to participate as a student? Don't be discouraged, you can apply and be accepted as long as you are not mentoring for any organisation (including Gentoo) and as long as you work on a project different to what you normally do (ie. if you normally work on portage, don't apply for a portage project during SoC). If you have any questions, drop a line to [EMAIL PROTECTED] or stop by #gentoo-soc on irc.freenode.net Cheers, Christel Dahlskjaer [1]http://code.google.com/soc/studentfaq.html [2]http://www.gentoo.org/proj/en/devrel/user-relations/summerofcode/index.xml -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Herds, Teams and Projects
On Friday 28 April 2006 21:29, George Shapovalov wrote: > Friday, 28. April 2006 21:20, Kevin F. Quinn (Gentoo) Ви написали: > > OK; just to clarify my understanding, and perhaps for anyone else > > watching who saw things as muddled as I did: > > [skip] > > Just to be really anal :) > > > 3) A herd does not have an email address - it's not a person or group > > of people so an email address is nonsensical. > > 3a) A herd has an associated alias A team that maintains a herd may create a convenient mailing address on which matters for the specified herd can be handled. This email address may be used for multiple herds. (and as such does not need to be @g.o) > 3b) Individual developers add yourself (explicitly or get added by means of > herds.xml (gentoo module in cvs, under misc)) to this alias. Many herd maintenance teams/projects do have a free entry policy where you can enter by adding yourself to the alias and the herds.xml file. This could be indicated in herds.xml by a comment in the herd tag. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpjsESxEMIta.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo: State of the Union
Stuart Herbert wrote: Hrm. Don't we get that benefit only if the overlays switch over to using the same distributed VCS that the main tree moves to? The short answer is yes. The long answer is that it's much easier to interconvert histories between most DVCS's than to convert back and forth between file-based history systems like CVS. One could plausibly and sanely export any commits from their mercurial overlay into e.g. git (or whatever ends up happening), suitable for merging into the official tree. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On Mon, 2006-05-01 at 13:23 +0100, Chris Bainbridge wrote: > The main purpose that comes to mind is to help the groups working in > overlays (layman -L shows 28 current overlays; there may be more). It > should enable easier merging of trees, local tree management, sharing > experimental changes between devs without commiting to the main tree, > while still retaining the possibility of easily pushing changes back > to the main gentoo tree. Hrm. Don't we get that benefit only if the overlays switch over to using the same distributed VCS that the main tree moves to? Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://blog.stuartherbert.com/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
[gentoo-dev] ANNOUNCE: Paludis 0.2.0
Ok, we're now officially admitting that Paludis exists (really this time), and is fit for an initial public release. Paludis is a library providing ebuild-related utilities together with a simple command line client. It is not a Portage rewrite, nor is it a Portage replacement, although it could be considered to be on its way to becoming a Portage alternative. Many of the features in Portage are not present in Paludis. Some of these features will appear in Paludis at a later date; some will not. Paludis is not Portage compatible, and should not be used on the same ROOT as Portage. Paludis will rape your dog. The homepage is at [1], and includes a HOWTO explaining how to set up a chroot built with Paludis. Note the bug tracker and mailing list; discussion of this lot on Gentoo lists is highly discouraged since it's not supported. The source can be found at [2] for those too lazy to use Subversion. Bug reports go via the bug tracker, preferably only after having discussed them in #paludis. So far most bugs we've found have been user or ebuild screwups. Feature requests and requests for doing stuff that Portage does are not welcome unless they come with a decent patch or are actually easy to implement rather than just looking like it; we are at the "make it more or less sanely usable" phase, not the "make it nice and shiny for end users" phase. Ricers will be terminated. For a list of differences between Portage and Paludis, see [3]. The list is not complete, nor does it attempt to be, but provides some points of interest that are intentionally different. Some of these are missing Portage features, while some are fundamental differences in design. All are subject to change without warning or reason. Paludis has been used to install at least one bootable system, complete with Xorg and Fluxbox. There was a full moon at the time. It cannot install Gnome because Gnome's deps are broken. It cannot install KDE because no-one can be bothered sitting and watching Qt compile. [1]: http://paludis.berlios.de/ [2]: http://developer.berlios.de/project/showfiles.php?group_id=6360 [3]: http://paludis.berlios.de/PortageDifferences.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo: State of the Union
On 30/04/06, Henrik Brix Andersen <[EMAIL PROTECTED]> wrote: On Sun, Apr 30, 2006 at 12:50:45AM -0700, Donnie Berkholz wrote: > While we're posting useful links, here's another one from the cairo > project on switching from CVS to some distributed SCM: All this talk about switching to a more powerful SCM I can understand - but what would the purpose of switching the portage tree to a distributed SCM be? The main purpose that comes to mind is to help the groups working in overlays (layman -L shows 28 current overlays; there may be more). It should enable easier merging of trees, local tree management, sharing experimental changes between devs without commiting to the main tree, while still retaining the possibility of easily pushing changes back to the main gentoo tree. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Having fun with compression
On 30/04/06, Patrick Lauer <[EMAIL PROTECTED]> wrote: Hi all, I had this random idea that many of our distfiles are .tar.gz while more efficient compression methods exist. So I did some testing for fun: If you already have an old copy of the distfile it's much more bandwidth efficient to transfer deltas. Many Gentoo users rarely clean out /usr/portage/distfiles so it could be quite a bandwidth saving to use something like zsync http://zsync.moria.org.uk/ . I did some tests a long time ago and found that a version bump of a package like kdegraphics produced a 300k uncompressed diff, which was 25x more bandwidth efficient to transfer with rsync than to download the full bz2 file. I haven't played with zsync yet, but the technical paper suggests it is close to 'rsync -z' in terms of bandwidth efficiency, and it removes some of the drawbacks of rsync, such as high server load and the requirement to run a special daemon. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for app-laptop/ibm-acpi
On Sat, Apr 22, 2006 at 04:52:20PM +0200, Henrik Brix Andersen wrote: > Unless somebody has a really good reason as to why we should keep the > external module in portage I will package.mask it in a week from now > and remove it from portage 30 days later. I have now p.masked app-laptop/ibm-acpi. It will be removed from the tree in 30 days. Regards, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd pgpo1ongyvx5X.pgp Description: PGP signature
[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 15060 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 218 minutes.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Having fun with compression
On Sun, 2006-04-30 at 22:36 -0500, Jon Hood wrote: > Hey Patrick, > I agree, tar.bz2 is the way to go when possible, but I have many > friends on old bsd-based systems and some old linux boxes I must > maintain that don't have bzip2 support. Normally if I know a package I > write is going to need to go on an older system, I'll package it in both > formats, but there are times when bz2 is just not an option. Is that a problem in the sense "it doesn't run at all" or is it "they'd need to install extra dependencies" ? > That having been said, it IS an option in 95%+ of the cases I deal > with, and for being on a cable modem, bzip2 has saved quite a bit of > time (and money) in the past. I just did a conversion run over all of distfiles just for fun (~10h on an AMD64) Input: 15634581 kB Output: 13462050 kB Difference: ~14% Compared to my earlier run with ~830M this has less difference, but I think users would appreciate a reduction of 10-30% of their downloads. Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
