Re: Fwd: [gentoo-portage-dev] search functionality in emerge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Emma Strubell wrote: There must be a faster python pickler out there, though, any recommendations? Right off the bat, you might try cPickle. It should work identically, just faster. Also you can try importing psyco, if it's present it will try semi-compiling some bits and pieces and *might* offer some speed-ups (as in, it won't always, for small projects it might actually slow it down). Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmUjy8ACgkQu7rWomwgFXrW6wCfS9zTTgqbhiDyaU1opDJO3BM2 VO4AoIaPQ+t27OnTGh7tBEH/mqYntO/v =NzDj -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [2/4] proto-GLEPS for Tree-signing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry, I lost my notes from when I last looked these over several months ago, and only just found them again. I haven't copied this to [EMAIL PROTECTED], so let me know if I should do that. I just had a quick couple of things I was thinking about, and one of them I figured out during my re-read, so it's only really the following... In this Glep (xx+1), in the section discussing the procedure for creating a MetaManifest file, in step 3.3, does that include verification of the manifest's signature if it has one? It would seem odd to ignore the signature if it's wrong (I'm not sure about the case if a signature isn't present). I also don't know how this would then be handled (a complete abort, or ignoring the latest changeset to that ebuild?). If the signature check happened here, it could also allow for enforcable revocation of developer certificates (once they're revoked, any signed manifests will have the ebuild changes ignored). That may be a lot of work and may take too long, but if not (and depending on our users' trust needs), it might allow them just to check the MetaManifest's signature, and not that of the individual packages. Does that seems sensible? I've probably missed a key issue somewhere along the way, in which case, sorry, and do feel free to chide me liberally... 5:) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiPdNAACgkQu7rWomwgFXoJ9gCeLZOvpGAyr+EzI/d8EKWrnqnf CVoAoI63EiYvB4+1cBSURIlRxaH0xy4o =yZH7 -END PGP SIGNATURE-
Re: [gentoo-portage-dev] Masked by corruption
Jim, I opened bug 158632, so that's worth looking at. It also points to a post on the forums about the problem. I can't add much to the discussion myself, just that it affected two of my machines differently which I found rather odd (one has difficulty with all versions of mpc, the other with only one version). I hope that helps... Mike 5:) -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Package moves in overlays
Ok, Well, what if instead we were to try and treat the overlay trees as exactly that, overlays. So the moves were used from the lowest layer (ie the main tree) unless a higher up layer overrode them, could that work? It would mean effectively that the overlay moves were global, but I guess you'd then end up losing updates to the main tree if a file like 4Q-2005 was overridden... Can anyone think of a pratical solution to this problem other than either a major rework of portage's tree handling system, or by having the two packages block each other and relying on the user to fix the tree up manually whenever this happens? Any ideas would be welcome, it's a problem I'd really like to fix. Thanks very much, Mike 5:) -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Package moves in overlays
Yeah, Sorry about the double posting, patrick told me about a gmail feature that means you never see your own posts... I agree that the updates should only affect that individual tree. Whilst I can imagine cases where a move in the main tree should affect overlay trees (such as recategorizing some net-misc ebuilds into a net-proxy category), that could at least be emulated with a per-tree move directive fairly easily. It sounds as though the answer is that there currently no way to do these kinds of moves, so what's the next step? Should I try and hack up a version to deal with updates on a per tree basis? Is it actively being developed and I'm just unaware of it? What can I do to help get this feature into a future version of portage? It would be very useful to have, because at the moment network administrator's can't quite use overlays as a software management mechanism... Thanks for you time, Mike 5:) -- gentoo-portage-dev@gentoo.org mailing list
