[gentoo-dev] python-2.4.2 marked stable x86
There is a memory leak in python-2.4.1 so 2.4.2 was marked stable on x86. There isn't much listed in the changelog[1] upstream such as a patch or bug#, but Mr_Bones_ encountered it when running repoman on the full tree causing python to consume 400 megs of memory. [1] http://python.org/2.4.2/NEWS.html -- Rob Cakebread Gentoo Linux Developer Public Key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x96BA679B Key fingerprint = 5E1A 57A0 0FA6 939D 3258 8369 81C5 A17B 96BA 679B -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] python-2.4.2 marked stable x86
On Wed, 2005-10-12 at 23:41 -0700, Rob Cakebread wrote: There is a memory leak in python-2.4.1 so 2.4.2 was marked stable on x86. Is the memory leak specific to python-2.4.1? Or is it still present in 2.4.*? There isn't much listed in the changelog[1] upstream such as a patch or bug#, but Mr_Bones_ encountered it when running repoman on the full tree causing python to consume 400 megs of memory. [1] http://python.org/2.4.2/NEWS.html -- Rob Cakebread Gentoo Linux Developer Public Key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x96BA679B Key fingerprint = 5E1A 57A0 0FA6 939D 3258 8369 81C5 A17B 96BA 679B -- Lares Moreau [EMAIL PROTECTED] Gentoo x86 Arch Tester LRU: 400755 http://counter.li.org 127.0.0.1 Canada -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: python-2.4.2 marked stable x86
Fixed in 2.4.2 according to their Changelog. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] On Thu, 13 Oct 2005, Lares Moreau wrote: On Wed, 2005-10-12 at 23:41 -0700, Rob Cakebread wrote: There is a memory leak in python-2.4.1 so 2.4.2 was marked stable on x86. Is the memory leak specific to python-2.4.1? Or is it still present in 2.4.*? There isn't much listed in the changelog[1] upstream such as a patch or bug#, but Mr_Bones_ encountered it when running repoman on the full tree causing python to consume 400 megs of memory. [1] http://python.org/2.4.2/NEWS.html -- Rob Cakebread Gentoo Linux Developer Public Key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x96BA679B Key fingerprint = 5E1A 57A0 0FA6 939D 3258 8369 81C5 A17B 96BA 679B -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [RFC] New category for xmingw cross compile toolchain
Hi all, I am just wondering about people's option about making a new category, called something like dev-xmingw or similar. At the moment we have in portage: dev-util/xmingw-binutils dev-util/xmingw-runtime dev-util/xmingw-gcc dev-util/xmingw-w32api Which gives a usable W32 toolchain on gentoo using just standard W32 libraries. But every so often people submit ebuild for other libraries for use with this toolchain ( eg. http://bugs.gentoo.org/show_bug.cgi?id=101468 ) I have not added them up to now as it would, in my opinion, just clutter things. The other option is to make an external non-official tree that people could use as an overlay. Opinions? Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] New category for xmingw cross compile toolchain
Just a few opinions from the outside looking in... On Thursday 13 October 2005 12:25 pm, Stefan Jones wrote: I am just wondering about people's option about making a new category, called something like dev-xmingw or similar. Wouldn't set a precident for dev-gcc, dev-icc, dev-[enter alternate toolchain here]? The other option is to make an external non-official tree that people could use as an overlay. Personally I don't like that idea either. To me, external overlays are 'tainted' because they are not blessed enough to be part of the default gentoo tree. I therefore don't trust them and don't use them. Obviously that means I don't get the latest cutting edge stuff, but to have a stable gentoo environment I'm willing to make that sacrafice. Relegating these mingw stuff to an external overlay would carry the same 'taint' with it. And the fact that external non-official overlays are not really given much representation in the doco, most users looking for something like this would not have any idea that the external overlay existed and they could get the packages they're looking for from there. Like I said, just comments from an outsider... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] New category for xmingw cross compile toolchain
On Thursday 13 October 2005 12:25 pm, Stefan Jones wrote: dev-util/xmingw-binutils dev-util/xmingw-runtime dev-util/xmingw-gcc dev-util/xmingw-w32api i'd prefer to see these moved into the normal binutils/gcc ebuilds myself But every so often people submit ebuild for other libraries for use with this toolchain ( eg. http://bugs.gentoo.org/show_bug.cgi?id=101468 ) I have not added them up to now as it would, in my opinion, just clutter things. are these libraries special ? that is, are these things specific to xmingw ? or are they just ebuilds which take normal packages and force them to be compiled with the xmingw toolchain ? if they are xmingw-specific, then they should be added to the tree as sep packages, but if they are normal packages and these ebuilds are special hacks to cross compile them with xmingw, then they have no business in the tree -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Scratching of GLEP22
On Friday 07 October 2005 14:25, Chris Gianelloni wrote: Wouldn't it make more sense to get with the GLEP authors and propose a revision of the GLEP, since the concept is still the same Gentoo ALT KEYWORDS, to make it fit better with the current situation? Problem is that this would mean replace it with another GLEP then because it changes basically everything. I would have liked replies from someone else (maybe the GLEP editor?). Also because right now we're not following that scheme anyway right now... -- Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/ Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpHnEKYR0xGl.pgp Description: PGP signature
Re: [gentoo-dev] Scratching of GLEP22
Diego 'Flameeyes' Pettenò wrote: [Thu Oct 13 2005, 01:37:32PM CDT] Problem is that this would mean replace it with another GLEP then because it changes basically everything. I would rather it be replaced by another GLEP, personally. Just yanking it isn't sufficient, since it doesn't solve the problem of what to call the profile for a freebsd-based system that uses a gnu userland on x86. Or is the claim that no such name would be needed? The original e-mail suggesting yanking the GLEP wasn't really sufficiently for me to understand exactly how the replacement would work. Also because right now we're not following that scheme anyway right now... Which is fine, of course, since nothing is in the tree yet, but there will be real complaints if this stuff makes it into the tree w/o following that GLEP (or a new GLEP if it's approved). -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpQ7YbK3rW2D.pgp Description: PGP signature
[gentoo-dev] Someone's going to hate me -- test
Yeah, I know... need to check which adress I used for subscription... -- Benjamin Judas [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Python setuptools/eggs
Dave Nebinger wrote: I may be a bit of-base, but since I don't know much about the ruby gems, I'm wondering how close of a situation this is with the perl cpan modules? They're integrated to operate using the distribution process of both cpan and portage... They are similar. There is a project called g-gem [1] that uses the gems.eclass to generate ebuilds. A few of us had a good talk on Eggs on yesterday on irc and came up with a few proposals. I've setup SVN/Trac[2] so we can get things organized. Theres a very quickly dished-out eggs.eclass and test ebuild on the Trac site. [1] http://rubyforge.org/projects/g-gem/ [2] http://eggs.gentooexperimental.org/ -- Rob Cakebread Gentoo Linux Developer Public Key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x96BA679B Key fingerprint = 5E1A 57A0 0FA6 939D 3258 8369 81C5 A17B 96BA 679B -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Gentoo Linux preinstalled
Hi, I want to preinstall Gentoo Linux on some devices for customers. Do you have any tips for preinstallation, any scripts? What is the correct prcedure of doing so? Anyone knows of something like a sysprep script for linux that will ask the costumer for user and passwort setup when he first switches on the PC? On the technical side what I am currently doing is taking a normal setup, cleaning up distfiles, /usr/src, /tmp, /home, creating a new usser without any files of my own ;) cleaning out all my passwords of /etc. partimageing the partition, and dd'ing grub and sfdisking the partition table. Then playing back the images on the HDs I want to put into the devices later. Regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Handling compatible multi tools
Hi everybody,
Please don't start flaming me for this proposal, it's a discussion.
Now, we have in tree app-arch/bsdtar and app-arch/tar (gnu tar) that are
syntax compatible and can actually work fine on Gentoo/Linux or
Gentoo/FreeBSD or anything Gentoo/*..
Now they are probably the only two of a series of tools that might be choosen
from a list.
I already tried preparing a list, but right now, they are probably limited to
tar and mpg123/mpg321 ... sort of.
What I was thinking of is to standardize a way they can be handled. A part an
eselect module, what I was thinking of was a way to have (in this
case) /bin/tar remain what it is if it's a symlink.
Basically, I thought of this:
* don't install the symlink in src_install
* in pkg_postinst, look at ${ROOT}/bin/tar.. if it does exists, and it points
on something existing, don't touch it, otherwise, make it a link to the
current tar
* in pkg_postrm, if ${ROOT}/bin/tar points to something non existant, remove
it
at this point, gnu tar and bsdtar might share a virtual, and one can choose
the tar to use (obviously, the default remains on the os default tar, so
bsdtar for freebsd, and gnu tar for everything else).
It's probably incomplete, so I like proposals about this...
--
Diego Flameeyes Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgptEeSt3HPah.pgp
Description: PGP signature
Re: [gentoo-dev] [RFC] New category for xmingw cross compile toolchain
Mike Frysinger wrote: On Thursday 13 October 2005 12:25 pm, Stefan Jones wrote: dev-util/xmingw-binutils dev-util/xmingw-runtime dev-util/xmingw-gcc dev-util/xmingw-w32api i'd prefer to see these moved into the normal binutils/gcc ebuilds myself I do not think that would ever work well; the bootstrap method is a bit to out of sync with the GNU/Linux target Plus it would mean I would step on the gcc maintainers toes alot. [ xmingw cross compiled libraries] are these libraries special ? that is, are these things specific to xmingw ? or are they just ebuilds which take normal packages and force them to be compiled with the xmingw toolchain ? About half (guess) are xmingw spercific; will not compile in GNU/Linux. Others are normal libraries which work on Linux but need special tricks to get working with the crosscompiler. if they are xmingw-specific, then they should be added to the tree as sep packages, but if they are normal packages and these ebuilds are special hacks to cross compile them with xmingw, then they have no business in the tree But what is the difference in effect? Both are libraries for the xmingw toolchain, but a line would need to be drawn otherwise I might as well port the entire cygwin distribution! Out of tree collection looks good; but I doubt anyone will find it and I do not really use xmingw! Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] New category for xmingw cross compile toolchain
On Thursday 13 October 2005 08:16 pm, Stefan Jones wrote: Mike Frysinger wrote: On Thursday 13 October 2005 12:25 pm, Stefan Jones wrote: dev-util/xmingw-binutils dev-util/xmingw-runtime dev-util/xmingw-gcc dev-util/xmingw-w32api i'd prefer to see these moved into the normal binutils/gcc ebuilds myself I do not think that would ever work well; the bootstrap method is a bit to out of sync with the GNU/Linux target glanced in the ebuilds and they dont look too bad to me ... this is how we do avr after all ... we punted the avr gcc/binutils ebuilds and now people have to `emerge crossdev crossdev avr` Plus it would mean I would step on the gcc maintainers toes alot. err, you mean me ? :) i dont think the other toolchain guys would care too much [ xmingw cross compiled libraries] are these libraries special ? that is, are these things specific to xmingw ? or are they just ebuilds which take normal packages and force them to be compiled with the xmingw toolchain ? About half (guess) are xmingw spercific; will not compile in GNU/Linux. these are OK then imho Others are normal libraries which work on Linux but need special tricks to get working with the crosscompiler. these are not valid then as sep packages if they are xmingw-specific, then they should be added to the tree as sep packages, but if they are normal packages and these ebuilds are special hacks to cross compile them with xmingw, then they have no business in the tree But what is the difference in effect? Both are libraries for the xmingw toolchain, but a line would need to be drawn otherwise I might as well port the entire cygwin distribution! i thought the line i drew was pretty clear ;) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] New category for xmingw cross compile toolchain
Mike Frysinger wrote: glanced in the ebuilds and they dont look too bad to me ... this is how we do avr after all ... we punted the avr gcc/binutils ebuilds and now people have to `emerge crossdev crossdev avr` Ok, many thanks Mike for the input. I guess I better get on with it! Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Cache rewrite backport
Brian Harring wrote: Curious about feedback from general usage, emerge -s, emerge -Dup world, etc. timing runs would be appreciated On my P4 I get these times: portage 2.0.53_rc5 emerge -s portage: real0m13.881s user0m2.716s sys 0m0.582s emerge -Dup world: real0m46.796s user0m17.264s sys 0m2.523s emerge metadata: 1:st run real16m59.430s user9m9.071s sys 1m2.749s 2:nd run real5m2.350s user0m33.074s sys 0m10.584s portage 2.0.53_rc5 - 3.0-cache-backport-experimental-7 emerge metadata: 1:st run real11m16.058s user0m54.954s sys 0m29.180s 2:nd run real2m50.096s user0m21.912s sys 0m9.377s emerge -s portage: real0m10.855s user0m2.610s sys 0m0.537s emerge -Dup: real0m40.443s user0m18.300s sys 0m3.465s -- Naga -- gentoo-portage-dev@gentoo.org mailing list
[gentoo-portage-dev] exclude cache from sync, was:Cache rewrite backport
Elaborating on the previous subject an idea come in mind, avoid the $PORTDIR/metadata/cache sync, It's 80 MB, 2 files So I've tryed the first python patch of my life, obviously it's also the first portage one (subliminal message, take the result with care and check it yourself) how? the patch add the option --withregen, the to exclude /metadata/cache from the sync and to issue a regen of the cache before to update the metadata. calling emerge --withregen --sync do the work. The following test has run with a dual opteron as rsync server and a Athlon XP 2500+ with an old and slow disk, cabled with gigabit ethernet. The rsync is forced removing the timestamp. The portage tree has been synced _before_ starting the bench, so the overhead of rsync is really reduced at the bare minimum, check the differences between the files on server and client. The surprising result is that recreating the cache is faster than rsync it. (real time) ===|=== ===|=== 1st try, portage [2.0.53_rc5] + cac|1st try, portage [2.0.53_rc5] + cac ===|=== sync with cache and _no_ regen |sync without cache and regen after |Regenerating cache entries... |done regen! | real6m23.727s |real4m14.837s user0m12.373s |user0m18.681s sys 0m13.849s |sys 0m7.744s ===|=== ===|=== 2nd try, portage [2.0.53_rc5] + cac|2nd try, portage [2.0.53_rc5] + cac ===|=== sync with cache and _no_ regen |sync without cache and regen after |Regenerating cache entries... |done regen! | real6m53.649s |real2m40.794s user0m12.361s |user0m18.361s sys 0m14.117s |sys 0m6.800s ===|=== ===|=== 3rd try, portage [2.0.53_rc5] + cac|3rd try, portage [2.0.53_rc5] + cac ===|=== sync with cache and _no_ regen |sync without cache and regen after |Regenerating cache entries... |done regen! | real6m46.973s |real4m19.261s user0m12.605s |user0m18.593s sys 0m13.733s |sys 0m7.648s | To run the test yourself (please with a local rsync mirror) mkdir tmptest ; cdtmptest # download the patch here bunzip2 emerge.patch.bz2 cp /usr/bin/emerge . patch -i emerge.patch emerge grep -B1000 ###end test with emerge.patch test_emerge # modify test_emerge for your needs . test_emerge == (/please with a local rsync mirror) Please check the correctness of what the patch do before test it. Cheers emerge.patch.bz2 Description: BZip2 compressed data
Re: [gentoo-portage-dev] Cache rewrite backport
On Thu, Oct 13, 2005 at 01:05:40PM +0200, Nagatoro wrote: Brian Harring wrote: Hmm, when trying to update the cache (emerge --metadata) I get this: --- Updating Portage cache: Traceback (most recent call last): File /usr/bin/emerge, line 2734, in ? cache.util.mirror_cache(source, cm, pdb.auxdb[porttree_root], eclass_cache=ec, verbose_instance=noise_maker) File /usr/lib/portage/pym/cache/util.py, line 22, in mirror_cache if not trg_cache.autocommits: AttributeError: CachingDict instance has no attribute 'autocommits' --- but if I remove the lastX patch it workes. *cough*, that's cause lastX is a dirty hack externally, rather then implemented w/in the cache backend for testing. That and I forgot to define that method. :) Basically it wraps the cache repo obj- if it proved to make a decent difference, would go through and integrate it better. portage 2.0.53_rc5 - 3.0-cache-backport-experimental-7 + lastx emerge -s portage: real0m12.891s user0m3.030s sys 0m0.576s After running this with and without the lastx patch I seem to get slighly longer times (real and user) with it (~0.5s real and user) and slightly shorter sys times (~0.2s). emerge -Dup world: real0m38.113s user0m18.186s sys 0m2.916s And here I seem to get slightly shorter real and sys times but slightly longer user times (~0.5s real and user, ~0.2s sys). But the times varies way to much to prove this. Pretty much is exactly what I've seen Haven't gotten any conclussive stats out of it. fex, testing via- cd /usr/portage ; for x in 1 2; do time repoman scan /dev/null ; done ; cd /usr/lib/portage/pym/; patch -p2 -i ~/lastx.patch ; cd /usr/portage ; for x in 1 2; do time repoman scan /dev/null ; done ; cd /usr/lib/portage/pym/; patch -p2 -i ~/lastx.patch -R real53m30.754s user34m25.549s sys 6m11.663s real49m16.141s user32m48.835s sys 5m52.882s patching file cache/mappings.py patching file portage.py real51m4.228s user34m24.005s sys 6m4.447s real51m16.202s user34m21.253s sys 6m1.315s patching file cache/mappings.py patching file portage.py About the only thing I've seen with the patch is less variation in the results, although never hitting the best runs unpatched does. Either way, thanks for testing it :) ~harring pgp4vHN8GQe9n.pgp Description: PGP signature
Re: [gentoo-portage-dev] exclude cache from sync, was:Cache rewrite backport
On Thu, Oct 13, 2005 at 07:12:42PM +0200, Francesco R. wrote: Elaborating on the previous subject an idea come in mind, avoid the $PORTDIR/metadata/cache sync, It's 80 MB, 2 files So I've tryed the first python patch of my life, obviously it's also the first portage one (subliminal message, take the result with care and check it yourself) how? the patch add the option --withregen, the to exclude /metadata/cache from the sync and to issue a regen of the cache before to update the metadata. calling emerge --withregen --sync do the work. The following test has run with a dual opteron as rsync server and a Athlon XP 2500+ with an old and slow disk, cabled with gigabit ethernet. The rsync is forced removing the timestamp. The portage tree has been synced _before_ starting the bench, so the overhead of rsync is really reduced at the bare minimum, check the differences between the files on server and client. The surprising result is that recreating the cache is faster than rsync it. (real time) Nuke the cache and try it ;) Being slightly sarcastic there, fastest I've managed to get a full regen down to was around 22 minutes for ebd, with stable being around 34m http://dev.gentoo.org/~ferringb/ebuild-daemon/stats/paired-stats I'd expect the gap has narrowed a bit since those timing runs, although it should still be sizable. Either way, the longer timing run (stable ebuild.sh) is the one to note :) So... that --metadata run has an extra stat call per check best case, but the cost of getting a cache entry is pretty heavily different. For metadata, just is a file read/write, for regen, exec(bash -c ebuild.sh) which, via quicky commandline test (that sets a floor for it), time bash /usr/lib/portage/bin/ebuild.sh , you're looking at around .1s per call. Pretty heavy difference on updates, eg, worst case- something a user hits on first sync, or nuking of the tree :) ===|=== ===|=== 1st try, portage [2.0.53_rc5] + cac|1st try, portage [2.0.53_rc5] + cac ===|=== sync with cache and _no_ regen |sync without cache and regen after |Regenerating cache entries... |done regen! | real6m23.727s |real4m14.837s user0m12.373s |user0m18.681s sys 0m13.849s |sys 0m7.744s ===|=== ===|=== 2nd try, portage [2.0.53_rc5] + cac|2nd try, portage [2.0.53_rc5] + cac ===|=== sync with cache and _no_ regen |sync without cache and regen after |Regenerating cache entries... |done regen! | real6m53.649s |real2m40.794s user0m12.361s |user0m18.361s sys 0m14.117s |sys 0m6.800s ===|=== ===|=== 3rd try, portage [2.0.53_rc5] + cac|3rd try, portage [2.0.53_rc5] + cac ===|=== sync with cache and _no_ regen |sync without cache and regen after |Regenerating cache entries... |done regen! | real6m46.973s |real4m19.261s user0m12.605s |user0m18.593s sys 0m13.733s |sys 0m7.648s | That said, I'm curious wth is triggering the 2x sys activity, which probably is to blame for the ~90s difference Anyone game for profiling a --metadata run, vs --regen run via profile.run? ~harring pgpEITgRx5D51.pgp Description: PGP signature
