[ Apologies for this internal-centric request. ]
In order to satisfy the dependencies for SUNWinstalladm-tools, I need
to get a SPARC SUNWpython-lxml SVR4 package built. Could someone
please build that and provide a pointer? Of course, we'll need it
integrated into the dock shortly as well (alon
> I think that waiting for 106 IPS repo is a good idea.
> Looking at the 105 one, it doesn't contain changes for
> split SUNWgui-install and in order to be sure that
> images are constructed correctly we should verify
> also using official IPS repo.
Right, the split SUNWgui-install came in after b
> Thanks for filing this bug. As bug 5644 is fixed for now, Target Discovery
> and Target Instantiation test drivers are now built during full build of
> slim_source gate and SUNWinstall-test package was created for delivering
> them to the target system. Also I have filed bug 6224 for integrating
> I am playing with 106 IPS repositories available
> on ipkg.sfbay:29047 for x86 and ipkg.sfbay:29051 for
> Sparc (both available only internally) trying to
> build reduced AI images using official repositories.
>
> As far as x86 image is concerned, it seems that
> SUNWauto-install package depends
> Greg and Tycho, please switch over to the new repo. I talked with David
> Comay who will send a pointer to the SUNWipkg package (or equivalent) which
> contains the IPS bits themselves. You'll of course need that to install from
> the repo. Once you get SUNWipkg, please try what Bart sugge
> I would like to pull over the IPS repository for this test, would you
> tell me how to set up a mirror
> IPS SPARC repo from current one(http://ipkg.sfbay:29048)? At 2008.11
> release, I have set up a local
> x86 repository, but I am not sure where the current SPARC repository
> locates in ipkg.s
> # pwd
> /export/comay/sparc/pkg/repo/catalog
>
> # ls -l
> total 141
> -rw-r--r-- 1 comaystaff 71 Dec 4 23:58 attrs
> -rw--- 1 comaystaff 70398 Dec 4 23:58 catalog
>
> Please check and give me read permission.
This has been done.
> Has anybody tried to image-update the OS by pkg(1) through
> http://ipkg.sfbay:29048
What were you updating from? From the errors you listed, it looks like
you started from some sort of x86 image as I'm seeing drivers specific
to that architecture.
> I realise I'm rather late to the discussion, I'd like to
> know whether the above notes represent an official
> dropping of support for the other UltraSPARC lines
> that we currently support with the NV gate, and if
> so, when were you going to let ON know?
They don't represent any dropping of s
> Why not? I thought there was so much positive discussion around
> providing a partition tool for OpenSolaris, especially one that could
> shrink existing NTFS laptops to make room, that we would want this
> very obvious/visible/discoverable.
>
> Yes, we could leave it burried in a menu somewhe
I'd appreciate a review of the following modified webrev
http://cr.opensolaris.org/~comay/webrev-11276/
which addresses the following issue
11276 reenable delivering RBAC entries as fragments
There are some work-arounds here until SUNWbeadm and SUNWgui-install
deliver their resp
> A seperate bug need to be filed in bugster to see why multicast service did
> not start. It should be filed solaris/network/multicast_routing
Actually, mDNS issues should be filed under solaris/network/dns,
AFAIK.
> We've installed some sparc machines here with the AI image osol_0906-106a
> and have tried out some benchmarks. Some of these benchmarks require
> compiling etc. So, we install SUNWsprot too.
>
> We fail compiling.
>
> Seems usr/bin/as is missing.
At this time, the SPARC version of as(1) is no
> Installer:
> http://cr.opensolaris.org/~dminer/dc-681-v2/
I assume this webrev is actually
http://cr.opensolaris.org/~dminer/slim-681-v2/, right?
Looks good.
> Distro Constructor:
> http://cr.opensolaris.org/~dminer/dc-681-v2/
src/build_dist.lib
Line 457 - It would be nice if the Liv
> OK, will restore. There's a subtlety that, should you also need to
> build media for that older release, you'd need to use the DC that's
> sync'ed with this in order to build that older release, rather than the
> version that was used originally. That seems OK, but if you can think
> of a reaso
> Please review the changes for
>
> 3583 Live CD boot should not display license file automatically
> http://defect.opensolaris.org/bz/show_bug.cgi?id=3583
>
> which are posted at:
>
> http://cr.opensolaris.org/~dminer/slim_3583/
>
> Changes have been tested on both a CD and an installed system.
D
> Bug 4333 has been filed regarding order of the items in the Grub menu.
>
> Currently it has the two standard boot modes, followed by the "Boot from
> Hard Disk", followed by the two accessibility modes. The "bug" is to
> put the "Boot from hard Disk" item at the bottom of the menu.
>
> I seem to
> I have confirmed that the 101a images available on nana at:
> http://nana.sfbay/products/osol_0811/101a/ do "not" contain
> /etc/skel/<.profile and .bashrc> files.
>
> When will they be available and how do you want to track this issue?
I believe these fixes didn't get into those images because
I'd appreciate a code review of the fix for
1884 Default PS1 fails to print current directory containing format specifiers
http://defect.opensolaris.org/bz/show_bug.cgi?id=1884
The webrev can be found here
http://cr.opensolaris.org/~comay/webrev-1884/
The fix is straightforward and though the i
> OK for now, though it seems like filing a bug to have jack change to use
> the standard profile would be appropriate.
Thanks, yes I'll do that.
dsc
> Looks like the following bug was also added to
> the blocker list earlier today -
>
> 4234 SUNWinstalladm-tools fails dependency check for SUNWapch2
I added it because it was unclear whether the tools was actually
looking at SVR4 package names or not. I assume they don't and now that
4417 is ad
Author: David.Comay at Sun.COM
Repository: /hg/caiman/slim_source
Latest revision: 1c9e9b99681e3670b1a5a4076504471b0b44b3bc
Total changesets: 1
Log message:
1884 Default PS1 fails to print current directory containing format specifiers
Files:
create: usr/src/cmd/slim-install/user/jack/loca
> My only question, is what'll happen on a system image-updated as
> to if they'll still have the file at /LICENSE or if the one at
> /etc/LICENSE will be the accurate one anyways. (Are there any races? Can I
> update show-license but not the file, and thus /etc/LICENSE would be an
> incorrec
> One of the things I am trying to figure out the number of options a user
> should have to boot OpenSolaris. This of course directly translates to
> the number of grub entries.Currently, the entry will boot the
> system in the best available mode, i.e if your hardware supports ISA64
> then
> We discussed this at the summit, and everyone was orally for including
> compiz on the Indiana release (but having it turned off by default).
> Is this still the plan?
It sounded like Compiz isn't quite ready (particularly given the
limited device support) for integration into the Live CD at the
> I would tend to agree.. As long as it's not enabled by default and fails
> gracefully if the required hardware support isn't there, what's the harm
> in including it?
If that's the case, then including it in the repository seems
reasonable. But I thought that I heard at the summit that the grac
it to snv_75a,
etc.
dsc
-- Forwarded message --
Date: Tue, 23 Oct 2007 11:30:45 -0700 (PDT)
From: david.co...@sun.com
To: pkg-discuss at opensolaris.org
Subject: [pkg-discuss] Summary: Second phase of redistribution changes.
Author: David.Comay at Sun.COM
Repository: /hg
> storage drivers needed to be pulled). As such, microroot_pkgs.txt will
> need to be patched to remove the packages in question (I've attached a
> diff to this message).
Of course, I forgot the patch the first time - it should be there now.
dsc
-- next part --
diff -r 14
Roland,
> 2. The patch seems to miss /etc/ksh.kshrc which is important for ksh93
> (see PSARC 2006/587 for the background. Short: Without this file ksh93
> will not enable any editor mode (for strict POSIX shell conformance - we
> work around this usability issue by enabling the "gmacs" editor mod
> BTW: What about replacing the standard /etc/ksh.kshrc with this version
> (it's like the current once except that it sets a custom prompt which is
> modeled after the default for SuSE Linux):
I'm looking and doing something similar and I'll look at the code you
provided.
> 2. What about setting
> http://cr.opensolaris.org/~dminer/license/
packages/utils/license.desktop
Based on current discussions with Bonnie, we're going to be
putting the license file under /LICENSE rather than /README.
The file /LICENSE (which I'll send to you and Jean in a
separate ema
> http://cr.opensolaris.org/~dminer/dc_license/
Looks fine - the only thing I can think of is perhaps /LICESNE should
ship as 0444.
I assume there are also some corresponding changes on the slim side,
right?
dsc
> And please review the webrev at:
>
> http://cr.opensolaris.org/~dminer/slim_prototype/
>
> which addresses the below issues with licensing as well as fixes the
> empty grub menu on the installed system and failure of the installer's
> Reboot button to initiate an actual reboot.
Looks good. A fe
>> slim_prototype/packages/utils/profile
>>
>> I wonder whether it makes sense to add /usr/gnu/bin to the
>> front of the path for "jack"?
>>
>
> I'll add it, I think it would be safer in terms of stabilizing at this point
> to put it at the end than front, though.
Mmm, but in that case
> I can confirm the October 30th iso installed fine on a Dell
> Optiplex with 512MB ram. However, it's most certainly not very tested in
> only 512MB.
I can also confirm that a recent ISO installed successfully on a VMware
Fusion instance where the VM was allocated 512MB.
dsc
> If we use zfs, I believe the minimum memory requirement is 1 GB of memory.
> If you use anything lower than 1 GB, you will have performance issues. I
> don't know whether the memory requirement to install ZFS had changed
> recently.
Certainly ZFS does have higher memory requirements than oth
> I ran into this same failure.
>
> Change (add) your ai manifest to point to /dev.
>
> installation will be performed from
> http://pkg.opensolaris.org/release (opensolaris.org)
> installation will be performed from
> http://pkg.opensolaris.org/release (opensolaris.org)
Actually as this build
> The fix looks like it goes into SUNWauto-install. While this package isn't on
> the LiveCD, it is part of the "entire" incorporation. Taking in this fix
> means importing SUNWauto-install and "entire" into the repository again,
> correct?
The key is the following packages should be reimported
> Hopefully, the user experience is going to change soon, since nwam 0.5
> will be available in build 100:
> 2683 Phase 0.5 of nwam Integration.
> http://defect.opensolaris.org/bz/show_bug.cgi?id=2683
Although NWAM 0.5 will help, there should have been improvements in
this area starting with build
> Bug 4049 has an entry from Dave Miner which states that "The fix for bug
> 1040 unfortunately lost the fix for bug 496,..."
>
> The changeset for bug 496 contains more changes then seems to be
> required to fix bug 4049.
>
> My understanding is to fix bug 4049 what needs to be done is to change
>
> Regarding Bug 4108 "The .profile file is missing in the default user's
> directory after installation"
>
> Shouldn't this be a stopper for 2008.11 ?
Yes although it's already marked as such (it blocks bug 2413).
dsc
> I would prefer we just document the limitation, so long as we can set
> the root password correctly and users can login as or su to root after
> installation. As I noted in the bug already, the behavior would at best
> be a stop-gap until the correct solution of specifying roles in the
> manifes
> No plans, as far as I know, and certainly not in the next week, so it'll
> need to be added to the IPS import.
If someone could file a bug on this in opensolaris/packaging, I'll pick
this up when I do the next set of import changes.
dsc
> So I suspect the fix for 4108 will not be pushed until early next week.
I think that's fine as the other half of the fix, populating /etc/skel,
won't be ready until then either.
dsc
> Please check at /net/indiana-build.central/export/home/sundar/packages and
> pick up for now. This package SUNWpython-xml is in the process of moving to
> IPS and it will be available soon.
I'm trying to pull this in to some final build 100 changes. But just
to verify, the package in questi
Author: David.Comay at Sun.COM
Repository: /hg/caiman/distro_constructor
Latest revision: d2193c274e7df20baa61e7f6576ccbbf6ebf978d
Total changesets: 1
Log message:
1269 Changes needed to built current ISO: microroot size, postrun
Files:
create: src/postrun_scripts/SUNWccsm.postinstall.24
> The changes enable booting Indiana under a Xvm domu.
> Location:
> http://cr.opensolaris.org/~nadkarni/listcd/
I haven't looked at the changes to livecd.c (yet) but I was curious
about the change to live-fs-root - I thought the recommendation was to
change this to a "devfsadm -C" (which will cle
> The purpose of listcd is locate the compressed /usr. Since devfsadm is
> located in /usr/sbin, it is not available hence this is mounting the file
> system using the explicit name. The issue with Xvm was that devices under
> /devices/xvdp were not being instantiated.
Strange, because when
> I've pinged Dave and Sanjay for clarification and direction. I'm unaware of
> any new policy, but that's likely just ignorance.
For now, please continue to use SUNW as a prefix.
> could I please ask for reviewing changes for following bug ?
>
> 6612 AI image missing some drivers
> http://defect.opensolaris.org/bz/show_bug.cgi?id=6612
>
> webrev:
> http://cr.opensolaris.org/~dambi/bug-6612/
I believe the following need to be added (mostly reflects changes to
the repository
> I tried 109, seems most fix not in now, like 6320, and disk unit size.
> So I believe 110 would a major release, it will be delivered on around
> end of this week, right?
> I am also waiting for 110 for testing.
Build 110 will likely be available early to the middle of next week.
> Could you tell us where the 110 IPS repo locates?
> Right now, we are using http://osol-re.sfbay:80, which still is 109
> to rsync our Beijing local IPS repo.
Build 110 hasn't finished yet so I would suggest waiting for the
official announcement from Release Engineering. The build is scheduled
> This is a known issue and it is tracked under:
>
> 7612 - SUNWinstalladm-tools/SUNWauto-install-common needs to be back-publish
>
> To workaround this, you either have to pkg image update your AI server to
> osol 110. osol_110 is not even available yet.
Alternatively, I believe the versions of
> Based on this, I am thinking if it might make sense to reorder
> packages in default manifest, so that people don't run into this
> kind of problems when they neglect (or don't know it is needed)
> to reorder packages.
I think it makes sense to have "entire" first in the list for both AI
and DC
> jan damborsky wrote:
>> Currently, if user installs by AI with default manifest,
>> latest bits are pulled from given IPS repository.
>>
>> It seems that one of the scenarios people are interested
>> in is to install particular build which is not the latest one.
>>
>> Following list of packages
>> I happen to find out that the dhcp manifest disappears under
>> /var/svc/manifest/network/ on osol b110 and nevada, which might
>> affect installadm setup of AI server as there is no dhcp service exists by
>> default (users need manually start dhcp daemon ) I just filed a bug on
>> b
> I'm happy to make this change if the osol leads and the gatekeepers are
> OK with re-opening the gate to take the virt-install fix.
I'm fine with this coming into build 111a but not the official ON gate
closure for that is scheduled for Monday evening.
William,
> Author: William Schumann
> Repository: /hg/caiman/slim_source
> Latest revision: 1a63241f5f19518b4aaf0d293cd583b47d2778fa
> Total changesets: 1
> Log message:
> lg
>
> Files:
> update: usr/src/lib/liborchestrator/disk_slices.c
Which bugids does this change cover? Thanks.
> The Acer Still fails to boot normally.
This is with build 110?
What is the "intel-iommu" value in
/platform/i86pc/kernel/drv/rootnex.conf?
> "1. At the GRUB menu highlight the desired boot entry and hit e. Then scroll
> down to the kernel$ line and highlight that line.
> 2. Append the following at the end of the kernel$ line -B intel-iommu=no
> 3. Hit enter and then hit b."
>
> Sorry but it did not work. It still fails. I did it
> Glynn should provide that, but I believe the desired value is "OpenSolaris
> 2009.06".
Yes, that is what Glynn mentioned in bug 5416.
Sarah,
> Could I please get a code review for the following:
>
> http://defect.opensolaris.org/bz/show_bug.cgi?id=8071
> 8071 AI fails if 'username' and 'userpass' are both left out of SC manifest.
>
> Webrev:
> http://cr.opensolaris.org/~sjelinek/bug_8071/
With this change, how does the possibil
> 8427 AI doesn't set dump device to ZVOL on installed system
>
> webrev:
> http://cr.opensolaris.org/~dambi/bug-8427
Jan, is there a reason you're directly writing /etc/dumpadm.conf (a
project private implementation, I believe) rather using dumpadm(1M)?
> Will a fix for bug 6834260 be included in 2009.06? This bug causes
> reboots/hangs when the ESC key is pressed at a specific point early on in
> boot, see:
>
> http://bugs.opensolaris.org/view_bug.do?bug_id=6834260
Yes, this issue will be resolved for 2009.06.
> I tend to agree with Dave in this point. In such cases, referencing
> bug number might save time and is only temporary - it is assumed
> that once related bug is fixed, workaround can be removed and comment
> modified appropriately. Thinking about this particular scenario, I had
> to go through t
> 5009550 install should put fully qualified host name in /etc/hosts
>
> was closed (will not fix) with an explanation that NWAM would fix it.
Sounds like it should be reopened and recategorized to network/config?
dsc
> We've been working away at getting a prototype Slim Install CD built
> (fairly successfully ;-) and I've posted an updated package list off of
> the Slim announcements page [1]. I also posted diffs vs. Sanjay's
> original list, the summary of which is essentially adding the Dwarf
> Caiman instal
> http://www.opensolaris.org/os/project/caiman/Slim_Install/slim_annoucememts/
There are a number of packages on the revised list which seem eligible
to be moved to the repository. Most of these are servers of some sort
and it's not clear how useful they are from the Live CD context
(although I c
> Note that whatever is on the live CD get's installed on the target system.
> Therefore SUNWsshr and SUNWsshu are required. Telnet I would like drop
> entirely.
Good point. Yes, assuming the Live CD and the Install CD are one and
the same (which they are for the moment), then including the S
> Sure, but I'm not sure we need to be in quite such a hurry to toss out
> telnet; last I knew, Windows didn't include an ssh client or server - has
> that changed?
Sorry just in case I wasn't clear; I was just advocating removing the
telnet server packages from the Live CD contents. I'm happy
> SUNWGlib and Gtk* are part of JDS.
Actually, they're delivered by SFW. I believe these are the old GNOME
1.x libraries rather than the current ones delivered by
SUNWgnome-base-libs.
dsc
> Note that some very significant portion of LiveCDs today are actually
> booted into virtual machines. So you're looking at all these
> ZFS-curious people starting it up on their host OS, right clicking on a
> folder in the guest, clicking Share, and seeing if they can access it
> or not on the h
Mike,
>> Sorry just in case I wasn't clear; I was just advocating removing the
>> telnet server packages from the Live CD contents. I'm happy leaving
>> the contents of SUNWtnetc there.
>
> We are worrying about this, right?
>
> $ egrep -e 'SUNWtnet[rd]' /var/sadm/install/contents\
>| nawk '$
> Fair enough. May I suggest as an overriding theme we go for "secure
> by default"[1]? Perhaps adoption of such a strategy can serve as a
> guiding principle for the next time this conversation
> (s/telnetd/$whatever/g) comes up.
Absolutely - Indiana will certain come out of the box in a "secur
> BTW, I would still vote to add the nfs server pkg on CD. As others
> have pointed out, without this functionality setting sharenfs property
> on a dataset would amount to squat.
I'm fine with this too after hearing the propose use cases from MC,
Alok and others.
dsc
>> Sorry just in case I wasn't clear; I was just advocating removing the
>> telnet server packages from the Live CD contents. I'm happy leaving
>> the contents of SUNWtnetc there.
>>
>
> It was clear, I just believe there is worth to being able to login
> remotely to the live CD system using the o
> No objection, I think we'll just take these, though I wonder whether the
> live CD layout will actually agree with SUNWrpm to the point that it'll
> do anything useful.
Remember that SUNWrpm only includes rpm2cpio(1) - the primary reason I
had for including it is to be able to use rpm2cpio and e
> Hmm... Not sure where you got this list from, but only SUNWimagick
> seems to depend on glib/gtk, and looking at snv_72, it now links to
> glib2 and gtk2.
>
> I recommend taking SUNWGlib and SUNWGtk[ur] off the list.
SUNWGlib and SUNWGtk[ur] are listed as dependencies in SUNWimagick's
depend fil
> Size is not the issue for JRE. At present Swing/AWT still
> links with Motif libraries on Solaris as opposed to Gtk
> on Linux.
>
> Since Solaris Motif is closed and non-redistributable this
> makes a Java GUI non-functional on Indiana. The solution
> is for libawt and friends to eith
>> SUNWslprSLP, (Root)
>> SUNWslpuSLP, (Usr)
>
>> SUNWncarSolaris Network Cache and Accelerator (Root)
>> SUNWncauSolaris Network Cache and Accelerator (Usr)
>
>> SUNWpppdSolaris PPP Device Drivers
>> SUNWpppdr Solaris PPP configuration files
>> SUNWppp
> What about folks whose intent is to install from a repository available
> via kerberized nfs?
If the repository was being made available that way, then perhaps it
would be needed. However if a HTTP-based approach is used, such as
REST, then it's not clear if this package is useful.
dsc
>>> SUNWbtool CCS tools bundled with SunOS
>
> This package contains things like elfdump, nm, strip etc. Not good
> to leave out.
But those tools are useful for developers and we've definitely not been
including developer tools on the Live CD. We could do this but we're
talking potentia
> These tools are very basic functionality at the core of any *nix or
> look-alike OS. This is not only for developers but also for users
> trying to figure a problem or an admin asking a user to perform
> a step if he faces a problem. For eg. how do we look at exported
> symbols without
Dave,
> I've posted yet another updated to the package list on the announcements
> page [1], including diffs from the most recent version. The changes can
> be summarized as:
>
> - Remove a few things which are Solaris-product-specific
> - Remove some things which are developer-specific and proba
> I've posted yet another updated to the package list on the announcements
> page [1], including diffs from the most recent version. The changes can
> be summarized as:
> [1]
> http://www.opensolaris.org/os/project/caiman/Slim_Install/slim_annoucememts/
By the way, SUNWdtcor is listed probably f
> In general touching /etc/profile is not required, how the default
> PATH in Solaris is
> too limited to be useful for desktop users. PATH should contain
> things like, /usr/sbin,
> /usr/ccs/bin, /usr/sfw/bin, /usr/X11/bin, /usr/gnu/bin for a good out
> of the box experience
> on the LiveC
> /bin/sh -c 'print ${.sh.version}'
> /bin/sh: bad substitution
>
> I hoped Indiana would improve things and deliver the ksh 93 as
> /bin/sh, but no, it is just the same bourne shell as in Solaris. No
> improvement. Indiana doesn't improve things for developers.
Actually I had hoped to explore rep
> Exactly. This project is behaving as far as I can tell exactly the
> way we expect projects to behave: creating prototypes, experimenting,
> and making decisions.
>
> When (and if) the project is ready to do so, I trust that it'll come
> for ARC review, and the rest of the community will be able
> If this were an actual ARC review, the attention signal you just heard
> would have been followed by news and other official information. ;-}
So noted. :-)
> I'd say that prepending (or even appending) /usr/gnu/bin likely
> doesn't make sense.
Well, appending makes no sense since as you point
> Distribution/opensolaris/install
> Distribution/opensolaris/livecd
In talking with Stephen and Glynn, I think we want to use the
Distribution classification for mostly triage and to recategorize bugs
out of there and into the appropriate place under the Development
classification.
How does that
> Author: ktung at ox
> Repository: /hg/caiman/distro_constructor
> Latest revision: 1433ef2f52df96a8d73e25d9b93976416eb047c7
> Total changesets: 1
> Log message:
> Explicitly specify SUNWslim-utils in the package list, since it will be
> removed
> from the slim_install cluster.
>
> Files:
>
Shawn,
> ksh93 is the only suitable replacement for /sbin/sh at the moment
> since it is the only one that has been fully tested for such a thing.
>
> If someone wants to do the work to guarantee backwards compatibility
> for /sbin/sh for another shell such as bash, etc. then more power to
> them.
> I believe the next version of Indiana will end your pain when it
> changes /bin/sh to ksh93.
Just to set expectations that although there is talk about replacing
/bin/sh with ksh93, there is no concrete plan yet to do so and I expect
in the next ISO prototype that is pushed out that /bin/sh will
> You are kidding, aren't you?
Actually, I'm not. It takes work on the part of a number of
individuals to make any change to OpenSolaris, such things don't happen
automatically just because of wishful thinking. If you're interested
in proposing something, I would recommend participating in the
O
>> Are there a set of modules from the "official" Indiana build that we can
>> make use of?
The build 75a xVM modules are currently in the official Indiana
repository, http://pkg.opensolaris.org. Here's a breakdown of the IPS
packages in question
pkg://opensolaris.org/SUNWcakrx at 0.5.11-0.75
> Thanks Dave ... I've got the SUNWipkg installed but am not having much luck
> with the
> install command you've mentioned:
>
> # pkg -R /usr/tmp install pkg://opensolaris.org/SUNWcakrx at 0.5.11-0.75
> '/usr/tmp' is not an install image
You need to setup a directory as an image by f
> Does someone need to file a bug against IPS about the pythonssl dependency
> issue so that it can be fixed in b129 ???
I've suggested to RE that we release note this issue for this build and
address it in build 130.
> I'm in the process of opening one now. Clay thinks the 2.6 simplejon pkg
> needs to be depended upon as well.
The latter was done in build 129 - it's just the SUNWpython26-pyopenssl
dependency that was not updated.
> We have seen a couple of instances during our testing that indicate that this
> could break upgrade. I had to manually update it on our AI server, for
> example, to see if we could go any further in the AI install.
Thanks - certainly the image-update issue needs to be fixed as the
work-around
Thanks to Danek, we now have a shiny new Bugzilla closed resolution
field: TRACKEDINBUGSTER. The intent of this is to mark bugs which have
a corresponding Bugster CR available.
Since tracking bugs via Bugster only makes sense for those components
whose fixes will be delivered through Nevada, this
1 - 100 of 113 matches
Mail list logo
