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
