HI Keith.
On 04/23/10 09:40 AM, Keith Mitchell wrote:
Sue, thanks for catching the copyright for me!
Jack - earliest copyright I can find for that file (initially
bootroot_initialize.py) is 2008, so the copyright dates should be
"2008, 2010". No need for an updated webrev, but please make that update.
OK. Thanks also for sending info on how to check this.
Jack
Thanks,
Keith
On 04/23/10 09:25 AM, Jack Schwartz wrote:
Hi Keith, Joe and Sue...
Thanks to all of you for your review.
D'oh... :) I had changed line 169 for the test program but it didn't
make it into the webrev... Anyhow, I fixed that and retested the
final bits.
I also updated the copyright per Sue's findings.
Webrev updated, same spot.
http://cr.opensolaris.org/~schwartz/100404.1/webrev/
I'll push later today unless another intervening comment comes in the
meantime.
Thanks,
Jack
On 04/22/10 03:32 PM, Keith Mitchell wrote:
Hi Jack,
This algorithm looks much better.
Line 169 would still be more legible as:
"if excitem_s.startswith(item_s):"
Thanks,
Keith
On 04/22/10 03:21 PM, Jack Schwartz wrote:
Forgot to say the webrev has been updated at the same location:
http://cr.opensolaris.org/~schwartz/100404.1/webrev/
Thanks,
Jack
On 04/22/10 03:20 PM, Jack Schwartz wrote:
Hi Joe and Keith.
Thanks for your comments. I've finally had time to go back and
work on this. Below is IMHO a solution which addresses all of
your concerns:
On 04/ 5/10 07:44 AM, Keith Mitchell wrote:
On 04/ 5/10 05:16 AM, joseph.vl...@oracle.com wrote:
On 04/ 4/10 11:41 PM, Jack Schwartz wrote:
Hi everyone.
This easy webrev is for a fix to the DC finalizer script which
copies files into the boot_archive. It fixes how
whole-directories are excluded.
I have tested this fix by having built several images during
Driver Update testing.
Webrev:
http://cr.opensolaris.org/~schwartz/100404.1/webrev/index.html
Bug:
http://defect.opensolaris.org/bz/show_bug.cgi?id=15290
Thanks,
Jack
_______________________________________________
caiman-discuss mailing list
caiman-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
Hey Jack,
I see what I think might be a problem with your solution. What
if the item you are attempting to match is a substring match and
not the full match?
For example:
>>> excitem="AAAA/BBB/CCC"
>>> excitem.find("AA")
0
This matches "AA" even though I think you only want to match "AAAA"
I think this proposed solution might be safer:
>>> EXCLUDES = "one "
>>> for i in excitem.split('/'):
... if "AAA" == i:
... EXCLUDES = EXCLUDES + "more excludes"
...
>>> print EXCLUDES
one
>>>
Correctly does not match "AAA"
>>> for i in excitem.split('/'):
... if "AAAA" == i:
... EXCLUDES = EXCLUDES + "more excludes"
...
>>> print EXCLUDES
one more excludes
>>>
but does correcly match "AAAA"
What do you think?
If I append a / to the end of excitem and to the end of item if it
doesn't already end in /, then it all works nicely. The trailing
/ of item properly "terminates" strings which would otherwise
incorrectly match. For example,
/var/pk will incorrectly show as an ancestor to /var/pkg/123,
but
/var/pk/ won't.
I tested using a test program with a pretty extensive list of test
cases, and then tested by running a build and checking added
output. If you are curious, test program and output is attached.
Please bless.
Thanks,
Jack
I'm not sure that'll work in all cases Joe? Such as if "foo/bar"
were included, and "bar" were excluded, it would match? But it's
early on a Monday and maybe I'm not thinking it through.
Another point to consider is, it doesn't *seem* like there would
be ill effects in the scenario you bring up. For example,
consider the following set of dirs:
foo
foo/bar
foo/bartwo
Suppose you wanted to include foo, include foo/bartwo, and
exclude foo/bar. Based on the code, "foo/bar" would 'match'
against both foo/bar and foo/bartwo as it looped, but at line 163
all that's added is a "grep -v foo/bar" - so no harm done, in
this case, in being overzealous.
That said:
Jack, please use "if excitem.startswith(item):" instead of
parsing for "...find(..) == 0".
- Keith
Joe
_______________________________________________
caiman-discuss mailing list
caiman-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
caiman-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss