Hi Keith,
Thank you for the clarification. I have no further comments.
Thanks,
--Karen
On 06/29/10 11:23 AM, Keith Mitchell wrote:
Hi Karen,
My responses are below.
On 06/29/10 11:14 AM, Karen Tung wrote:
Hi Keith,
I got a couple of questions about your changes inline.
On 06/29/10 10:54 AM, Keith Mitchell wrote:
Hi all,
I need a code review for my fix for bugs 16400 and 16408
https://defect.opensolaris.org/bz/show_bug.cgi?id=16400
https://defect.opensolaris.org/bz/show_bug.cgi?id=16408
Webrev:
http://cr.opensolaris.org/~kemitche/16400/
Details of 16400:
Added timeout_seconds attribute to all "exec_method" elements. As
all of our custom exec_methods exec ":true", I set the timeouts to
0. It's been suggested that perhaps the timeout should match the
"real" service; that seems to me like extra work (and maintenance,
if those values ever change in the "real" service - would they need
to be updated here?), but I can change the values easily enough if
there's concern.
I also removed the xmlns:xi portion from all *live.xml files, as the
DTD validation was having problems with those and they served no
apparent purpose.
I noticed that you also added enabled='true' to some of the services
that we dummy out.
Is that necessary for the validation to succeed?
Yes, the enabled attribute was also required by the schema.
Verification:
Used lxml.etree and pointed at the latest service_bundle.dtd.1 file
from the onnv-gate to verify that our live.xml files pass
validation. Additionally, I'm running DC builds of liveCD, text
installer, and AI, and so far they've all passed the ba-config step,
which is where the validation would occur. I will also ensure that
each image boots properly before pushing.
Details of 16408:
The install-incorporation manifest in slim_source needs to match
what was previously handled by RE and the importer; which means the
obsolete/renamed packages need to be included, as well as some
additional packages that are tagged under install-incorporation
(such as python/lxml). As a short term fix, I've explicitly added
them to the manifest file; long term it would be more consistent for
our gate to build the empty, renamed packages (to catch the cases of
upgrading from a built copy of our gate, and for tracking purpose) -
but for expediency's sake I'd like to defer that and lump it with
changes to our gate to fully remove the SVR4 packages.
I noticed that the FMRI you specified included build numbers. Does
that mean you will
have to update this file for every build? Can we omit the build
numbers so the latest
will get pick up?
The build numbers for the renamed packages are permanently at 133 -
that won't change with each build. The build numbers for
developer/dtrace/toolkit, library/python-2/lxml-24 and lxml-26 I've
set to 142 based on emails with David Comay (note that they'd need to
be at 143 for this build, for example; and if they needed to be
dynamically set that would be simple enough to do).
Thanks,
Keith
Thanks,
--Karen
Verification:
Built the gate; ran a depot out of the built packages and confirmed
that the install-incorporation has all expected packages constrained.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
