Re: [gentoo-dev] [RFC] C++ herd proposal
Georgi Georgiev wrote: - that package in my overlay that has net-wireless/gnome-phone-manager in its *DEPENDs to work for as long as needed gnome-phone-manager can be found in portage tree under app-mobilephone category. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] C++ herd proposal
maillog: 20/09/2005-09:37:23(+0300): Alin Nastac types Georgi Georgiev wrote: - that package in my overlay that has net-wireless/gnome-phone-manager in its *DEPENDs to work for as long as needed gnome-phone-manager can be found in portage tree under app-mobilephone category. So that's why my overlay got screwed up! But seriously, this only supports my point -- category moves are evil. -- / Georgi Georgiev/ Putt's Law: Technology is dominated by two/ \ [EMAIL PROTECTED]\ types of people: Those who understand what \ / +81(90)2877-8845/ they do not manage. Those who manage what / \ --- \ they do not understand. \ pgpcsS58zjKuP.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] C++ herd proposal
Georgi Georgiev wrote: maillog: 20/09/2005-09:37:23(+0300): Alin Nastac types Georgi Georgiev wrote: - that package in my overlay that has net-wireless/gnome-phone-manager in its *DEPENDs to work for as long as needed gnome-phone-manager can be found in portage tree under app-mobilephone category. So that's why my overlay got screwed up! But seriously, this only supports my point -- category moves are evil. portage isn't supposed to offer eternal functionality status for personal overlays. what if an eclass gets obsoleted and eventually is removed from the tree? the only problem is binary packages screw up. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] C++ herd proposal
On Tue, 2005-09-20 at 08:54 +0200, Kevin F. Quinn wrote: On 20/9/2005 7:37:19, Georgi Georgiev ([EMAIL PROTECTED]) wrote: maillog: 20/09/2005-07:21:08(+0200): Christian Parpart types On Monday 19 September 2005 15:22, warnera6 wrote: Mark Loeser wrote: Paul de Vrieze wrote: I think that dev-util is a very specific category containing development utilities of some sort. There might be some misclassifications in them, but from a user perspective I don't really care about the language anything is written in. As C++ is so widespread I don't think that anything but app-misc or the like should be moved into a dev-cpp category. This isn't for what the package is written in, but more for what the package is for. If the package is a utility for use when doing coding with C++, like the ones I listed, then I think it should be in dev-cpp. That's what the metadata for the category describes it to be. Mark Once again I'd like to point out that organizing packages in the tree by category is a stupid idea for this very reason. and what's *your* certain proposal then? That's been discussed a number of times already. The best idea is to leave the categories alone and forget that the category means anything. Or, to throw the ball back in your court, could *you* suggest alternatives that accomplish the following: (quoting [1]:) More precisely, what I'd like to see, in order of preference, is - that package in my overlay that has net-wireless/gnome-phone-manager in its *DEPENDs to work for as long as needed - the net-wireless/gnome-phone-manager that I have in my overlay to work for as long as needed - my net-wireless/gnome-phone-manager binary packages to work without having to be fixpackaged - the location of the ebuilds for net-wireless/gnome-phone-manager to stay in the same physical path on my filesystem end quote I would grade the above features as vital, badly needed, happy to see it done, cosmetic. I.e., even solving only the first one is enough, though if you could get to number two it would be better. Here's another requirement I'd like to add to the list: - when moving stuff around, change history moves too CVS doesn't support this, but subversion does (along with atomic commits, also useful to ensure integrity of the tree during a move). The support for symlinks in subversion may also provide a way to resolve the overlay problem... Technically it does support it if said developer gets Infra to move it server side some nasty side effects, etc, but lots better than our current situation where some bright spark removed most if not all history of stuff that was moved :/ -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] cvs keywording.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: On Mon, 2005-09-19 at 20:38 +0300, Alin Dobre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alec Warner wrote: Official policy states that CVS ebuilds should never be marked stable[1]. Yet many ebuilds that are based on cvs sources and are marked stable on arch's. I would like to know why this is so. ./net-misc/netcomics-cvs/netcomics-cvs-0.14.1.ebuild:KEYWORDS=x86 ~amd64 ./games-fps/blackshades-cvs/blackshades-cvs-20031110.ebuild:KEYWORDS=x86 ~ppc ~amd64 ./dev-embedded/sdcc-cvs/sdcc-cvs-2.4.0-r1.ebuild:KEYWORDS=x86 ~ppc amd64 ./games-fps/avp-cvs/avp-cvs-20031110.ebuild:KEYWORDS=x86 This was just a hacked up search I did on the tree while in class, and is no way inclusive of all packages breaking policy. If you want bugs for them, I 'll make them. [1] http://devrel.gentoo.org/handbook/handbook.xml?part=2chap=3#doc_chap1_sect9 ;-) The two games listed are CVS snapshots, not live CVS builds. A live CVS build should never be stable. A snapshot is a known set of files, and can be marked stable. It is usually a known-good working set of files, taken from CVS, but not tied to an actual release version, and added to our mirrors by the package maintainers. Indeed I suck at this :) Sorry games team ;) The other two packages I checked by hand ( and not a craptastic script ) to make sure they were live cvs ebuilds. I have filed bugs [1,2] for them. [1] http://bugs.gentoo.org/show_bug.cgi?id=106663 [2] http://bugs.gentoo.org/show_bug.cgi?id=106662 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQy/h9GzglR5RwbyYAQIUMQ//Sb/fsEHazPnh9sHTvhCmlyNowfTOhFDO h9kL/mwphuaVtMlXsoXT0DoVNND7Z7+us3UFf6DEDifV0bA5HGtBJj1eNZix+Hyc r9i7D2PHgd9YvUtlaJvW4/C1vRRhobqcKrhzTWKkjhsMkoBlIX5K6dVRDxy/oSv4 /2qc0S8+GQBzpVBvf6JkvK9A5+e/QLbkeTiJAtJwWynbB4j1mPaiam53Uviy/OEw KPnsJhxZb5CVEor2C8hZBRyeczqo4HlYBD8pQDYNMV7NHKItKBatBJVqIAy1FxlQ wYW1i8r2atuxN+xJMSFoSa9fpNLoyQd2Z76Lxlqmy16zatcoKuvp/ONbAnU/lDym ZwbOQVt6Y047Hdkz/RNaxXaBXlq0+2cVLPFZ9VVaMW+d2XCjLrNu3baFRQd6MZyb plRCu6XETJ3hpTzOqvdLTUO1HPUZGBAF2MGtoVmoBuLVaLT96cvb+x75GC29n9xz g8kkILRpZNfE424rqvQb1kaAR3V9z1hQNtCB8Miqe5QQaA7UjDV7UQ6YAjU/ubf2 ZtptEzXHjVAwsZhAeSXen/ImAKUf1G+KvGMpcnVTCRifWNQ8yPYj4+BuXy6BmEWj rZnBUWS/TMADvIHbC3Z8yH0VWSBq5SeXWHtY2lNFVnnGLOI6bcylNhPmFHUu82f8 0onAwV82rDY= =2lVV -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] C++ herd proposal
On Tue, Sep 20, 2005 at 10:01:39AM +0300, Alin Nastac wrote: Georgi Georgiev wrote: maillog: 20/09/2005-09:37:23(+0300): Alin Nastac types Georgi Georgiev wrote: - that package in my overlay that has net-wireless/gnome-phone-manager in its *DEPENDs to work for as long as needed gnome-phone-manager can be found in portage tree under app-mobilephone category. So that's why my overlay got screwed up! But seriously, this only supports my point -- category moves are evil. portage isn't supposed to offer eternal functionality status for personal overlays. Eh? what if an eclass gets obsoleted and eventually is removed from the tree? Pull from viewcvs. I assume you're talking about portage =2.1 capabilities, since you *cannot* remove an eclass from the tree once it's been added currently. the only problem is binary packages screw up. Binpkgs should be running from their own env, they should be stand alone not requiring even a tree. Back on subject... I *really* don't like categories. Single vdb, single repo, single binpkg, it's not horrible. Multiple true, standalone repos, with the occasional binpkg repo used? It makes doing the category move *really* rather hard, since you need to track down exactly which repository and ebuild came from. ~harring pgp81JlK7zAMI.pgp Description: PGP signature
Re: [gentoo-dev] UK Linux Expo
lo, On Monday 19 September 2005 10:14, Rob Holland wrote: All, This is a gentle reminder that the UK Linux Expo is on 5th-6th October at Olympia, London. Gentoo will have a (small) booth at the expo, so if you are interested in being in the booth (dev's only I'm afraid) please let me know. I will be drawing up a rota on Wednesday, so if you've not replied by email or IRC by then, you will struggle to get a time slot to strut your funky stuff in the booth. Hopefully I will be there both days but I will definitely be there on the Wednesday (barring something breaking at work) so slot me in for a stint sometime then. PS rob make sure you have time for that beer afterwards ;) -- Benjamin Smee (strerror) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] C++ herd proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Schlemmer wrote: | Technically it does support it if said developer gets Infra to move it | server side some nasty side effects, etc, but lots better than our | current situation where some bright spark removed most if not all | history of stuff that was moved :/ Not really any side effects if you do it right. Copy the ,v files (don't just mv them), then cvs rm in the old location. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDMDmaXVaO67S1rtsRApZtAKCefgS2okfjNcpQpBUekthLdj4XhgCguCMQ zFLmx9mPBX+dYwR/YS5WE6M= =BwBQ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] PATCH: gentoolkit: Make portage.config object a global object
On Tue, 2005-09-20 at 19:00 -0500, Brian Harring wrote: On Tue, Sep 20, 2005 at 06:55:44PM -0500, Paul Varner wrote: On Tue, 2005-09-20 at 18:34 -0500, Brian Harring wrote: Updated patch to add a semaphore to control access to the global portage.config object. Unless anyone sees any other issues with this patch, I will be placing it into gentoolkit. Reason for a semaphore over threading.Lock ? No reason other than I'm used to thinking of them as semaphores instead of locks, so semaphore is what I searched for in the Python docs. Need to make some chunks of the rewrite thread safe, so I poked a bit; python -m timeit -n 1 -r 3 -s 'import threading;s=threading.Lock()' 's.acquire();s.release()' around 1us python -m timeit -n 1 -r 3 -s 'import threading;s=threading.Semaphore()' 's.acquire();s.release()' 20us Okay, I've changed the Semaphore to a Lock and removed the self._settings.reset() call. Anything else before I commit this? Regards, Paul PS: As an aside the command 'equery hasuse perl' goes from 34s to 2s on my Pentium 4 with this patch. -- gentoo-portage-dev@gentoo.org mailing list
