On 03/22/10 08:42 AM, Louis Tsien wrote:
> On 03/19/10 20:08, Liane Praza wrote:
>> On 03/19/10 02:51 PM, Louis Tsien wrote:
>>> this transition has made me a newbie again -- not in a good way.
>>>
>>> - got build machine updated so that it is building IPS packages cleanly
>>> (thanks to RE staff)
>>> - got test machine installed with dev_133, despite being in a lab where
>>> the opg-labs script doesn't work and will not be supported by lab
>>> support staff. dev_133 is the latest (and only) version currently
>>> available on the local AI servers.
>>>
>>> what I'm trying to do: test FMA, for which I must have the cpu/memory
>>> error injector package formerly known as SUNWonmtst.{i,u,v} . These are
>>> built from closed sources.
>>>
>>> - located new package name SUNWonmtst , dependent on
>>> system/fault-management/mtst , and understand that it will be in
>>> repo.extra, not repo.redist. all of that makes perfect sense.
>>
>> The new package name is really system/fault-management/mtst. The other
>> one is a legacy name and will go away in the future.
>>
>>>
>>> My build machine is running 133. My test machine is running 133. The
>>> sources from which I built are ~135, maybe 136. I have a full, clean
>>> base build and a full build with my changes (1 source file, not closed),
>>> both including closed source components.
>>>
>>> I attempted the following:
>>>
>>> 1) run pkg.depotd on build machine, -d to repo.extra from my base build.
>>> 'pkg install' client failed due to version dependency mismatches.
>>
>> Yes, IPS checks that you have matched versions. You could have upgraded
>> your test machine so that it's running the bits from your gate. You can
>> also build without dependencies for your ON packages (SUPPRESSPKGDEP),
>> as described in usr/src/pkg/README.pkg, though then mismatches will be
>> at your own risk.
>>
>> It'd be better to image-update your test machine completely to your
>> bits, or in the future, you could also get the repository from the
>> gatekeeper's archived build, though obviously this won't work for build
>> 133.
>>
>>>
>>> 2) run pkg.depotd on build machine, -d to
>>> /ws/onnv-gate/packages/sparc/snv_136/nightly/repo.extra
>>>
>>> pkg.depotd failed with python errors.
>>
>> Without knowing the errors, it's hard to say anything useful.
> reproduced on another test machine:
>
> burpen-cs11-1 65 =>pwd
> /ws/onnv-gate/packages/sparc/snv_136
> burpen-cs11-1 66 =>ls -d ../*136*
> ../snv_136/ ../snv_136-pit1/
> ../snv_136-nd/ ../snv_136-pit1-nd/
> burpen-cs11-1 67 =>/usr/lib/pkg.depotd -d ./repo.extra -p 55555
> Traceback (most recent call last):
> File "/usr/lib/pkg.depotd", line 681, in <module>
> writable_root=writable_root)
> File "/usr/lib/python2.6/vendor-packages/pkg/server/repository.py", line
> 262,
> in __init__
> self.__init_state(refresh_index=refresh_index)
> File "/usr/lib/python2.6/vendor-packages/pkg/server/repository.py", line
> 780,
> in __init_state
> self.__write_config()
> File "/usr/lib/python2.6/vendor-packages/pkg/server/repository.py", line
> 954,
> in __write_config
> self.cfg.write(self.cfgpathname)
> File "/usr/lib/python2.6/vendor-packages/pkg/server/repositoryconfig.py",
> line 481, in write
> "%s" % (pathname, strerror))
> RuntimeError: Unable to open
> /ws/onnv-gate/packages/sparc/snv_136/repo.extra/cfg_cache for writing:
> Permission denied
> burpen-cs11-1 68 =>
>
> so I have to have write permission on the directory containing the repository?
No, you need to use the --writable-root argument to pkg.depotd(1M).
It's in the manpage, and the onu script has an example of how to use it.
You're also misusing the "-d" argument to onu, which (per the onu(1)
manpage) "Specifies that <dir> contains repo.redist and repo.extra
sub-directories."
> does that mean that only one instance of pkg.depotd should ever be started on
> any directory containing a repository?
No.
>>> 3) run pkg.depotd on build machine, -d to repo.dist from my build.
> ^^^^^^^^^
>>> got repository config error on server, publisher.prefix required, use
>>> --set-property to fix or update cfg_cache_file
>>
>> That's odd, we set this automatically during build time. What is prefix
>> set to in your repo.redist/cfg_cache file?
>>
>> (Usually I get this when I mistype the path for -d. Certainly if you
>> did repo.dist, it would have failed.)
>
> the packages from my base build are in $CODEMGR_WS/packages-base
> and for build with my changes, $CODEMGR_WS/packages
>
> packages-base/sparc/nightly has a repo.dist, repo.extra, and repo.redist
> packages/sparc/nightly has only a repo.extra and repo.redist, no repo.dist
repo.dist? Really? What's the date/ownership on it? Is it consistent
with repo.redist and repo.extra, or was it maybe created inadvertently
somewhere along the line? The build system won't ever create that
directory, and it would be useful to know if one of our tools is
misbehaving.
> packages-base/sparc/nightly/repo.dist does NOT contain a cfg_cache file
> packages-base/sparc/nightly/repo.redist -does- have a cfg_cache file,
> containing
> the lines
>
> [publisher]
> alias =
> prefix = on-nightly
>
> as does
> packages/sparc/nightly/repo.redist
>
> so I should have used repo.redist instead of repo.dist?
No, you should iuse packages/sparc/nightly, per above.
> what's the conceptual difference between repo.dist and repo.redist ? or, why
> is
> repo.dist needed?
Per above.
>>> 4) wanted to run pkg.depot -d to
>>> /ws/onnv-gate/packages/sparc/snv_133/nightly , only to find that at
>>> snv_133 the onnv-gate still holds SVR4 packages.
>>
>> Right. We hadn't integrated yet, so these ON-specific packages aren't
>> available in IPS format.
>>
>>> so I gave in and ran
>>> the old-fashioned
>>>
>>> pkgadd -d . SUNWonmtst.u -- for the test machine I happened to be using
>>>
>>> can you explain what happened, and how to avoid problems 1-3 in future
>>> when 4 won't be available any more?
>>
>> Hope this helps...
>>
>> liane
>
> _______________________________________________
> on-ips-dev mailing list
> on-ips-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/on-ips-dev
