Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
On Tuesday 14 January 2014 16:15:48 Tom Wijsman wrote: On Mon, 13 Jan 2014 23:59:11 -0500 Mike Frysinger wrote: we probably should just use dev branches in the main repo, at least for people who have write access to the repo dev/$USERNAME/whatever you want To be more clear, which one? g.o.g.o, GitHub or is one of both fine? g.o.g.o r'\s*src_(configure|prepare)\s*\(\)' You can then proceed further and move the re outside: the idea was to walk a balance between simplicity and maintainability. imo, the fixed version above is the best. What about the latter improvements about the parentheses? seems fine as long as portage supports an EAPI, i see no reason to omit useful checks like this. Repeating my original question in different words: Why is it useful? people run repoman outside of the main tree. we don't really know their desire for EAPI compatibility. legacy/old portage/who knows. Chromium OS for a long time was restricted to EAPI 4 for two reasons -- it had an old portage version (and upgrading to a newer one regressed performance significantly, so we held off until we could figure out why), and it was using a really old stage3 to build the SDK (which means we needed to support upgrading an old system too). -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
On Sun, Jan 19, 2014 at 4:44 AM, Mike Frysinger vap...@gentoo.org wrote: Chromium OS for a long time was restricted to EAPI 4 for two reasons -- it had an old portage version (and upgrading to a newer one regressed performance significantly, so we held off until we could figure out why) I am curious to know more about the performance regression if you can share. Is that something that got fixed, or did you disable some features (like the slot-operator stuff)?
Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
On Sunday 19 January 2014 11:59:36 Mike Gilbert wrote: On Sun, Jan 19, 2014 at 4:44 AM, Mike Frysinger vap...@gentoo.org wrote: Chromium OS for a long time was restricted to EAPI 4 for two reasons -- it had an old portage version (and upgrading to a newer one regressed performance significantly, so we held off until we could figure out why) I am curious to know more about the performance regression if you can share. Is that something that got fixed, or did you disable some features (like the slot-operator stuff)? we finally tracked it down (was due to new the new FEATURES=merge-sync option. when you're installing 200 to 500 binary packages (with like 32 in parallel), that can easily choke your throughput. some systems saw really excessive latencies (which i would guess was due to their drive taking longer to process dirty blocks). but it took us some time to figure that out as we were making a large version jump and we didn't have too much time to dedicate to tracking it down. lots o bugs to fix. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
On Sun, Jan 19, 2014 at 9:47 PM, Mike Frysinger vap...@gentoo.org wrote: On Sunday 19 January 2014 11:59:36 Mike Gilbert wrote: On Sun, Jan 19, 2014 at 4:44 AM, Mike Frysinger vap...@gentoo.org wrote: Chromium OS for a long time was restricted to EAPI 4 for two reasons -- it had an old portage version (and upgrading to a newer one regressed performance significantly, so we held off until we could figure out why) I am curious to know more about the performance regression if you can share. Is that something that got fixed, or did you disable some features (like the slot-operator stuff)? we finally tracked it down (was due to new the new FEATURES=merge-sync option. when you're installing 200 to 500 binary packages (with like 32 in parallel), that can easily choke your throughput. some systems saw really excessive latencies (which i would guess was due to their drive taking longer to process dirty blocks). but it took us some time to figure that out as we were making a large version jump and we didn't have too much time to dedicate to tracking it down. lots o bugs to fix. -mike Are you still doing crazy crap like disabling all of the portage locking? ;p -A
Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
On Monday 20 January 2014 01:02:31 Alec Warner wrote: Are you still doing crazy crap like disabling all of the portage locking? ;p yes no. we make sure we hold the right locks and don't do operations that otherwise cause problems. then we disable the core lock grabbing :P. the current locking logic is pessimistic and causes way too much of a slow down for us to do anything else. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
On Monday 13 January 2014 19:08:30 creff...@gentoo.org wrote: From: Chris Reffett creff...@gentoo.org you might want to set ~/.gitconfig to have your name/email so that git sendemail uses the right info in the actual e-mail From: field + undefined_phases_re = re.compile(r'^\s*(src_configure|src_prepare)\s*\(\)') you use re.match, so technically the ^ is redundant i'd suggest merging the regex a little: r'^\ssrc_(configure|prepare)\s*\(\)' could check for pkg_pretend/pkg_info too (it's new to EAPI 4) the regex is naive and can match valid ebuilds. consider ones that handle $EAPI itself and will call the right funcs as necessary. can you check the tree to see if anyone is doing this ? if so, we should drop a note to the dev list and get them fixed up. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
On Mon, 13 Jan 2014 19:50:44 -0500
Mike Frysinger vap...@gentoo.org wrote:
On Monday 13 January 2014 19:08:30 creff...@gentoo.org wrote:
From: Chris Reffett creff...@gentoo.org
Subject: [gentoo-portage-dev] [PATCH] Add repoman check to warn if
src_prepare/src_configure are used in EAPI 0/1
Well, I was planning to cover these bugs; seems we really need to
organize with regards to avoiding double work, as two others have got
the same happen to them. Let's synchronize it.
So, what you have done here is wrote a partial patch for this bug:
https://bugs.gentoo.org/show_bug.cgi?id=379491
Therefore I suggest you that you mention it in the commit subject.
Now that you're working on phases, I wonder whether you plan to deal
with the other bug as well:
https://bugs.gentoo.org/show_bug.cgi?id=365691
While vapier's case could be considered as valid; I think we should
consider that as a bad practice, as one could just as well put the if
inside a phase which is the much more common practice.
Can you let me know whether you would work on this one as well as to
avoid both of us doing the same work on these?
As a note, my WIP work is at the next url; there you can see the bug
numbers I've been working on (still need to revise them, properly
document the added check errors [eg. in `man repoman`] and so on).
https://github.com/TomWij/gentoo-portage-next/branches
If you do something similar, we could check whether we attempt to work
on the same bug; as to avoid clashing. (In this case I think I told
you in #gentoo-qa that I planned to do this; but well, then I can be
lucky that I've not started on it. ^^)
you might want to set ~/.gitconfig to have your name/email so that
git sendemail uses the right info in the actual e-mail From: field
Then what is the From: field that it puts separately into the e-mail
itself? Seems quite odd for these to differ; or, is the latter an
attempt to mark the author? Then why does the e-mail From: field need
to be correct? Afaik it would only use one of both, so only one of both
needs to be correct. But that would make the actual question: Which one?
+ undefined_phases_re =
re.compile(r'^\s*(src_configure|src_prepare)\s*\(\)')
you use re.match, so technically the ^ is redundant
Indeed, they match on a line basis from the beginning of the string.
i'd suggest merging the regex a little:
r'^\ssrc_(configure|prepare)\s*\(\)'
Note that the * behind the first \s was lost; so, with the redundant ^
removed and the * put back it would be:
r'\s*src_(configure|prepare)\s*\(\)'
You can then proceed further and move the re outside:
r'\s*src_(configu|prepa)re\s*\(\)'
The closing parentheses can also be removed because phase( ) is valid:
r'\s*src_(configu|prepa)re\s*\('
(We don't need to account for phase( invalid ) here; as that results
in invalid Bash syntax, which would bail out harder than our checks)
But if we would do that, it would be like:
r'\s*src_(configu|prepa)re\s*\(\s*\)'
could check for pkg_pretend/pkg_info too (it's new to EAPI 4)
+1
the regex is naive and can match valid ebuilds. consider ones that
handle $EAPI itself and will call the right funcs as necessary.
From a QA point of view it seems more preferable to move away from old
EAPIs, than to conditionally support them. The common case is that
ebuilds move from older to newer EAPI and thus would get these
functions as they get to a newer EAPI.
Is there an actual case for downgrading back to an older EAPI?
If not, conditional code that checks $EAPI has no purpose.
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
On Mon, 2014-01-13 at 23:59 -0500, Mike Frysinger wrote: On Monday 13 January 2014 22:23:01 Tom Wijsman wrote: On Mon, 13 Jan 2014 19:50:44 -0500 Mike Frysinger wrote: On Monday 13 January 2014 19:08:30 creff...@gentoo.org wrote: From: Chris Reffett creff...@gentoo.org Subject: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1 Well, I was planning to cover these bugs; seems we really need to organize with regards to avoiding double work, as two others have got the same happen to them. Let's synchronize it. we have a bugzilla workflow doc posted which we'll merge once git is back up. please do not reassign portage bugs to yourself. instead, set the status to INPROGRESS. Sorry, that was me that told him to. I didn't know about a bugzilla workflow doc. Plus I didn't see it at www.gentoo.org. So it wasn't converted to the wiki. -- Brian Dolbec dol...@gentoo.org signature.asc Description: This is a digitally signed message part
