[gentoo-dev] Agenda for Council meeting, Tuesday, November 15th, 20:00 UTC
The November Gentoo Council meeting will be held on #gentoo-council Tuesday, November 15th, 20:00 UTC, presided by Seemant Kulleen. The following items have been put on the agenda : Voting - GLEP 41 (requested by Homer Parker) Discussion - Portage Tree signing status (requested by Marius Mauch) - QA session I hope I didn't miss anything... See you there. -- Thierry Carrez Gentoo Council Member -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] aging ebuilds with unstable keywords
On Mon, 14 Nov 2005 08:12:25 +0100 (CET) Daniel Ahlberg [EMAIL PROTECTED] wrote: This is an automatically created email message. http://gentoo.tamperd.net/stable has just been updated with 14406 ebuilds. Just FYI, it doesn't display correctly in Opera - I can provide screenshots if you want. -- Andrej Ticho Kacian ticho at gentoo dot org Gentoo Linux Developer - net-mail, antivirus, sound, x86 signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 42 Critical News Reporting Round Two
On Sun, 2005-11-13 at 22:34 +, Stuart Herbert wrote: On Sat, 2005-11-12 at 10:26 -0500, Chris Gianelloni wrote: If users are interested in non-critical information, there's already a mechanism in place for them to get such things. They can join the mailing lists. Do we not already have a gentoo-events list? We also have a gentoo-releng list, or gentoo-announce. At this point, I think you're suggesting that we different news carried by different mediums. If so, I think that's very different from the proposal I'm putting forward. I thought your proposal was to get critical information to our users, not force every user to read that $dev is going to be in $country from $date1 to $date2. As I understood it, the portage-delivered news would be 100% tree-related and not filled with nonsense. If I am mistaken in this, then I change my opinion on supporting this proposal, as I surely don't give a damn about some dev meet in the UK that I would never be able to attend and *definitely* don't want that *shoved* down my throat by the tree. I also noticed how you lost context in my quote by the way you quoted it. Thanks. I'm not hoping for a 100% perfect technical solution straight away. I am. Anything less at this point is a half-assed design. The *design* should be 100% from the start. While implementation can occur in stages, you should not design as you go. I think that's a worthy goal, but looking around, it looks to me that software design just doesn't work like that in real life. Designs have to adapt and change as time passes, not just implementations. Really? I work with quite a few developers where I work. We have meetings. During these meetings, requirements are hashed out to cover the scope of the project. The code is then written to the specifications. If a later change is made into the requirements, then another meeting takes place, and a change request is agreed upon and scheduled. They sure as hell don't let the requirements slip otherwise, or they would end up in the ever-developing and never-completing world. We're talking about a *very* simple set of things that need to be developed here. Why *would* we even consider not laying out the requirements up front? -- 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] GLEP 42 Critical News Reporting Round Two
On Mon, 14 Nov 2005 10:25:33 +0100 Thierry Carrez [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Fri, 11 Nov 2005 22:37:15 + Stuart Herbert [EMAIL PROTECTED] wrote: | For example, there's no real reason why GLSA's couldn't been delivered | via this at some point (although I'd prefer a You have X amount of | security fixes to apply type message adding to emerge, and treating | GLSAs as a special case). hh! We're not supposed to be mentioning that until the thing's up and running. Why not, if it can speed up portage/GLSA emerge --security integration... It can't. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Agenda for Council meeting, Tuesday, November 15th, 20:00 UTC
On Mon, 14 Nov 2005 10:09:24 +0100 Thierry Carrez [EMAIL PROTECTED] wrote: The November Gentoo Council meeting will be held on #gentoo-council Tuesday, November 15th, 20:00 UTC, presided by Seemant Kulleen. The following items have been put on the agenda : Voting - GLEP 41 (requested by Homer Parker) Discussion - Portage Tree signing status (requested by Marius Mauch) - QA session Ehm, I didn't request anything. Grant did ;) Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Agenda for Council meeting, Tuesday, November 15th, 20:00 UTC
Thierry Carrez wrote: [Mon Nov 14 2005, 03:09:24AM CST] Voting - GLEP 41 (requested by Homer Parker) My recollection was that GLEP 41 was rejected at the last meeting, although a revised GLEP could be resubmitted for approval. As far as I know, however, the GLEP has not yet been revised. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpoataSnjjIE.pgp Description: PGP signature
Re: [gentoo-dev] Agenda for Council meeting, Tuesday, November 15th, 20:00 UTC
Marius Mauch wrote: [Mon Nov 14 2005, 08:05:44AM CST] Discussion - Portage Tree signing status (requested by Marius Mauch) Ehm, I didn't request anything. Grant did ;) Yep, I did make the request, but it is genone who did all of the hard work. I'm just pushy. *Grin* -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgprkGPbJisnj.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council meeting Tuesday, November 15th, 20:00 UTC
On Sun, 2005-11-13 at 14:29 -0600, Grant Goodyear wrote: Homer Parker wrote: [Fri Nov 11 2005, 08:09:11PM CST] Just want to be sure that GLEP41 is on the list. GLEP 41 was rejected by the council at the last meeting, pending a rewrite that addressed the issues brought up at that meeting: http://www.gentoo.org/proj/en/council/meeting-logs/20051013.txt According to CVS, the GLEP hasn't been updated since the last meeting, so I'm assuming that the GLEP's authors aren't ready yet. -g2boojum- I uploaded it the end of last week. Looks to be updated on the web site. -- Homer Parker Gentoo/AMD64 Team Gentoo/AMD64 Arch Tester Strategic Lead Gentoo Developer Relations [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo Council meeting Tuesday, November 15th, 20:00 UTC
On Mon, 2005-11-14 at 18:11 +, Ciaran McCreesh wrote: On Mon, 14 Nov 2005 12:02:43 -0600 Homer Parker [EMAIL PROTECTED] wrote: | I uploaded it the end of last week. Looks to be updated on | the web site. Hrm, but you didn't post it to -dev for discussion? If you wish, here it is. Made the changes the council asked for is all. -- Homer Parker Gentoo/AMD64 Team Gentoo/AMD64 Arch Tester Strategic Lead Gentoo Developer Relations [EMAIL PROTECTED] GLEP: 41 Title: Making Arch Testers official Gentoo Staff Version: $Revision: 1.3 $ Last-Modified: $Date: 2005/11/11 18:42:27 $ Author: Simon Stelling [EMAIL PROTECTED], Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 7-Sep-2005 Post-History: 15-Sep-2005 Abstract Arch Testers should be treated as official Gentoo staff. Motivation == Since Mike Doty (kingtaco) created an Arch Tester (AT) project in January 2005 to reduce the developer's load and the amount of open keywording bugs for the amd64 porting team, many users have volunteered to become ATs. They are doing a fair share of everyday's work to keep the amd64 and ppc trees up to date. While they spent many hours and even had to pass the staff quiz, they are currently not recognized as official members of Gentoo. Specification = ATs should basically be treated as staff. This includes the following changes to the current situation: - Get a @(subdomain_to_be_determined).gentoo.org email address. The email address will just be an alias, and will be forwarded to their @gentoo.org address if they go on to become a Gentoo developer. - Get read-only access to the gentoo-x86 repository. This doesn't have to be individual accounts, a single account, without a shell, with all of their keys will be sufficiant. There will be a 30 day probationary/mentoring period for new ATs.The lead AT/HT for arch/herd will be responsible for the mentoring period. If arch/herd doesn't have a Lead AT/HT, then either the arch/herd lead or the Strategic AT Lead will be responsible. The Lead AT is a seasoned developer that watches for talent, recruits and mentors ATs. Additionally, the mentoring period should be shortened to a minimum of two weeks if an AT wants to take the end quiz to become a developer, assuming he has been AT for at least two weeks. The amd64 porting team has handled situations like this for a while and only made positive experiences. Also, the idea of an arch tester as a trustworthy user who is able to test critical changes (such as hard masked software branches), could be expanded to other herds. These 'ATs' wouldn't be called arch testers as the 'arch' is irritating, instead, herd tester (HT) could be used. As arch testers (and herd testers) become official staff, they should be handled by DevRel. Since ATs don't want to have to handle the big 'communication overhead' normally, they won't be subscribed to the gentoo-core mailing list and won't be able to vote. Backwards Compatibility === All current active arch testers should be migrated. Copyright = This document has been placed in the public domain.
Re: [gentoo-dev] Agenda for Council meeting, Tuesday, November 15th, 20:00 UTC
Grant Goodyear [EMAIL PROTECTED] wrote: Thierry Carrez wrote: [Mon Nov 14 2005, 03:09:24AM CST] Voting - GLEP 41 (requested by Homer Parker) My recollection was that GLEP 41 was rejected at the last meeting, although a revised GLEP could be resubmitted for approval. As far as I know, however, the GLEP has not yet been revised. According to the changelog you stuck the status update saying it got rejected and should be changed into the glep *after* hparker updated it. (And included council recommendations) Got me pretty confused ;-) Greetings, Matti -- All your files have been destroyed (sorry). Paul. pgpZCa5yb4mAa.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council meeting Tuesday, November 15th, 20:00 UTC
Homer Parker wrote: On Mon, 2005-11-14 at 18:11 +, Ciaran McCreesh wrote: On Mon, 14 Nov 2005 12:02:43 -0600 Homer Parker [EMAIL PROTECTED] wrote: | I uploaded it the end of last week. Looks to be updated on | the web site. Hrm, but you didn't post it to -dev for discussion? If you wish, here it is. Made the changes the council asked for is all. Sending it out a day before the meeting isn't exactly a good thing. I'd rather wait to look through those details instead of getting them a day before they vote on them. -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key: http://www.ramereth.net/lance.asc Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Agenda for Council meeting, Tuesday, November 15th, 20:00 UTC
Thierry Carrez wrote: [Mon Nov 14 2005, 10:28:23AM CST] v 1.3 looks like a revised version to me (on Nov 11) : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0041.txt?r2=1.3root=gentoor1=1.2diff_format=u Hmmm, I'm not sure how I missed that one, but clearly I did. Did it get sent out to -dev for comments? -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp0Yd5GWcsZg.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council meeting Tuesday, November 15th, 20:00 UTC
On Mon, 2005-11-14 at 13:06 -0600, Lance Albertson wrote: Sending it out a day before the meeting isn't exactly a good thing. I'd rather wait to look through those details instead of getting them a day before they vote on them. I got busy and forgot to post it to the list. If it needs to wait till next month, so be it. -- Homer Parker Gentoo/AMD64 Team Gentoo/AMD64 Arch Tester Strategic Lead Gentoo Developer Relations [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Science herd testers
Hi, I wanted to announce that the science herd took on its first herd tester (Lucas Chiesa (tulku)) nearly a month ago. We also have a few others in the pipeline. Due to the technical nature of some of the scientific packages we felt that herd testers would be especially appropriate for the scientific herd. I am working with hparker to get the herd tester project moving. If anyone would like any more information then please contact myself or hparker about it. Thanks, Marcus pgpyyfJdmRqWZ.pgp Description: PGP signature
Re: [gentoo-portage-dev] Plugin framework
On Monday 14 November 2005 23:17, Marius Mauch wrote: On Mon, 14 Nov 2005 22:38:28 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: The cache and elog plugin selection(s) come from user settings but emaint (and repoman whenever that happens (and possibly even emerge itself one day?)) needs to automatically detect what's available and use it. The last part I consider questionable, while they shouldn't come from the user config directly I'd be very careful with a use everything possible policy. Not saying that it's flat wrong or that I have a better plan right now, but having this as a primary design goal seems wrong. That's why there's the issubclass() check. That guarantees that modules found in a certain path (of a certain plugin type) provide a prespecified API. Utilizing that API, it's then possible to inspect the plugin in any way necessary. My goal at this level is just to provide an easy way to enumerate what plugins are available and have some assurance that a certain API is available. If you're talking with regard to emaint specifically. The goal is to have plugins detected at runtime and available as extra targets beyond the current world. That would allow things such as revdep-rebuild to be integrated without the need for special handling on the emaint side. -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] going to need a 2.0.53-rc8
On Monday 14 November 2005 00:46, Jason Stubbs wrote: On Sunday 13 November 2005 11:52, Brian Harring wrote: On Sun, Nov 13, 2005 at 09:19:55AM +0900, Jason Stubbs wrote: On Sunday 13 November 2005 04:00, Brian Harring wrote: *cough* that's that funky _p1 you're using there? :) patchlevel... I think it gives a stronger impression that 2.0.53 is distinct from 2.0.54. Is distinct the right word? I mean that it kind of shows that 2.0.53 is done but there was something that needed to be fixed quickly. 2.0.53.1 vs 2.0.53_p1 vs 2.0.53.p1 ... either of the three indicates 2.0.53 had minor fix tagged onto the base 2.0.53 release... Given portage's history of using lots of dots, 2.0.53.1 doesn't have as much impact. Is the *cough* a complaint of sorts? Well, knowing what you mean by pN, I'm just going to gesture wildly at my earlier email of lets fix the whacked out versioning now. ;) So then my suggested 2.0.53_p1 should be 2.0.54 and what is currently referred to as 2.0.54 should be 2.1.0? Any thoughts on this? If we use 2.0.54 for the fix for this, that can go into ~arch before 2.0.53_pre7 goes to .53 and arch without versioning getting screwed up. I'm still pretty sure 2.0.53 will be stable (at least on some arch) in under 48 hours and the fix for this should really go out at the same time or before... -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] going to need a 2.0.53-rc8
On Tue, 15 Nov 2005 00:24:02 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: On Monday 14 November 2005 00:46, Jason Stubbs wrote: On Sunday 13 November 2005 11:52, Brian Harring wrote: On Sun, Nov 13, 2005 at 09:19:55AM +0900, Jason Stubbs wrote: On Sunday 13 November 2005 04:00, Brian Harring wrote: *cough* that's that funky _p1 you're using there? :) patchlevel... I think it gives a stronger impression that 2.0.53 is distinct from 2.0.54. Is distinct the right word? I mean that it kind of shows that 2.0.53 is done but there was something that needed to be fixed quickly. 2.0.53.1 vs 2.0.53_p1 vs 2.0.53.p1 ... either of the three indicates 2.0.53 had minor fix tagged onto the base 2.0.53 release... Given portage's history of using lots of dots, 2.0.53.1 doesn't have as much impact. Is the *cough* a complaint of sorts? Well, knowing what you mean by pN, I'm just going to gesture wildly at my earlier email of lets fix the whacked out versioning now. ;) So then my suggested 2.0.53_p1 should be 2.0.54 and what is currently referred to as 2.0.54 should be 2.1.0? Any thoughts on this? If we use 2.0.54 for the fix for this, that can go into ~arch before 2.0.53_pre7 goes to .53 and arch without versioning getting screwed up. I'm still pretty sure 2.0.53 will be stable (at least on some arch) in under 48 hours and the fix for this should really go out at the same time or before... Replace 2.1.0 with 2.2.0 and I'll agree. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-portage-dev] going to need a 2.0.53-rc8
On Tuesday 15 November 2005 00:32, Marius Mauch wrote: On Tue, 15 Nov 2005 00:24:02 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: On Monday 14 November 2005 00:46, Jason Stubbs wrote: On Sunday 13 November 2005 11:52, Brian Harring wrote: On Sun, Nov 13, 2005 at 09:19:55AM +0900, Jason Stubbs wrote: On Sunday 13 November 2005 04:00, Brian Harring wrote: *cough* that's that funky _p1 you're using there? :) patchlevel... I think it gives a stronger impression that 2.0.53 is distinct from 2.0.54. Is distinct the right word? I mean that it kind of shows that 2.0.53 is done but there was something that needed to be fixed quickly. 2.0.53.1 vs 2.0.53_p1 vs 2.0.53.p1 ... either of the three indicates 2.0.53 had minor fix tagged onto the base 2.0.53 release... Given portage's history of using lots of dots, 2.0.53.1 doesn't have as much impact. Is the *cough* a complaint of sorts? Well, knowing what you mean by pN, I'm just going to gesture wildly at my earlier email of lets fix the whacked out versioning now. ;) So then my suggested 2.0.53_p1 should be 2.0.54 and what is currently referred to as 2.0.54 should be 2.1.0? Any thoughts on this? If we use 2.0.54 for the fix for this, that can go into ~arch before 2.0.53_pre7 goes to .53 and arch without versioning getting screwed up. I'm still pretty sure 2.0.53 will be stable (at least on some arch) in under 48 hours and the fix for this should really go out at the same time or before... Replace 2.1.0 with 2.2.0 and I'll agree. Brian? Others? -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] going to need a 2.0.53-rc8
On Mon, Nov 14, 2005 at 04:32:35PM +0100, Marius Mauch wrote: On Monday 14 November 2005 00:46, Jason Stubbs wrote: Replace 2.1.0 with 2.2.0 and I'll agree. Skipping 2.1 accomplishes what? People asking, whoah there, it's a later version then 2.1, where's the 2.1 functionality? will still occur. *cough* this is why alpha/feature releases should be date tagged against the branch point instead of the potential version. :) ~harring pgp8qcBikWX6V.pgp Description: PGP signature
Re: [gentoo-portage-dev] Plugin framework
On Mon, Nov 14, 2005 at 10:38:28PM +0900, Jason Stubbs wrote:
On Sunday 13 November 2005 11:57, Brian Harring wrote:
?? filenames.
OT, but return of the funky 'A's...
Curious if others are seeing it, or if my nano/mutt setup just plain
sucks.
* portage.py edits to the config class to make use of the framework.
Essentially, plugins.registry gives dict access to modules under
plugins/. To give an example, the plugins.cache.anydbm.anydbm class can
be accessed via plugins.repository[cache][anydbm].
Offhand... you're duplicating pythons first found for module
namespace, which I'm not particularly much for, at least for a
registry framework.
If you're going to introduce a plugin registry, allow the plugins to
exist wherever they want in python namespace, and have the registry
entry point to it (preferably lifting code from 3.0 where possible
also).
I'm not familiar with this. If it works better than what I've got now without
having to hardcode what plugins are available, I'm all for it. Perhaps
registry is the wrong word for what I was trying to do...
No... registry's probably apt. :)
If this were mainlined, I'd prefer a tool that registers the plugin
portage uses- do this, and /etc/portage/modules can go away, using a
generic framework instead.
I'm not much for on the fly determination via inspecting namespace-
too easy for it to bite users in the ass, imo.
Meanwhile, couple of code comments, then final comments...
diff -uNr portage-orig/pym/plugins/__init__.py
portage-plugin-framework/pym/plugins/__init__.py ---
portage-orig/pym/plugins/__init__.py 1970-01-01 09:00:00.0
+0900
+++ portage-plugin-framework/pym/plugins/__init__.py 2005-11-12
21:52:15.0 +0900 @@ -0,0 +1,80 @@
+class registry:
+
+ class _plugin_loader:
Shoving the _pluging_loader class into the registry class namespace
Strange obsession with keeping the namespace empty.
__all__ is a useful module attribute if you're concerned about
from somemodule import *
makes it a bit hard for derivatives of registry to be implemented.
I can't see any possible reason to want to derive from it. The point of it is
that pulling external code in should be seamless. If it doesn't serve as is,
I'd prefer that it be fixed rather than putting the functionality somewhere
else.
Nothing real is lost by not hiding it. It probably will never be
derived from, but that doesn't mean we hide it blocking the possibility
from ever occuring either. :)
+ self._path = path
+ self._loaded = {}
+
+ def __getitem__(self, name):
This is not thread safe (addressed in 3.0)
This is an interesting point. I wasn't thinking about thread-safety at all,
but when should I be? Should everything be implemented with thread safety in
mind? If not, at what point should the line be drawn?
My view on it is if you're implementing global objs, new stuff should
be thread safe if it's sane.
Plugin registry is something I'd define, at least for the imports, as
code that should be as defensive as possible (eg, atomic).
$ python -c 'import plugins; print dir(plugins)'
['__builtins__', '__doc__', '__file__', '__name__', '__path__', 'registry']
There's something attractive about the above, but I'm not married to it.
dir() isn't real useful aside from introspection/development imo;
Imo, appropriate pydoc strings tacked in ought to mitigate any issues
in terms of pollution/uglyness.
config.module_priority is _evil_ (yep, first I've noticed that gem).
If a user specified cache backend can't be loaded, falling to a
default is a great way to piss users off (that's a bad 'helpful'
feature). Meanwhile, back to your patch...
Actually, that was also my mistaken addition. The original code uses
module_priority but only tries loading the first found. More
misguidedness. :(
Eh... module_priority should die, regardless if you've expanded upon
it or not.
Ironic I'm stating portage should be made dumber then it is, but
'helpfullness' when an app reverts user choices is something that
always has bugged the hell out of me. :)
So, as I said before, the point is to unify plugin management. Instead of
having the imports done wherever something can be plugged in, unify that and
do it all in one place. The cache and elog plugin selection(s) come from user
settings but emaint (and repoman whenever that happens (and possibly even
emerge itself one day?)) needs to automatically detect what's available and
use it.
User settings is system specific settings really; this is getting back
to why I think this should be an actual registry (as in on disk).
I'll take a look at ripping portage.plugins out of 3.0, and integrate
it into 2.0. The api differs, but wrapping it's base api with a dict
style class isn't too hard to do.
~harring
pgpdQlmVfTpMW.pgp
Description: PGP signature
Re: [gentoo-portage-dev] cache subsystem replacement
On Tue, Nov 15, 2005 at 01:13:58AM +0900, Jason Stubbs wrote: Was talking with a guy yesterday who mentioned he had 10 line patch that sped up current portage a lot with regard to updating metadata. I asked him to send it to me and here it is: --- -??2005-10-29 18:49:15.156173000 +0900 +++ /usr/lib/portage/pym/portage_db_cpickle.py2005-10-08 11:13:37.0 +0900 @@ -61,6 +61,9 @@ return False def sync(self): +??return + +??def realsync(self): if self.modified: try: if os.path.exists(self.filename): @@ -74,6 +77,6 @@ pass def close(self): -??self.sync() +??self.realsync() self.db = None; Ok, your mail client is screwing stuff up here ;) The problem with the trick above is that, yeah, it delays syncs, but it also means if portage shuts down uncleanly _ever_, the entire eclass db of the old cache format is invalidated. All of it. Back to square one. Massively bad thing, obviously. This is why the default sync rate of cache classes in the rewrite is 1 also, it updates every time a change is pushed to it. I remembered seeing sync_rate when glancing through the new cache stuff and then had a look into mirror_cache(). Playing with trg_cache.sync(x), I got the following numbers. xtotal #1 total #2 total #3 median sys 1 13.65113.45113.727 2.712 10 13.41313.41213.645 2.538 10013.60513.49813.405 2.700 1000 13.67313.72613.748 2.839 1 14.54114.05413.447 2.743 10 13.97313.95114.512 2.881 10013.58313.62213.935 2.669 Command run was: rm -rf /var/cache/edb/dep/*; time emerge -q metadata So what does changing the sync_rate actually do? Ease seeks? Should I re-run these tests with a reboot in between? (And what happened to the 4 seconds I was getting with earlier patches? Bug fixes turn quantity into quality? :) Umm... 4 seconds? Eh? Regarding what the sync_rate does, if the target cache supports batched updates (think rdbms), it is capable of delaying upto N modifications prior to pushing the change out. a cdb/cpickle cache backend would want to use this fex. Meanwhile, why you're not seeing any variation- I'm pretty much positive you're using a cache that autocommits, meaning delayed sync'ing isn't possible. Autocommit == can't batch, so sync rate isn't used/valid. The only cache in the rewrite that doesn't autocommit is the sqlite implementation (which coincidentally is why sync rate exists; inserts into sqlite are [EMAIL PROTECTED]@#*ing slow). ~harring pgpfEyeYnJQqs.pgp Description: PGP signature
Re: [gentoo-portage-dev] Plugin framework
On 05/11/14 09:53, Brian Harring wrote: On Mon, Nov 14, 2005 at 10:38:28PM +0900, Jason Stubbs wrote: On Sunday 13 November 2005 11:57, Brian Harring wrote: Â filenames. OT, but return of the funky 'A's... Curious if others are seeing it, or if my nano/mutt setup just plain sucks. I don't see them in Jason's emails, but in your replies they're there... Don't know why, but maybe some sort of locale- or encoding-setting somewhere in your mutt config? -- Regards, Patrick Börjesson PGP signature: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x21792A5D PGP fingerprint: 74AF D4EF 6BDE CF77 16BE 6A29 CDB8 7607 2179 2A5D () The ASCII Ribbon Campaign - against HTML Email /\ and proprietary formats. pgpC5PDTTn8oK.pgp Description: PGP signature
[gentoo-portage-dev] confcache
Hola all. Wrote another confcache implementation (this time not bound to ebd thank god), and stuck an ebuild and portage patch for it in http://dev.gentoo.org/~ferringb/confcache/ . Should be a bit stricter then the 2.1 implementation; for those not aware of what it is, it's a global autoconf cache + staleness detection. End result is a 2-4x faster configure run when the cache is fully primed, decreasing levels of gain if the cache isn't full. Worst case, cache is invalidated/missing, which is normal configure runtifme + minor overhead. Portage integration is pretty minor; just an econf modification. Feedback/testing desired, so have fun with it. ~harring pgpw02nwNXFmm.pgp Description: PGP signature
