* [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
@ 2014-01-14 0:08 creffett
2014-01-14 0:50 ` Mike Frysinger
0 siblings, 1 reply; 12+ messages in thread
From: creffett @ 2014-01-14 0:08 UTC (permalink / raw
To: gentoo-portage-dev; +Cc: Chris Reffett
From: Chris Reffett <creffett@gentoo.org>
---
pym/repoman/checks.py | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/pym/repoman/checks.py b/pym/repoman/checks.py
index 85aa065..a408ee3 100644
--- a/pym/repoman/checks.py
+++ b/pym/repoman/checks.py
@@ -731,6 +731,21 @@ class DeprecatedHasq(LineCheck):
re = re.compile(r'(^|.*\b)hasq\b')
error = errors.HASQ_ERROR
+# EAPI <2 checks
+class Eapi01UndefinedPhases(LineCheck):
+ repoman_check_name = 'EAPI.incompatible'
+ undefined_phases_re = re.compile(r'^\s*(src_configure|src_prepare)\s*\(\)')
+
+ def check_eapi(self, eapi):
+ return eapi in ('0', '1')
+
+ def check(self, num, line):
+ m = self.undefined_phases_re.match(line)
+ if m is not None:
+ return ("%s" % m.group(1)) + \
+ " phase is not defined in EAPI=0/1 on line: %d"
+
+
# EAPI-3 checks
class Eapi3DeprecatedFuncs(LineCheck):
repoman_check_name = 'EAPI.deprecated'
--
1.8.5.1
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
2014-01-14 0:08 [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1 creffett
@ 2014-01-14 0:50 ` Mike Frysinger
2014-01-14 3:23 ` Tom Wijsman
0 siblings, 1 reply; 12+ messages in thread
From: Mike Frysinger @ 2014-01-14 0:50 UTC (permalink / raw
To: gentoo-portage-dev; +Cc: creffett
[-- Attachment #1: Type: Text/Plain, Size: 809 bytes --]
On Monday 13 January 2014 19:08:30 creffett@gentoo.org wrote:
> From: Chris Reffett <creffett@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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
2014-01-14 0:50 ` Mike Frysinger
@ 2014-01-14 3:23 ` Tom Wijsman
2014-01-14 4:59 ` Mike Frysinger
0 siblings, 1 reply; 12+ messages in thread
From: Tom Wijsman @ 2014-01-14 3:23 UTC (permalink / raw
To: gentoo-portage-dev; +Cc: creffett, vapier
[-- Attachment #1: Type: text/plain, Size: 3905 bytes --]
On Mon, 13 Jan 2014 19:50:44 -0500
Mike Frysinger <vapier@gentoo.org> wrote:
> On Monday 13 January 2014 19:08:30 creffett@gentoo.org wrote:
> > From: Chris Reffett <creffett@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 : TomWij@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
2014-01-14 3:23 ` Tom Wijsman
@ 2014-01-14 4:59 ` Mike Frysinger
2014-01-14 5:37 ` Brian Dolbec
2014-01-14 21:15 ` Tom Wijsman
0 siblings, 2 replies; 12+ messages in thread
From: Mike Frysinger @ 2014-01-14 4:59 UTC (permalink / raw
To: Tom Wijsman; +Cc: gentoo-portage-dev, creffett
[-- Attachment #1: Type: Text/Plain, Size: 3529 bytes --]
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 creffett@gentoo.org wrote:
> > > From: Chris Reffett <creffett@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.
> 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.
certainly, but we need to notify the dev community first
> 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
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>
> > 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?
the Author field of the git commit
> 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?
if they differ, git will post the From: as the first line of the body so that
`git am` can do the right thing. if they're the same, then git omits it.
they don't *need* to be the same for patches to be merged correctly, but they
should be the same to cut down on extraneous noise. the focus is the commit
message/code, not other random junk that takes 3 seconds to fix with a
configuration tweak.
> > 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:
yes, typo when i hand wrote it
> 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.
> > 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.
and yet it exists today. as long as portage supports an EAPI, i see no reason
to omit useful checks like this.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
2014-01-14 4:59 ` Mike Frysinger
@ 2014-01-14 5:37 ` Brian Dolbec
2014-01-14 6:37 ` Mike Frysinger
2014-01-14 21:15 ` Tom Wijsman
1 sibling, 1 reply; 12+ messages in thread
From: Brian Dolbec @ 2014-01-14 5:37 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]
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 creffett@gentoo.org wrote:
> > > > From: Chris Reffett <creffett@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 <dolsen@gentoo.org>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 620 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
2014-01-14 5:37 ` Brian Dolbec
@ 2014-01-14 6:37 ` Mike Frysinger
0 siblings, 0 replies; 12+ messages in thread
From: Mike Frysinger @ 2014-01-14 6:37 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: Text/Plain, Size: 1574 bytes --]
On Tuesday 14 January 2014 00:37:21 Brian Dolbec wrote:
> 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 creffett@gentoo.org wrote:
> > > > > From: Chris Reffett <creffett@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.
[gentoo-portage-dev] [PATCH] Document bugzilla workflow
From: SebastianLuther@gmx.de
To: gentoo-portage-dev@lists.gentoo.org
Date: 08.01.2014 13:25
off the top of my head, the only team that does this sort of flow is the docs
team, and i've never particularly cared for it. i'd prefer we stick with
using the INPROGRESS flag as our "lock" to avoid stomping on each other's feet
as it's already part of the flow. if that doesn't work out, we can talk about
alternatives.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
2014-01-14 4:59 ` Mike Frysinger
2014-01-14 5:37 ` Brian Dolbec
@ 2014-01-14 21:15 ` Tom Wijsman
2014-01-19 9:44 ` Mike Frysinger
1 sibling, 1 reply; 12+ messages in thread
From: Tom Wijsman @ 2014-01-14 21:15 UTC (permalink / raw
To: gentoo-portage-dev; +Cc: vapier, creffett
[-- Attachment #1: Type: text/plain, Size: 2693 bytes --]
On Mon, 13 Jan 2014 23:59:11 -0500
Mike Frysinger <vapier@gentoo.org> wrote:
> 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.
Okay, I will comment there later; since I now have a whole other vision
of the bug workflow in my head due being asked to do this, I rather see
the resulting workflow as more handy than the posted workflow doc.
As a side note, those changes were with permission suggested by dol-sen.
> > 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.
>
> certainly, but we need to notify the dev community first
+1
> 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?
The suggested naming sounds good to me, I suggest we document that.
> > 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?
Yes, I agree that de-duplicating 're' is an overkill change with no
benefit other than some non-measured performance; but, the latter
changes contain a benefit in more correct matching of the parentheses.
> > > 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.
>
> and yet it exists today.
Does that existence mean it has an actual purpose? Or is it just there?
> as long as portage supports an EAPI, i see no reason to omit useful
> checks like this. -mike
Repeating my original question in different words: Why is it useful?
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : TomWij@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
2014-01-14 21:15 ` Tom Wijsman
@ 2014-01-19 9:44 ` Mike Frysinger
0 siblings, 0 replies; 12+ messages in thread
From: Mike Frysinger @ 2014-01-19 9:44 UTC (permalink / raw
To: gentoo-portage-dev; +Cc: Tom Wijsman, creffett
[-- Attachment #1: Type: Text/Plain, Size: 1364 bytes --]
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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
@ 2014-01-19 16:59 Mike Gilbert
2014-01-20 5:47 ` Mike Frysinger
0 siblings, 1 reply; 12+ messages in thread
From: Mike Gilbert @ 2014-01-19 16:59 UTC (permalink / raw
To: gentoo-portage-dev
On Sun, Jan 19, 2014 at 4:44 AM, Mike Frysinger <vapier@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)?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
2014-01-19 16:59 Mike Gilbert
@ 2014-01-20 5:47 ` Mike Frysinger
2014-01-20 6:02 ` Alec Warner
0 siblings, 1 reply; 12+ messages in thread
From: Mike Frysinger @ 2014-01-20 5:47 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: Text/Plain, Size: 1072 bytes --]
On Sunday 19 January 2014 11:59:36 Mike Gilbert wrote:
> On Sun, Jan 19, 2014 at 4:44 AM, Mike Frysinger <vapier@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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
2014-01-20 5:47 ` Mike Frysinger
@ 2014-01-20 6:02 ` Alec Warner
2014-01-20 6:40 ` Mike Frysinger
0 siblings, 1 reply; 12+ messages in thread
From: Alec Warner @ 2014-01-20 6:02 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]
On Sun, Jan 19, 2014 at 9:47 PM, Mike Frysinger <vapier@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 <vapier@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
[-- Attachment #2: Type: text/html, Size: 1910 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1
2014-01-20 6:02 ` Alec Warner
@ 2014-01-20 6:40 ` Mike Frysinger
0 siblings, 0 replies; 12+ messages in thread
From: Mike Frysinger @ 2014-01-20 6:40 UTC (permalink / raw
To: gentoo-portage-dev
[-- Attachment #1: Type: Text/Plain, Size: 410 bytes --]
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
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-01-20 6:40 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-14 0:08 [gentoo-portage-dev] [PATCH] Add repoman check to warn if src_prepare/src_configure are used in EAPI 0/1 creffett
2014-01-14 0:50 ` Mike Frysinger
2014-01-14 3:23 ` Tom Wijsman
2014-01-14 4:59 ` Mike Frysinger
2014-01-14 5:37 ` Brian Dolbec
2014-01-14 6:37 ` Mike Frysinger
2014-01-14 21:15 ` Tom Wijsman
2014-01-19 9:44 ` Mike Frysinger
-- strict thread matches above, loose matches on Subject: below --
2014-01-19 16:59 Mike Gilbert
2014-01-20 5:47 ` Mike Frysinger
2014-01-20 6:02 ` Alec Warner
2014-01-20 6:40 ` Mike Frysinger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox