Re: [gentoo-portage-dev] making aux_get more usable for vardbapi
On Wed, 11 Jan 2006 12:39:03 -0800 Brian Harring [EMAIL PROTECTED] wrote: Regex you've got there allows for pulling the wrong text- recall, ebd originally was doing grep based filtering (regex). Had to rewrite that in a major hurry since bash syntax (specifically here ops) forces you to track state/constructs rather then just a regex... Not really an issue in this case. First the code bails out if more than one match is found, so unless the metadata assignment is NOT found by it we don't get the wrong info. Also a mismatch in this special is so extremely unlikely that honestly I don't really care about it, especially as this is a one time conversion (might be different if I'd have added the on the fly extraction). All together makes this pretty much a hypothetical issue with no practical relevance. 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] Re: Plausible idea for GLEP 19?
On 06/01/22 17:47, Mikey wrote: On Sunday 22 January 2006 16:56, Marius Mauch wrote: That's not really what you want. -s updates might (will) be overlaid with version or revision bumps from time to time, for this to be of any use it has to happen at the resolver level (visiblity filter). Normal emerges would take -s2 over -r1 or -s1. The change is transparent when not in glsa-only mode. You didn't understand what I said. If you just play around with the output info you'll miss updates. How will I miss updates? Standard actions (system world) or myfiles would work the exact same as they do now, they just consider a new revbump specifier in the digraph calculation. The non-standard action that I am proposing, call it emerge glsa-only, would take the output from emerge -Du world and filter out anything from the resulting package list except for -s packages. I will only miss updates that are not strictly security related. If there is no security-only related update, i.e. I have to upgrade to the next version, glsa-check will report it and I will have to manually update. The problem with your reasoning is that portage only reports the highest upgrade (from it's point of view). So if you have package A-1.0 installed and two possible upgrades, say A-1.0-s1 and A-1.1, then portage will chose the highest of the two. So the output from that command would be: | These are the packages that I would merge, in reverse order: | | Calculating world dependencies ...done! | [ebuild U ] the-cat/A-1.1 [1.0] .. It will not output the following: | These are the packages that I would merge, in reverse order: | | Calculating world dependencies ...done! | [ebuild U ] the-cat/A-1.0-s1 [1.0] .. So you _will_ miss upgrades if you only filter the output of emerge in your solution and expect to get all security related upgrades relating to the package you're using. -- / Patrick Börjesson \ --- / () The ASCII Ribbon Campaign - against HTML Email \ /\ and proprietary formats. pgpMr3Pn7tZND.pgp Description: PGP signature
Re: [gentoo-portage-dev] emerge-webrsync patch
Brian, did you have a chance to look at this yet? - Johannes. Johannes Fahrenkrug wrote: Brian Harring wrote: On Wed, Jan 11, 2006 at 10:15:00AM +0100, Johannes Fahrenkrug wrote: if [[ -n $PORTAGE_NICENESS ]] ! [[ -z $WE_ARE_NICED ]]; then Haven't looked at the patch yet, but a bit of bash fu for ya- [[ -n $VAR ]] == ! [[ -z $VAR ]] -z is zero length or unset, -n is length = 1 (thus must be set). Exactly! This code ... If [[ -n $VAR ]] == ! [[ -z $VAR ]] (which it is) then export WE_ARE_NICED=1 exec nice -n $PORTAGE_NICENESS $0 $@ fi ...has the purpose to execute the current script again with nice if PORTAGE_NICENESS is set and WE_ARE_NICED is not set (to avoid an infinite loop). Right? If... if [[ -n $PORTAGE_NICENESS ]] ! [[ -z $WE_ARE_NICED ]]; then ...is the same as... if [[ -n $PORTAGE_NICENESS ]] [[ -n $WE_ARE_NICED ]]; then ...then that would mean that the condition is only met when both PORTAGE_NICENESS and WE_ARE_NICED are set. But WE_ARE_NICED is only set inside the if-body. So I think the condition should read if [[ -n $PORTAGE_NICENESS ]] [[ -z $WE_ARE_NICED ]]; then meaning the condition is only met when PORTAGE_NICENESS is set and WE_ARE_NICED is NOT set. Maybe I'm completely wrong here, but I think that's the only way the condition makes sense. Please enlighten me if I'm wrong :) - Johannes. -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] making aux_get more usable for vardbapi
On Mon, Jan 23, 2006 at 11:16:03AM +0100, Marius Mauch wrote: On Wed, 11 Jan 2006 12:39:03 -0800 Brian Harring [EMAIL PROTECTED] wrote: Regex you've got there allows for pulling the wrong text- recall, ebd originally was doing grep based filtering (regex). Had to rewrite that in a major hurry since bash syntax (specifically here ops) forces you to track state/constructs rather then just a regex... Not really an issue in this case. First the code bails out if more than one match is found, so unless the metadata assignment is NOT found by it we don't get the wrong info. Also a mismatch in this special is so extremely unlikely that honestly I don't really care about it, especially as this is a one time conversion (might be different if I'd have added the on the fly extraction). Re-read that statement. It's a one time conversion- meaning we better get it right the first time, else the user's data is effectively corrupted. Forcing a full regen from the saved environment is not a solution for fixing past corruptions either. If it were on the fly extraction, I wouldn't care quite as much- but the fact this is an untracked change to the users data means we *do* need to cover corner cases. I know you want this in, but it has to be done *right* covering all known corner cases for it- I already wrote the tool that handles the corner cases properly, use it, don't adhoc a solution that re-introduces the potential gaps. If we're not going to do it right, we really shouldn't do it when it comes to upgrades of the vdb. Aside from that, if the code is in debate (as this is), I really don't think it should get slid into svn 2 weeks later effectively unchanged- didn't write that original email just for the hell of it :) ~harring pgp8DlaOCY2aR.pgp Description: PGP signature
Re: [gentoo-portage-dev] emerge-webrsync patch
Great! Thank you :) I'll be watching the GWN closely :) - Johannes. Brian Harring wrote: On Mon, Jan 23, 2006 at 12:39:06PM +0100, Johannes Fahrenkrug wrote: Brian, did you have a chance to look at this yet? Will be integrating the changes sometime this week (spaced it tbh) :) ~harring -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Re: Plausible idea for GLEP 19?
On Monday 23 January 2006 04:56, Patrick Börjesson spammed: The problem with your reasoning is that portage only reports the highest upgrade (from it's point of view). So if you have package A-1.0 installed and two possible upgrades, say A-1.0-s1 and A-1.1, then portage will chose the highest of the two. So the output from that command would be: | These are the packages that I would merge, in reverse order: | | Calculating world dependencies ...done! | [ebuild U ] the-cat/A-1.1 [1.0] .. It will not output the following: | These are the packages that I would merge, in reverse order: | | Calculating world dependencies ...done! | [ebuild U ] the-cat/A-1.0-s1 [1.0] .. So you _will_ miss upgrades if you only filter the output of emerge in your solution and expect to get all security related upgrades relating to the package you're using. That is _exactly_ how it is intended to work. Normal users will get A-1.1 when they run emerge -u. Users with a need for stability will only see A-1.0-s1, and only if it is available for A-1.0. Perhaps I should have named it hotfix instead of glsa-only. This feature is targeted towards environments that prioritize stability slightly over security. Often it is not an option to upgrade to the next version of something until it has been regression tested, various apps have been migrated/ported, etc... My patches alone don't make this possible, but they at least provide a framework for it to happen in the future. Users who need backported security fixes could band together for the major apps and do the work, the -s packages could be distributed via overlays (so as not to interfere with old versions of portage). pgpnO2YBP4w6k.pgp Description: PGP signature
Re: [gentoo-portage-dev] Re: Plausible idea for GLEP 19?
On Monday 23 January 2006 12:46, Marius Mauch spammed: That is _exactly_ how it is intended to work. Normal users will get A-1.1 when they run emerge -u. Users with a need for stability will only see A-1.0-s1, and only if it is available for A-1.0. And for that you have to hack the resolver so it only sees your -sX updates. Um, nope. + if myaction==glsa-only: + pkglist = mydepgraph.altlistglsa() Leads to: + def altlistglsa(self): + retlist=[] + for y in self.altlist(): ^^^ + psplit=portage.pkgsplit(y[2]) + myrev=psplit[-1] + myrevtype=myrev[0] + if myrevtype==s: + retlist.append(y) + return retlist + No touching the resolver, only filter output. The filter code is not complete yet - I still need to compare current version -vs- new version. The only other place I am touching anything is pkgsplit in portage.py: - if len(myrev) and myrev[0]==r: + if len(myrev) and myrev[0] in [r,s]: pgp5tCd4M7LIo.pgp Description: PGP signature
[gentoo-portage-dev] Order of operations: buildpkg
Many ebuilds fail due to failed QA. How difficult would it be to have the package create the tarball before the QA tests. If this were possible, QA could be slightly quicker, as there would be no need to rebuild the entire package, with features disabled, upon failure. -- Lares Moreau [EMAIL PROTECTED] | LRU: 400755 http://counter.li.org lares/irc.freenode.net | Gentoo x86 Arch Tester | ::0 Alberta, Canada Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Preferred Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] Order of operations: buildpkg
On Monday 23 January 2006 15:55, Simon Stelling wrote: Lares Moreau wrote: Many ebuilds fail due to failed QA. How difficult would it be to have the package create the tarball before the QA tests. If this were possible, QA could be slightly quicker, as there would be no need to rebuild the entire package, with features disabled, upon failure. I think you rather want to use FEATURES=keepwork than doing such ugly stuff. keepwork wouldnt accomplish anything wrt to what he wants this would prob do it though: ebuild ebuild install package qmerge -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] first pass at --debug-build
On Thursday 19 January 2006 19:39, Mike Frysinger wrote: here's what i was talking about when i mentioned the mutate() idea tested and it works for me ... binary is built properly and environment.bz2 contains the correct values to speed this along ... how do people care about the FEATURES=debug-build idea in general ? i could commit the first part which implements FEATURES=debug-build in general and then we can fight over how to implement `emerge --debug-build` -mike -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] first pass at --debug-build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: On Thursday 19 January 2006 19:39, Mike Frysinger wrote: here's what i was talking about when i mentioned the mutate() idea tested and it works for me ... binary is built properly and environment.bz2 contains the correct values to speed this along ... how do people care about the FEATURES=debug-build idea in general ? i could commit the first part which implements FEATURES=debug-build in general and then we can fight over how to implement `emerge --debug-build` -mike I'm stuck on this. Part of me wants to see more new features in portage and part of me screams horrible hack :P -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ9V1cGzglR5RwbyYAQJKDQ/+O4nWZfn+SavwNEm7nxm0mAkRJbuz6Unl PFJfRgjN67p9IFUu5rcbCMxVFUX8TFbCc6skMNl9M1WXiIBYQai2TodHso3uGcfn CVLpl40tCorEvb54UtNN/J+m0QOpEbOgG2QnfAteWD+Di1jAVzEzNSIhbiiY56oH buTdG6YPlsJldKkzE7NAmcco1sjW2lY71DPIulChaENBR1N/WYLfEmM4+BbZpcrs Phel2ILDWqjwrb0Y/XZf5gRtF7KaYmOqZLDo5Ou2SoT9dRtZpGI7Mj4mtdB3WU2k lMmX4zPB4u500wvD6hjC8CqwEr5BWuUOJFgywy7jn6IgfEeD833oQBKslt0asD2R qRwZjg44xn/Ddf76/Fa/azIq0G4U2KWa2gY22pAfRQ++bgHiUQiHsK33VY1fv1Vu Ol/FQQlMvqxtbMRUx5YpLh1ULbEAd5J4IXLmlne1ySv1xadVOV0umu4RUL/tjLc2 ucOr7qNLgBbrECZ+YwW5HyvYgKbrOLlwb3t1mgMbkhjegibcIFCWY/Y+yNbxt/6S xRMUQts6vUb5ACVzrCSeoAYIRyTNUMiEINYkxdSqv8JY3H12c5nE9KVY/lLr79mo HVHMIpkF6Ld/3f1xrCjS1VG9YOUJ4wHY7LSVO+HfusipCYyQTsQ792Alj8dsZ+gX +K1MGtChnBU= =SwCk -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] first pass at --debug-build
On Monday 23 January 2006 19:31, Alec Warner wrote: I'm stuck on this. Part of me wants to see more new features in portage and part of me screams horrible hack :P the idea or the implementation ? there is no getting around the idea and forcing the users to do this stuff for every package is bad design -mike -- gentoo-portage-dev@gentoo.org mailing list
