http://blog.gmane.org/gmane.os.solaris.opensolaris.indiana hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14377 <pre>For the past couple of years I have been a moderator for indiana-discuss. In my view, the usefulness of this list was eclipsed when Sun renamed the project known as "Indiana" got a formal distribution named OpenSolaris. Oracle's recent decision to discontinue the OpenSolaris distribution in favor of Oracle Solaris 11 Express (forgive me if I butchered the official name) further speaks to the notion that the indiana-discuss list has outlived its usefulness. As I write this message, there have been no messages to indiana-discuss in August. In that same time there have been 22 spam messages that were not caught by automatic spam detection, requiring manual action by a moderator to stop getting nag mail. July was a bit more active, with one thread asking where the MIA update to the OpenSolaris distro was, one unanswered plea for help, and three threads spawned by announcements by Alan Coopersmith. The spam to the moderators outnumbered these legitimate messages in July as well. http://mail.opensolaris.org/pipermail/indiana-discuss/ Given this, I propose that indiana-discuss-xZgeD5Kw2fzokhkdeNNY6A&lt; at &gt;public.gmane.org be retired. The archives should remain. Those interested in ongoing discussion of topics originally intended for indiana-discuss should be advised to subscribe to opensolaris-discuss-xZgeD5Kw2fzokhkdeNNY6A&lt; at &gt;public.gmane.org and/or the various distros that are based on OpenSolaris. If there is objection to this proposal, I will be supportive those wishing to keep it alive and will seek someone to take over my moderation role. </pre> Mike Gerdts 2010-08-26T00:48:51 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14374 <pre>Just when you thought you'd never see another one of these biweekly mails.... These changes in the X packages in Nevada build 145 will need updates to the IPS distro-import package definitions for those packages. (This is an early heads up - the list is subject to change if any issues are found in pre-integration testing.) As usual, this only lists the changes that need distro-import changes, the full list of X changes in these builds can be seen at: http://hub.opensolaris.org/bin/view/Community+Group+x_win/changelogs-nv_140#HBuild145 6939384 X delivered SMF manifests should be relocated to /lib/svc/manifest 144/i386/driver:graphics:nvidia currently contains: depend_path /var/svc/manifest/application/opengl/ogl-select.xml If pkg RFE 9739 is fixed before 145 closes, this should change to depend_fmri svc:/application/opengl/ogl-select otherwise, it should change to depend_path /lib/svc/manifest/application/opengl/ogl-select.xml The only other package I see that listed that depend_path in distro-import is x11/library/mesa, which is now delivered via X. (Hopefully all packages that use OpenGL libraries will have the right dependencies autodetected since the X package refactoring moved the service that creates the OpenGL links into the same package as the /usr/lib/libGL* -&gt; /var/run/opengl/* links. Since graphics/nvidia is a provider of OpenGL libraries instead of a consumer, I'm not sure if it has anything that will trigger this autodetection.) </pre> Alan Coopersmith 2010-07-21T01:10:46 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14372 <pre>[I know that for external users this isn't very useful while /dev is frozen, though at least one person outside Oracle has built our 144 repo so it is possible to start testing these now if you build them yourself. I could post the repo snapshot we delivered to build 144, but it was built on snv_142 so contains dependencies on ON &amp; SFW packages that aren't externally available, so wouldn't be installable.] Starting with build snv_144, the X consolidation has converted from building packages in SVR4 format (which the IPS team &amp; WOS RE then converted to IPS) to building directly in IPS format. At the same time, we have refactored our packages to better match functional groups, follow upstream source boundaries from the X11R7 modularization, and better allow sensible minimization. The archives of the OpenSolaris.org mailing lists xwin-discuss &amp; pkg-discuss can provide more insight into the decisions made there. (Of course, further changes are possible as we find out what works and what does not.) For the most part I have used the IPS package renaming support so that you should be automatically upgraded from the current package set you have installed to the appropriate replacements. However, in a few choices I was forced to choose between allowing minimization or handling upgrade automatically, and chose to allow minimization. There is an open RFE with the pkg(5) team to offer better support for this case, but until then you may find that some components you had previously installed need to be reinstalled after the upgrade. Specifically you may need to install these packages after upgrading to build 144 if you use the functionality they provide: pkg:/x11/server/xephyr pkg:/x11/server/xvfb pkg:/x11/server/xorg/driver/xorg-input-acecad pkg:/x11/server/xorg/driver/xorg-input-hotkey pkg:/x11/server/xorg/driver/xorg-input-synaptics pkg:/x11/server/xorg/driver/xorg-input-vmmouse pkg:/x11/server/xorg/driver/xorg-input-void The mouse &amp; keyboard drivers will be automatically installed, so you should be able to use the system until you install the other input drivers for more specialized systems. If you do not desire minimization but simply want to install every package from the X consolidation you can simply install our new group package: pkg:/consolidation/X/X-redistributable Additionally, for those building distributions such as Live CD's or install media, a new group package pkg:/x11/server/xorg/driver/xorg-video has been created that provides all the available video drivers for X. There are also effects on building the X consolidation - I will send a flag day to xwin-discuss soon with information on those. </pre> Alan Coopersmith 2010-07-16T01:14:18 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14370 <pre>These changes in the X packages in Nevada build 144 will need updates to the IPS distro-import package definitions for those packages. As usual, this only lists the changes that need distro-import changes, the full list of X changes in these builds can be seen at: http://hub.opensolaris.org/bin/view/Community+Group+x_win/changelogs-nv_140#HBuild144 6941932 X should be able to build IPS packages natively 6964006 X package boundaries are all wrong 6966504 lndir [PSARC/2010/219] 6967081 X package names need adjusting See http://cr.opensolaris.org/~alanc/xnv-ips/pkg-gate-v2/ for the changes I believe are necessary for the above set. 6963906 NVIDIA graphics driver support for OpenGL 4.0 [PSARC/2010/133] Information about the version bump &amp; driver aliases additions needed has already been sent to David. </pre> Alan Coopersmith 2010-07-09T22:02:16 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14360 <pre>Hi! After reading a topic dated from 2008 (http://opensolaris.org/jive/thread.jspa?threadID=50145&amp;tstart=0), I felt that by now there would probably be at least a 2D direct acceleration support for ATI cards. However, upon asking around at the IRC a while ago, I found that the current driver was actually software accelerated in nature, leading to poor performance while doing simple tasks such as dragging windows around, or watching videos. That being then and this being now, I decided to ask again at the IRC to see if any progress had been made. This time they directed me to either wait for a user called "alanc" to pop up in the IRC, or to post here to inquire about the state of support for ATI cards. I understand that ATI's driver is closed source, and that they have not ported it over to OpenSolaris themselves. Thanks in advance for any light you guys may be able to shed on the situation! </pre> Jonathan Chan 2010-06-27T02:46:06 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14349 <pre>Ok, this is not to start a flame war, just to hope for news/hints/grapevine, is there any hope to get 2010.06? At first I can understand 2010.03 is delayed to accommodate showstopper fixes, but with quite a few builds after b134 as of now, is it really a point to have something like b134a? what are the showstoppers exactly? Not that I actually wait for 2010.x but I am waiting the day /dev to be thawed.. Ivan. </pre> Ivan Wang 2010-06-18T16:48:55 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14348 <pre>I believe the only changes that should be needed to the IPS distro-import files for the X packages should be a version bump &amp; driver action update for the NVIDIA graphics driver package, which I've already forwarded the details for directly to David. As usual, this only lists the changes that need distro-import changes, the full list of X changes in these builds can be seen at: http://hub.opensolaris.org/bin/view/Community+Group+x_win/changelogs-nv_140#HBuild142 (In the former-X-package realm, the xscreensaver packages in JDS also got a version bump in 142 to the auspiciously/conveniently numbered version 5.11, but you should see those with the JDS consolidation changes.) </pre> Alan Coopersmith 2010-06-12T00:11:44 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14341 <pre>hello all, on a Sun X4150, i have os2009.06 (b111b) installed. Yesterday, i startrd an image-update to b134 (dev repo), and it is not finished after 10 hours! ------------------------------------------------------------ Install Phase 162016/162016 Update Phase 1590/1590 PHASE ITEMS Reading Existing Index 8/8 Indexing Packages 1431/1431 Optimizing Index... PHASE ITEMS Indexing Packages 1474/1474 PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 3931 root 520M 513M cpu3 40 0 10:55:01 12% pkg/1 ... me&lt; at &gt;antigone:~$ pfexec truss -p 3931 ioctl(4, ZFS_IOC_SNAPSHOT_LIST_NEXT, 0x08043480) = 0 ioctl(4, ZFS_IOC_SNAPSHOT_LIST_NEXT, 0x08043480) = 0 ioctl(4, ZFS_IOC_OBJSET_STATS, 0x08041FE0) Err#12 ENOMEM ioctl(4, ZFS_IOC_OBJSET_STATS, 0x08041FE0) = 0 ioctl(4, ZFS_IOC_OBJSET_STATS, 0x08044CD0) Err#12 ENOMEM ioctl(4, ZFS_IOC_OBJSET_STATS, 0x08044CD0) = 0 ioctl(4, ZFS_IOC_OBJSET_STATS, 0x08043060) = 0 ioctl(4, ZFS_IOC_OBJSET_STATS, 0x08043060) Err#12 ENOMEM ioctl(4, ZFS_IOC_OBJSET_STATS, 0x08043060) = 0 ... pfiles shows that 4 is: 4: S_IFCHR mode:0666 dev:299,0 ino:95420420 uid:0 gid:3 rdev:182,0 O_RDWR /devices/pseudo/zfs&lt; at &gt;0:zfs Anybody can help? thanks in advance, gerard PS: the disk isn't full: me&lt; at &gt;antigone:~$ zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT rpool 67.5G 55.1G 12.4G 81% ONLINE - me&lt; at &gt;antigone:~$ beadm list BE Active Mountpoint Space Policy Created </pre> solarg 2010-06-02T05:11:43 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14338 <pre>As we know, the last public update of dev repo was build 134, which was published almost three month ago. Assuming that OpenSolaris still plans (is it?) to follow half year release schedule, the period of dev repo freezing is now comparable to the release period itself. This makes one wonder whether current dev repo release policy makes any sense for general OpenSolaris user base, those outside Oracle inner circle. While discussions and threads like "problems with snv_14x" pop up here and there, it is frustrating for global OpenSolaris community, since those builds are not available from the repo anyway (unless someone likes always to use sources as a starting point). While those within Oracle refer to secrecy and non disclosure issues regarding the upcoming release dates, there is no reason to keep in secret the policy regarding dev repo updates. If the plan is to release updates for some time, and then to freeze the repo for more than a half of release period - let it be clearly specified somewhere for the benefit of OpenSolaris community (or is it clearly stated somewhere already?). This way everyone will know what to expect and it will help avoiding unnecessary frustrations. </pre> Hillel Lubman 2010-05-30T17:40:51 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14336 <pre>I'm sure we'll have users that will want to use these new open source Scientific, Technical, and Medical publishing fonts: http://www.aip.org/press_release/stixfonts_v1.0_released.html and there's already several other requested open source font packages filed in bugzilla/bugster - but since we're just packaging files and not making any change or adding any value with our process overhead, should we be driving fonts like this towards /contrib instead of trying to add to a core consolidation like X or G11n? Obviously we have to have a core set of fonts distributed in the WOS, but not all of them. </pre> Alan Coopersmith 2010-05-30T05:45:23 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14333 <pre>The only changes that should be needed to the IPS distro-import files for the X packages should be a couple of version bumps for: * 6902956 Fontconfig version 2.8.0 [PSARC/2010/162] pkg:/system/library/fontconfig pkg:/system/library/fontconfig/documentation * 6954535 Update Xorg from 1.7.6 to 1.7.7 pkg:/x11/server/xorg As usual, this only lists the changes that need distro-import changes, the full list of X changes in these builds can be seen at: http://hub.opensolaris.org/bin/view/Community+Group+x_win/changelogs-nv_140#HBuild141 </pre> Alan Coopersmith 2010-05-29T00:08:47 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14324 <pre>Will OpenSolaris support AMD Opterons? That is, anybody know of commits on Opensolaris source on the newer Opterons? http://www.theregister.co.uk/2010/05/27/oracle_spikes_opterons/ Looking at http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/hwdata/pci.ids it doesn't show. But the Intel Core i7's and Nehalem EX (7500's) seem to be supported, newer than the Opterons in the tree. Where else would the support appear in the tree? Thanks </pre> Amit Kulkarni 2010-05-27T21:11:32 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14306 <pre>No changes in the X packages in Nevada build 140 should need updates to the IPS distro-import package definitions for those packages. As usual, the full list of X changes in this build can be seen at: http://hub.opensolaris.org/bin/view/Community+Group+x_win/changelogs-nv_140#HBuild140 -alan- </pre> Alan Coopersmith 2010-05-18T15:03:36 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14304 <pre>Hi All, I am new to OpenSolaris and i am still learning. For studying purpose, I am trying to build the kernel from sources using b111b tree. All the steps completed as mentioned in the building procedure. But I am still not able to understand how to create a distribution? Can someone help me how to create distribution package of kernel after building procedure completed. Thanks! Regards, Adil </pre> Adil Mujeeb 2010-05-18T06:26:13 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14296 <pre>*** Apologies to all *** ... that I fell in Mr. "Dave Johnson"'s traps twice. Recently I didn't have much time for OpenSolaris. I did not back-check "Dave Johnson"'s claims sufficiently enough. Sorry! %martin bochnig On Tue, May 11, 2010 at 5:02 PM, Roland Mainz &lt;roland.mainz-QtDJSZoAcjhAfugRpC6u6w&lt; at &gt;public.gmane.org&gt; wrote: </pre> Martin Bochnig 2010-05-11T14:20:12 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14295 <pre>On Mon, May 10, 2010 at 3:15 PM, Dave Johnson &lt;dave.johnson.inquest-gM/Ye1E23mwN+BqQ9rBEUg&lt; at &gt;public.gmane.org&gt; wrote: [snip] Nice attempt, unfortunately (for you) the ARC emails are being archived. John Sonnenschein's original posting can be found at http://mail.opensolaris.org/pipermail/opensolaris-arc/2009-December/019530.html (and I and many others archive the emails at home, too) and differs a lot from the "proof" you've posted. The diff between his and your email looks like this: </pre> Roland Mainz 2010-05-11T14:02:13 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14270 <pre>Greetings I have to ask about next official OpenSolaris release. Could project leaders post ( like weekly based ) some status information ? There is no clear information where OpenSolaris now stands and how it progress. Personally this is important as i'm currently having a risk losing data with known zfs bugs ( old dev builds ) and waiting next official release to come out to get personal server back into full use. I do not like to start process to reinstall everything from scratch and invest temporary storage to that process... But if this is only way to get server back to use, have to reconsider what Operating System then use .... So could indiana project share some information about progress ? </pre> homerun 2010-05-10T09:44:04 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14259 <pre>It was noted, that delays in updating dev repo with most recent builds during a pending release are caused by concerns related to potential update to the release branch by some users, and QA focus: http://www.opensolaris.org/jive/message.jspa?messageID=478636#478636 May be it is possible to enable an alternative temporary and publicly available repository, which will contain most recent development builds while the release is still pending, so those who are not planning to use a release branch later can use the most up to date build without delays? Is it just a technical obstacle, or there are some bureaucratic reasons not to do so? Thanks. Hillel. </pre> Hillel Lubman 2010-05-06T20:48:55 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14246 <pre>A few days ago I wanted to update my MacBook Pro from b134 to b137 (from the internal repository) and I got an error like: pkg: unable to activate opensolaris-137 After asking some questions in #opensolaris (thanks for your help) I noticed that this is EFI related. Just for a test I booted back to my older b133 image and tried to reinstall b134 and I get the same error now: root&lt; at &gt;macbook:~# BE_PRINT_ERR=true pkg image-update DOWNLOAD PKGS FILES XFER (MB) Completed 670/670 10670/10670 230.2/230.2 be_get_uuid: failed to get uuid property from BE root dataset user properties. PHASE ACTIONS Removal Phase 4881/4881 Install Phase 5160/5160 Update Phase 18959/18959 set_bootfs: failed to set bootfs property for pool rpool: property 'bootfs' not supported on EFI labeled devices be_activate: failed to set bootfs pool property for rpool/ROOT/opensolaris-135 pkg: unable to activate opensolaris-135 What confuses me is that the update from b133 to b134 obviously worked before--because I have a b134 image--but it doesn't now. I can't think of anything I did that changed anything on the disk or the partition table, whatever that could be. Or is this because I tried to install b137 and that changed something? </pre> Christian Thalinger 2010-05-01T08:58:11 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14245 <pre>No changes in the core X packages in Nevada build 139 will need updates to the IPS distro-import package definitions for those packages. However, John Martin has provided updates to the nvidia-graphics manifest which have been forwarded to David already. As usual, this only lists the changes that need distro-import changes, the full list of X changes in these builds can be seen at: http://hub.opensolaris.org/bin/view/Community+Group+x_win/changelogs-nv_130#HBuild139 </pre> Alan Coopersmith 2010-05-01T00:37:32 http://comments.gmane.org/gmane.os.solaris.opensolaris.indiana/14240 <pre>Dear All, Having enabled pam_list in /etc/pam.conf I can then happily control who can log on via ssh and that works fine. HOWEVER, once pam_list is included in /etc/pam.conf then console logins ALL fail with messages such as ******************************************************************************************** Apr 30 11:32:55 phoenix login: [ID 825731 auth.error] dlsym failed pam_sm_authenticate: error ld.so.1: login: fatal: pam_sm_authenticate: can't find symbol ******************************************************************************************** Google locates various other people reporting this sort of problem, but I can't spot any obvious solutions. To provide a bit extra input, I tried running nm on a selection of pam libraries. **************************************************************************************** root&lt; at &gt;phoenix:/var/log# nm /usr/lib/security/pam_dial_auth.so.1 | grep pam_sm_authenticate [58] | 2524| 1172|FUNC |GLOB |0 |12 |pam_sm_authenticate root&lt; at &gt;phoenix:/var/log# *************************************************************************************** so that one has a pam_sm_authenticate symbol, HOWEVER ************************************************************************************** root&lt; at &gt;phoenix:/var/log# nm /usr/lib/security/pam_list.so.1 | grep pam_sm_authenticate root&lt; at &gt;phoenix:/var/log# ************************************************************************************** show it does indeed NOT have a pam_sm_authenticate So.... 1/. on the one, hand, is pam_list broken in some sense? 2/. alternatively, being pragmatic, can I do anything to stop console logons trying to do whatever they do do that hits this bug... As I say, pam_list is obviously NOT totally broken as after adding the appropriate line into /etc/pam.conf then it does do its job fine for ssh type logons, allowing in the users I want and blocking others.... Thanks, Dave Price </pre> Dave Price 2010-04-30T11:10:53 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.solaris.opensolaris.indiana