More ksh93 builtins
Milan Jurik wrote: Still GNU ls is in system. Why? Because users want it and removing it from the system serves no one. -- -Alan Coopersmith- alan.coopersmith at sun.com Oracle Solaris Platform Engineering: X Window System
More ksh93 builtins
Milan Jurik wrote: You ignored the rest of the e-mail, skipping arguments. Yes, you can consider those arguments as non-sense but it is fair to say it openly in discussion. Because it's still pointless. No amount of arguments will add up to making it worthwhile or likely that /usr/gnu/bin/ls is removed from the system and the debate about the PATH order has happened elsewhere. If you want to waste your time arguing, that's your choice, but it's not going to change anything. -- -Alan Coopersmith- alan.coopersmith at sun.com Oracle Solaris Platform Engineering: X Window System
[shell-discuss] More ksh93 builtins
John Plocher wrote: On Tue, Mar 23, 2010 at 4:47 PM, Darren Reed Darren.Reed at sun.com wrote: Enjoy (the fact that S10 does not have bash or /usr/gnu or ...). I don't see that line in Darren's original mail - did you add that commentary? It's incorrect if so, since bash was added in Solaris 8 with tcsh and gzip, and the other first round of open source software our customers had been begging us for years to add. This process is not new - it's over a decade old. -- -Alan Coopersmith-alan.coopersmith at oracle.com Oracle Solaris Platform Engineering: X Window System
More ksh93 builtins
Milan Jurik wrote: Alan Coopersmith p??e v p? 19. 03. 2010 v 16:39 -0700: Garrett D'Amore wrote: I'm also of the opinion that it is a mistake to sacrifice familiarity for our paying Solaris 10 customers in favor of familiarity for people coming from Linux. But clearly all our paying Solaris 10 customers already have dotfiles to set $PATH, given how useless the default Solaris 10 $PATH is. I would be very carefull with claiming all our paying Solaris 10 customers... Okay, make it Any Solaris 10 customer (paying or not) who actually wants to use the system - given the lack of some basic commands in the default path, such as /usr/sbin/ping or /usr/ccs/bin/make, the Solaris 10 default PATH shows we've long required customers to change the default PATH to actually make the system usable to either sysadmins or developers. -- -Alan Coopersmith-alan.coopersmith at oracle.com Oracle Solaris Platform Engineering: X Window System
More ksh93 builtins
Darren Reed wrote: What the default path, in /etc/default and elsewhere, really impact are things like: - install scripts (that don't use ~/.foo) - how scripts run remotely when ~/.foo isn't read - at/cron jobs - other uses of $SHELL where ~/.foo isn't read And notably, that path hasn't changed. The /usr/gnu/bin change was only in the default .profile installed in new user accounts. -- -Alan Coopersmith- alan.coopersmith at sun.com Oracle Solaris Platform Engineering: X Window System
More ksh93 builtins
[Removed the case id, since this is off-topic for the case which isn't currently on the table for discussion anyway.] Garrett D'Amore wrote: I'm also of the opinion that it is a mistake to sacrifice familiarity for our paying Solaris 10 customers in favor of familiarity for people coming from Linux. But clearly all our paying Solaris 10 customers already have dotfiles to set $PATH, given how useless the default Solaris 10 $PATH is. They get familiarity by continuing to use those - the default PATH with /usr/gnu/bin first only affects those setting up new accounts who don't have existing Solaris .dotfiles, which seems like a very reasonable compromise. Also rememeber the PATH default is set only in text files which are trivially editable by users with experience from previous Solaris releases - it's not baked into the kernel. Which group do you think contributes more towards the $$ that pay our salaries? Sounds like an invalid question for PSARC-ext shell-discuss at opensolaris.org. -- -Alan Coopersmith-alan.coopersmith at oracle.com Oracle Solaris Platform Engineering: X Window System
Locale Services Library [LSARC/2010/094 FastTrack timeout 03/25/2010]
David Lim wrote: Is there a particular reason why Python 2.6 is used and not the later Python 3.1? Python 3.1 has not yet gone through ARC review, nor been delivered in Solaris or OpenSolaris, so isn't available for use yet. -- -Alan Coopersmith-alan.coopersmith at oracle.com Oracle Solaris Platform Engineering: X Window System
More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
Garrett D'Amore - sun microsystems wrote: Compatibility between ksh93 built in utility implementation and GNU coreutils implementation: Should a future ARC case will add new features to the GNU coreutils utilities the project team will update the corresponding ksh93 built in utility. Should this not be possible the ksh93 project team will remove the mapping. So this constrains all future GNU coreutils update cases to coordinate with the ksh93 builtins, right? Have those responsible for the GNU coreutils agreed to this constraint? Should this be expressed as an ARC contract for cross-consolidation agreement of Volatile interfaces? -- -Alan Coopersmith- alan.coopersmith at sun.com Oracle Solaris Platform Engineering: X Window System
More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
Jennifer Pioch wrote: Why? The majority in the discussion already said that this is not a bug in ksh93. Why should this case wait for something which is not a bug? A majority of people who don't know what profile shells are or how they are used is not relevant - even if they did, bugs are not decided by democratic vote of the masses, but by review of the experts in that area. -- -Alan Coopersmith-alan.coopersmith at oracle.com Oracle Solaris Platform Engineering: X Window System
More ksh93 builtins [PSARC/2010/095 FastTrack timeout 03/25/2010]
Garrett D'Amore wrote: On 03/18/10 08:58 AM, Alan Coopersmith wrote: Garrett D'Amore - sun microsystems wrote: Compatibility between ksh93 built in utility implementation and GNU coreutils implementation: Should a future ARC case will add new features to the GNU coreutils utilities the project team will update the corresponding ksh93 built in utility. Should this not be possible the ksh93 project team will remove the mapping. So this constrains all future GNU coreutils update cases to coordinate with the ksh93 builtins, right? Have those responsible for the GNU coreutils agreed to this constraint? Should this be expressed as an ARC contract for cross-consolidation agreement of Volatile interfaces? The ksh93 versions adhere to the public interfaces from the GNU versions. If they change the semantics, then it will require some extra work, but I'm not sure that a contract properly captures this. Even just having a note added to the SFW metadata file would be better than doing nothing, which goes back to the original question of whether those responsible for the GNU coreutils in SFW have agreed to this or even been made aware of it? -- -Alan Coopersmith-alan.coopersmith at oracle.com Oracle Solaris Platform Engineering: X Window System
libgdata [PSARC/2010/092 timeout 03/24/2010]
Sebastien Roy wrote: I will list Desktop/library/libgdata as its ips name in interface table. Does this imply that there is in fact not a libgdata-devel? There should not be, as the IPS convention is to include the -devel bits in the main package (and eventually to use facets to allow controlling whether to install those bits or not). -- -Alan Coopersmith-alan.coopersmith at oracle.com Oracle Solaris Platform Engineering: X Window System
Locale Services Library [LSARC/2010/094 FastTrack timeout 03/25/2010]
Nicolas Williams wrote: There's a number of projects that could greatly benefit from a C library (even if that were implemented using IPC to a python daemon that uses your python library). For example, ssh(1) and sshd(1M) (which currently execute and parse the output of locale -a). But also C implementations of a growing number of Internet protocols that provide globalization features. And while admittedly not this project, add gdm to the list for this informal advice to the project team for a follow-on project, if the resulting API will allow gdm to get a list of locales without mapping (and leaving mapped) almost a hundred locale .so files, as noted in CR 6920064. -- -Alan Coopersmith-alan.coopersmith at oracle.com Oracle Solaris Platform Engineering: X Window System
libgdata [PSARC/2010/092 timeout 03/24/2010]
John Fischer wrote: The desktop team as a matter of routine supplies the symbolic link as well as 64-bit libraries. Actually, a recent survey of the OS libraries showed that most of the ones missing 64-bit versions were delivered by the desktop team, so it's unfortunately not as routine as it should be. -- -Alan Coopersmith-alan.coopersmith at oracle.com Oracle Solaris Platform Engineering: X Window System
EOL of the MySQL 5.0 from OpenSolaris [PSARC/2010/087 FastTrack timeout 03/18/2010]
sunanda menon wrote: The plan is to remove the same by OSOL.2010.10( I assume that's the one after OSOL.2010.03) There is no name nor schedule yet for the release after 2010.03. -- -Alan Coopersmith- alan.coopersmith at sun.com Oracle Solaris Platform Engineering: X Window System
open source sed [PSARC/2010/086 FastTrack timeout 03/17/2010]
Peter Tribble wrote: On Thu, Mar 11, 2010 at 12:28 AM, Garrett D'Amore - sun microsystems gd78059 at sac.sfbay.sun.com wrote: Template Version: @(#)sac_nextcase 1.69 02/15/10 SMI This information is Copyright 2010 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: open source sed 1.2. Name of Document Author/Supplier: Author: Olga Kryzhanovska 1.3 Date of This Document: 10 March, 2010 4. Technical Description I'm sponsoring this fast-track request on behalf of the POSIX utility community and shell project. Nit: Is there such a community? Perhaps they're just a community of people and not a formal Community Group? -- -Alan Coopersmith- alan.coopersmith at sun.com Oracle Solaris Platform Engineering: X Window System
[shell-discuss] open source sed [PSARC/2010/086 FastTrack timeout 03/17/2010]
? wrote: Which purpose has this option (I can't look at the GPL code without getting tainted by the GPL): The viral nature of the GPL only applies to copying code, it can't infect humans (unless you have a perfect memory and are likely to retype the code you saw directly into your code base, effectively copying it). That's off topic for this ARC review though, so further discussion should move off the PSARC-ext list. -- -Alan Coopersmith- alan.coopersmith at sun.com Oracle Solaris Platform Engineering: X Window System
Removing MySQL 4.0 from OpenSolaris [PSARC/2010/088 FastTrack timeout 03/18/2010]
Brian Utterback wrote: On 03/11/10 11:48, Andrew Gabriel wrote: This seems like two separate things, which need two different bindings (and would normally be two separate cases). EOL notification and interface reclassification in Solaris 10 would be a patch binding. EOL removal in Solaris Next would be a minor binding (feature removal is not eligible for patch binding). Is this what you mean? The project team thinks of this as one action, hence the single proposal. We can split this into to cases you that is desired. EOF's (removing a feature from a product, as you're doing here) are often done as one case, but with different release bindings for the two phases, as Andrew described. -- -Alan Coopersmith- alan.coopersmith at sun.com Oracle Solaris Platform Engineering: X Window System
Timer restat for 2010/067 Interim modernization updates
Joerg Schilling wrote: From my understanding, a case related to the changes made in Indiana should be in the open. Unfortunately, the case covered a broad range of changes, including why things were not included in OpenSolaris due to legal encumberments, and could not be made fully open as presented. (It might have been possible to split into a series of fasttracks, some open and some closed, but then the ARC would likely ask for an umbrella case like this one to explain how it all fits together and the overall project plan, and we'd be back where we are now.) At the review, the project team said they were considering what materials they can make open, but that's work that's not yet done. (BTW, most ARC members aren't seeing this mail since they're put on the other lists that PSARC-ext expands to - only the external participants are on opensolaris-arc - I just joined after seeing the cc's elsewhere indicated a conversation was happening. Mailing opensolaris-arc is mostly just preaching to the choir while the meeting is happening next door.) -- -Alan Coopersmith- alan.coopersmith at sun.com Oracle Solaris Platform Engineering: X Window System
opensolaris arc mailing lists (was: Timer restat for 2010/067 Interim modernization updates)
Cyril Plisko wrote: Hm, you mean OpenSolaris ARC members are not subscribed to opensolaris-arc list ? That sounds ... unnatural ... Yes, that's the somewhat confusing the way the lists were set up. The internal members were on either the LSARC or PSARC mailing lists already. When OpenSolaris opened up the ARC process, the opensolaris-arc list was added for external members to subscribe to, and new lists PSARC-ext and LSARC-ext were created for review of open PSARC LSARC cases. PSARC-ext sends to the internal PSARC list and the external opensolaris-arc list, and LSARC-ext send to the internal LSARC list and the external opensolaris-arc list (though that should be going away as LSARC merges into PSARC). opensolaris-arc was really intended to be just a distribution list to expand from PSARC-ext LSARC-ext, with all mail being sent via one of those addresses to hit both sets of participants. Mail like this that's not related to a specific case should be going to arc-discuss instead. -- -Alan Coopersmith- alan.coopersmith at sun.com Oracle Solaris Platform Engineering: X Window System
Timer restat for 2010/067 Interim modernization updates
Joerg Schilling wrote: But there was no permission from the ARC to do do the change with the shell How would you know what the ARC gave permission for in a case whose details are unfortunately still private? -- -Alan Coopersmith- alan.coopersmith at sun.com Oracle Solaris Platform Engineering: X Window System
Add Text Mode UI and Common Library to Device Driver Utility [PSARC/2009/602 FastTrack timeout 03/05/2010]
Bill Yan wrote: Has the project team been in contact with the pkg team to ensure that drivers installed using this tool won't be automatically removed from their installed locations during pkg image-update? If SVR4 packages are added and their files are orthogonal to IPS packages, then IPS will leave those files alone. DDU will use the pkg command to install IPS packages. Actually, SVR4 package files will be moved to lost+found by IPS image-update in some cases - this has bitten users with the SVR4 installed NVIDIA driver on a number of occasions, but I believe that's considered a bug in IPS, not a part of it's architectural design. -- -Alan Coopersmith- alan.coopersmith at sun.com Oracle Solaris Platform Engineering: X Window System
Timer restat for 2010/067 Interim modernization updates
Mark Martin wrote: The really fun fact is that there's an attribution to an external developer in the commit log. If you look at the on-ips-dev hg repo or mailing list archives, you'll see Rich did an amazing amount of work on this project. The ARC case only covered the changes that the OpenSolaris distro used to make to ON during the SVR4-IPS transition (things like the pkg equivalent of mv /usr/bin/sh /usr/has/bin/sh ; ln -s ksh93 /usr/bin/sh), since they can't do that when they get IPS packages directly from ON, and that was a small part of the overall changes putback to ON. -- -Alan Coopersmith- alan.coopersmith at sun.com Oracle Solaris Platform Engineering: X Window System
Timer restat for 2010/067 Interim modernization updates
Alan Coopersmith wrote: The ARC case only covered the changes that the OpenSolaris distro used to make to ON during the SVR4-IPS transition (things like the pkg equivalent of mv /usr/bin/sh /usr/has/bin/sh ; ln -s ksh93 /usr/bin/sh), since they can't do that when they get IPS packages directly from ON, and that was a small part of the overall changes putback to ON. -- -Alan Coopersmith- alan.coopersmith at sun.com Oracle Solaris Platform Engineering: X Window System
RealTek RTL8192SE Series WiFi Device Driver (PSARC/2010/077 Self Review)
Cyril Plisko wrote: On Tue, Mar 2, 2010 at 8:24 AM, Frank Che Frank.Che at sun.com wrote: |+---+---| | SUNWrtl819x| Committed | Package name | ++ Are there any policy changes in package naming (now that grand package rename is behind us) ? Effectively SUNW* names are Obsolete, and will not be allowed to integrate to ON in Nevada, since package renaming is landing there with the ON IPS conversion today. ARC is supposed to be managing the namespace for the new package names, but the case to formally introduce those hasn't been brought to ARC yet. -- -Alan Coopersmith- alan.coopersmith at sun.com Oracle Solaris Platform Engineering: X Window System
Timer restat for 2010/067 Interim modernization updates
John Plocher wrote: On Tue, Mar 2, 2010 at 1:43 PM, Sebastien Roy Sebastien.Roy at sun.com wrote: I don't believe that the materials as currently written can be made available. A point could be made that this case (and the associated project's deliverables) are not appropriate for inclusion in OPENsolaris, Strangely, most of its immediate deliverables are already in the distro named OpenSolaris, and the case is about integrating them back into the shared source base as the OpenSolaris distro will no longer be able to make those changes during the SVR4-IPS package transformation process once ON is building and delivering only IPS packages. Unfortunately, the case, like the ON IPS changes, straddles the open/closed boundary. -- -Alan Coopersmith- alan.coopersmith at sun.com Oracle Solaris Platform Engineering: X Window System
Opinion for PSARC review: PSARC/2008/532 NWAM Phase 1
Nicolas Williams wrote: 5. Futures A substantial amount of the discussion centered on issues that the project team considers to be items for future work, including servers, automated installers, VLANs, and NTP. The project team explained that there are still more phases coming, and that this one, like the previous phase, addresses lower-end users, so these concerns are out of scope for this project. The ARC members agreed with this explanation. An important distinction to note is that the Nevada instal- lation (including Jumpstart) does not enable NWAM by default. The only installer that enables it by default is the new OpenSolaris Caiman. Er, Nevada installation, JumpStart? Isn't Nevada (SXCE/SXDE and builds between releases thereof) dead? Nevada is the code name for the development branch of Solaris. It is alive and well - it's just the SVR4 packaged version of it (SXCE), and the related installers that are dead. Nevada builds 131 and later are only being made in IPS packaged versions. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
[xwin-discuss] GLUT [LSARC/2010/016 FastTrack timeout 01/21/2010]
Alan Coopersmith wrote: I am sponsoring this fasttrack for Stefan Teleman, and have set the timeout for a week from now, next Thursday, January 21. Since this case has received its +1 and no other comments during the timeout, it is now closed approved. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Command Assistant 2.0 [PSARC/2010/021 FastTrack timeout 01/21/2010]
Suresh Chandrasekharan wrote: Solaris Package Support -- Lists the package name (with dependent packages) to be installed for having for a given command. Very useful in svr4 system where such a feature does not exist. Does this deal with IPS having different package names from SVR4, including a completely new set coming soon (possibly for 2010.03)? -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
PSARC/2009/415 Bitmapped Console [Fasttrack timeout 01/22/2010]
Jan Setje-Eilers wrote: We do know what it does. Re-design is perhaps a stronger term than was appropriate here. Enrico was collapsing what were originally two daemons into one yesterday. He was primarily offering that he'd be happy to make additional changes if you had some smart ideas about how to deal with xsvc without running as root. At least from our experience with Xorg, you will need full privileges (uid 0) for both /dev/xsvc and the sysi86 call to change the IOPL. You may be able to drop some privileges after you've done that (Xorg can't since it has to be able to unwind and redo those calls again later). -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
GLUT [LSARC/2010/016 FastTrack timeout 01/21/2010]
I am sponsoring this fasttrack for Stefan Teleman, and have set the timeout for a week from now, next Thursday, January 21. The case materials directory includes an additional document, glut-appendix-1.txt with a list of the functions in the GLUT API. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2010 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: GLUT 1.2. Name of Document Author/Supplier: Author: Calin Teleman 1.3 Date of This Document: 14 January, 2010 4. Technical Description Introducing GLUT [ The OpenGL Utility Toolkit ] with X11 in Solaris Stefan Teleman stefan.teleman at sun.com 7 January 2010 1. Summary and Motivation GLUT [ The OpenGL Utility Toolkit ] [0] is a collection of functions providing a standardized access to a windowing system and to various input devices, in a platform-independent manner, and within an OpenGL [1] Context. The main purpose of GLUT is the avoidance of clobbering the OpenGL namespace with device, platform and operating-system specific functions. This platform independence comes at the expense of full device interaction features availability, and some loss of programming flexibility. From the FreeGLUT page: GLUT (and hence freeglut) allows the user to create and manage windows containing OpenGL contexts on a wide range of platforms and also read the mouse, keyboard and joystick functions. GLUT also provides general-purpose APIs simplifying some standard OpenGL programming idioms. Absent these GLUT APIs, these idioms would have had to be duplicated by the application programmer, for every OpenGL application. GLUT was originally developed and maintained by Mark Kilgard at SGI, under a very restrictive license. The last release from SGI was GLUT 3.7, in August 1998. Due to the licensing restrictions imposed by the canonical GLUT 3.7 license, and to the fact that it has not had a canonical upgrade release since August 1998, the SGI GLUT releases are not being considered for integration, and will not be discussed further. The GLUT API had been frozen at Version 3 since August 1998, and the GLUT releases have been frozen at Version 3.7. According to the OpenGL GLUT information page: [0] The current [ GLUT ] version is 3.7. Additional releases of the library are not anticipated. The current version of the GLUT API is 3. The current source code distribution is GLUT 3.7. The FreeGLUT Project [2] is a compatible replacement for the GLUT API V3 [ SGI GLUT 3.7 ], and is released under the MIT/X Consortium License. The FreeGLUT Project has extended and upgraded the SGI GLUT API version to Version 4. [4] The GLUT API Version 4 is a fully backwards compatible superset of Version 3 of the SGI GLUT API. The latest release from the FreeGLUT project is Version 2.6.0, and implements the GLUT API Version 4. For the purposes of this document, the term GLUT and FreeGLUT are used interchangeably, and refer to the canonical releases from the FreeGLUT project. This Case seeks Micro/Patch binding. 2. Programmatic Facilities The SGI [ Version 3 ] GLUT API and the FreeGLUT [ Version 4 ] API are documented in detail at [3] and [4]. A complete list of all the public interfaces exported by GLUT is provided in Appendix 1 in the Case Materials. Version 4 of the GLUT API provides a Standard API, available via the freeglut_std.h header file, and an Extensions API, available via the freeglut_ext.h header file. Access to the Standard GLUT API is provided by the glut.h header file. Access to the Standard And Extensions API is provided by the freeglut.h header file. The current GLUT API depends on the X11 Display structure. It has not yet been ported to XCB. [5] [6] 3. Interface Considerations GLUT imports interfaces from OpenGL [ libGL.so.1 and libGLU.so.1 ]. This is an explicit dependency: internal GLUT header files explicitly include GL/gl.h and GL/glu.h. GLUT does not specify a lower bound OpenGL API Version. FreeGLUT compiles cleanly with OpenGL Version 1.5. Additionally, GLUT imports interfaces from the following X libraries: - libX11.so.4 - libXext.so.0 - libXi.so.5 - libXxf86vm.so.1 GLUT exports C and [ identical ] C++ interfaces. The GLUT API Version 4
PSARC/2009/688 Human readable and extensible ld mapfile syntax
Garrett D'Amore wrote: James Carlson wrote: Garrett D'Amore wrote: Btw, I'm of the mind that it may be questionable to retain the old v1 mapfile syntax for very long. As indicated, not many people are using it, and we really shouldn't have to carry around baggage ~forever. I don't think the mapfile syntax was ever officially part of our source compatibility story. :-) I think that's a step too far. Yes, they're Committed interfaces and, no, it would not be good to have them go away. But wouldn't a tool to convert them answer the requirement for Committed support? I don't think the specific compiler command lines are part of that Committed interface, but perhaps I'm wrong. And I think I'd propose marking them Obsolete (at least) as part of this. That would complicate life for teams and projects trying to support older Solaris releases and Solaris next from the same source tree. I know some open source projects (including older releases of X and current releases of Mesa) have some level of support for SVR4 linker mapfiles for symbol visibility. (Current releases of X upstream have mostly migrated to using source code annotations for that, though they're sadly non-standard (gcc __attribute__(visibility), Sun cc __hidden __global keywords).) Any project to remove support for V1 mapfiles would have to update spec2map or properly obsolete it and fix every gate/product still using it. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Basic Network Privilege [PSARC/2009/685 FastTrack timeout 01/01/2010]
Peter Memishian wrote: I could see doing this on a subset of well-controlled applications, but what happens when a customer using this facility wants some Sun-supported application that happens to use loopback inet IPC to work? Are we going to change the code to accommodate their need, or tell them they're off the reservation? How would this be any different than if they tried removing other basic privileges, like the ability to fork() or exec(), from apps that really needed it? If customers break their system, it's broken. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Basic Network Privilege [PSARC/2009/685 FastTrack timeout 01/01/2010]
John Plocher wrote: What is the basic use case for this priv? I assumed it was to let setuid programs have one more thing they could give up, to reduce the number of things an exploit could do if you did find a security hole in them that allowed running arbitrary code, like most of the rest of the basic privileges. On Wed, Dec 23, 2009 at 2:34 PM, Alan Coopersmith Alan.Coopersmith at sun.com wrote: How would this be any different than if they tried removing other basic privileges, like the ability to fork() or exec(), from apps that really needed it? If customers break their system, it's broken. I think the difference is that for those, the set of system middleware we provide doesn't silently rely on them for proper operation; Just various non-obvious functions in libc(). (Do you think most programmers realize wordexp(), pututxline() or grantpt() call fork+exec?) -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Serial Port Console Redirection [PSARC/2009/684 FastTrack timeout 12/26/2009]
Garrett D'Amore wrote: I think it will be different for the different builds, but I'm not sure. I don't think this case is changing *that* (the default value being different between OpenSolaris and Nevada). That said, it may soon be moot as SXCE is supposed to be stopping soon. Part of the ON-IPS project currently underway is merging the OpenSolaris customizations to ON back into the main ON Nevada gate, since after they're done there will be just one Nevada build train, distributed as IPS packages in the style of OpenSolaris. You can see this in their current project gate on hg.opensolaris.org. (Exact schedule and details of that integration are TBD at the moment, but that's not this case.) -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
PSARC/2009/688 Human readable and extensible ld mapfile syntax
This all looks good to me. The one thing I wonder about changing:
By default, the stack has READ, WRITE, and EXECUTE permissions. The EXECUTE
setting exists for historical reasons. It is rarely if ever needed and is
generally considered to be a potential security risk. Removing EXECUTE
permission from the stack is a recommended practice:
STACK {
FLAGS -= EXECUTE;
};
Is there any reason to not just say If you're using a version 2 mapfile,
stack is non-executable by default, and you have to explicitly add it in
the very few cases it's needed ?
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
X Input Extension version 2.0 (XI2) [PSARC/2009/678 Self Review]
I am sponsoring this case for myself and closing it as approved automatic as it simply tracks the community addition of new protocol requests events to the existing Input extension to the X protocol, and the corresponding API additions to the libXi library. This case requests a Micro/Patch binding. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: X Input Extension version 2.0 (XI2) 1.2. Name of Document Author/Supplier: Author: Alan Coopersmith 1.3 Date of This Document: 14 December, 2009 4. Technical Description This case updates the definition of the X Input Extension (XI) protocol used in Solaris OpenSolaris from version 1.5 to version 2.0 of the spec from the X.Org Foundation. The introduction to the XI2 spec describes the changes as: The X Input Extension version 2.0 (XI2) is the second major release of the X Input Extension. XI2 provides a number of enhancements over version 1.5, including: - use of XGE and GenericEvents. GenericEvents are of flexible length with a minimum length of 32 bytes. - explicit device hierarchy of master and slave devices. See Section 4. - use of multiple independent master devices (Multi-Poiner X or MPX). - the ability for devices to change capabilities at runtime. - raw device events XI2's intent is to replace both core input processing and prior versions of the X Input Extension. Historically, the majority of applications employed the core protocol requests and events to handle user input. The core protocol does not provide information about which device generated the event. The X Input Extension version up to 1.5 requires the differentiation between core and extended devices. Extended devices may not be core devices and thus cannot be used on applications employing the core protocol. XI2 addresses both of these issues by enabling devices to be both extended and core devices and providing device information in each event (with the exception of core events). The full protocol spec is provided in the case materials as XI2proto.txt, and is available online at: http://www.x.org/releases/X11R7.5/doc/inputproto/XI2proto.txt It additionally updates the libXi client API from version 1.2 (reviewed in PSARC 2009/303) to version 1.3 to provide the matching support for the new protocol. The new API functions mirror these new requests - they are defined in the header file X11/extensions/XInput2.h and the man pages provided in the case materials. Support for Input version 2.0 in the Xorg server will be handled by the Xorg server 1.7 case to follow. Imported Interfaces: libXi.so.5 StandardPSARC 1992/172 X11/extensions/XInput.h Standard and Xinput extension protocol StandardPSARC 2009/303 Exported Interfaces: libXi.so.5 version SUNW_1.4 Committed [1] including all API's listed above X11/extensions/XInput2.h Committed [1] Xinput extension protocol version 2.0 Committed [2] References in case materials directory: [1] API man pages [2] XI2proto.txt 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: X Consolidation / Desktop C-Team 6.5. ARC review type: Automatic 6.6. ARC Exposure: open
Xorg server 1.7 [PSARC/2009/679 Self Review]
I am sponsoring this case for the X11 Engineering Group. I am marking it as closed approved automatic as it simply tracks the community changes. This case requests a Minor Release Binding since it once again makes incompatible changes to API ABI for Xorg loadable modules, and removes support for several command line options, which even though declared with Volatile stability, would have to be carefully considered for a Micro/Patch release. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Xorg server 1.7 1.2. Name of Document Author/Supplier: Author: Alan Coopersmith 1.3 Date of This Document: 14 December, 2009 4. Technical Description This case updates the Xorg server (and the associated X servers based on its source base - Xephyr, Xvnc and /usr/bin/Xvfb) from version 1.6 (a standalone release, between X11R7.4 and X11R7.5, reviewed in PSARC 2009/292) to version 1.7 (which is part of X11R7.5). This release adds support for X Input Extension 2.0, including Multi-Pointer X support, using the protocol changes covered by PSARC 2009/678. Removed Interfaces -- Xservers built on the Xorg 1.7 code base will no longer support these command-line flags: +xkb/-xkb Enable/Disable the XKB extension -probeonly Causes the server to exit after the device probing stage. The XKB extension is always enabled now, and may not be disabled. (The Solaris Xorg delivery had a long-standing bug in which keymaps were not loaded properly without XKB, resulting in unusable keyboards, thus we don't expect any users are running Xorg with XKB disabled.) Loadable Module Interfaces: --- This release includes incompatible changes in several of the Xorg loadable module API/ABI's. The version numbers of the ABI's have had their major number incremented to reflect this, and modules reporting they require a different version number will not be loaded unless the -ignoreABI option is used. (Modules can also check ABI versions themselves, and choose which function variant to call or structure variant to access, based on the reported versions - this is the option used by nvidia's closed source driver for instance.) ABI versions in this release, compared to the previously shipped Xorg 1.6: ABI Name: 1.6: 1.7: ABI_ANSIC_VERSION0.4 0.4 ABI_VIDEODRV_VERSION 5.0 6.0 ABI_XINPUT_VERSION 4.0 7.0 ABI_EXTENSION_VERSION2.0 2.0 ABI_FONT_VERSION 0.6 0.6 (Major number increments represent incompatible change, minor number increments represent compatible additions. ABI numbers may increment multiple times during Xorg server minor version development cycles, to track changes for those following the head of the development stream.) The changes that resulted in these version number bumps include: - Changes needed to support X Input extension 2.0 (XI2), including: - Addition of labels to input device buttons valuators. - Increase of input deviceids from 8-bit to 16-bit ints. - Removal of old DRI2 buffer alloc/free interfaces for video drivers - Removal of the old Resources/RAC API for video drivers All modules built delivered in the X consolidation have been updated to adjust to these changes, including all of the community-developed drivers and extensions, and the Sun created/maintained IA (Interactive Priority Class) and xtsol (Trusted Extensions) loadable modules. The drivers delivered through the SPARC graphics consolidation have been updated for delivery in coordination with the Xorg 1.7 delivery. Nvidia tracks the open source community ABI changes for their Xorg driver for all supported platforms (Solaris, Linux BSD), and the version integrated into Nevada and OpenSolaris already supports the Xorg 1.7 release ABI's. VirtualBox's guest addition drivers will need updates for this, as they do for the BSD Linux distros which have already or are also working on adopting Xorg 1.7. VirtualBox typically delivers these drivers via updates to their application - until those updates are delivered, VirtualBox users may use the default mouse and Vesa drivers, though with reduced performance and functionality over VirtualBox guest drivers. We are not aware of any other consumers of these Volatile ABI's which would need to be updated in coordination. Input drivers removed: -- The incompatible changes to input driver API ABI required updates to most input drivers. Since a number of drivers for old input devices were unmaintained, and had not had any reports of usage in several years, the community chose to discontinue those drivers instead of porting to the new API
Mesa OpenGL switcher for SPARC [LSARC/2009/659 FastTrack timeout 12/09/2009]
This case was approved by LSARC today during ARC business. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
libX11 1.3 [PSARC/2009/666 Self Review]
I am sponsoring this case for myself and have marked it Closed Approved Automatic, with Patch Release Binding, as it simply tracks an upstream API addition. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: libX11 1.3 1.2. Name of Document Author/Supplier: Author: Alan Coopersmith 1.3 Date of This Document: 07 December, 2009 4. Technical Description This case updates libX11 to the version 1.3 release from X.Org. This adds a new API for handling extra data returned with the GenericEvent added by the XGE extension (PSARC 2009/293): Bool XGetEventData(Display *display, XGenericEventCookie *cookie); void XFreeEventData(Display *display, XGenericEventCookie *cookie); Details are provided in the XGetEventData.3X11.txt man page in the case materials, or externally at: http://www.x.org/releases/X11R7.5/doc/man/man3/XGetEventData.3.html These functions are added to libX11.so under the new library version SUNW_1.3. Imported Interfaces: X Generic Event extension, Version 1.0 Committed PSARC 2009/293 Exported Interfaces: XGetEventData()Committed XFreeEventData() Committed XGenericEventCookie typedefCommitted libX11.so:SUNW_1.3 Committed 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: X Consolidation / Desktop C-Team 6.5. ARC review type: Automatic 6.6. ARC Exposure: open
Mesa OpenGL switcher for SPARC [LSARC/2009/659 FastTrack timeout 12/09/2009]
I am sponsoring this fasttrack for the X SPARC Graphics consolidations. It has a minor release binding. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Mesa OpenGL switcher for SPARC 1.2. Name of Document Author/Supplier: Author: Alan Coopersmith 1.3 Date of This Document: 02 December, 2009 4. Technical Description This project delivers the Mesa implementation of OpenGL the OpenGL switcher utility on SPARC. This is needed to allow OpenGL software to be included in OpenSolaris, since the current Sun OpenGL cannot be included in the OpenSolaris LiveCD or redistributable repository at this time, but a number of other packages (such as various utilities included in GNOME) depend on OpenGL software being present. Both of these are already provided on x86 platforms, so this case provides platform parity for these. The x86 deliveries were covered by these previous ARC cases: LSARC 2005/109 Mesa, Open Source OpenGL clone LSARC 2005/700 OpenGL boot time selection of libraries and headers Differences between those cases and this delivery: - As per PSARC 2009/482, the paths under /usr/X11 are now Obsolete, and the paths under /usr/include /usr/lib are the Stable paths. - On the x86 platform, the OpenGL switcher selects nvidia if the console framebuffer is using the nvidia accelerated driver, otherwise mesa. On the sparc platform, the OpenGL switcher will select sun if the SUNWgl* directories are present, otherwise mesa. This case modifies the previous Sun OpenGL cases (last successfully reviewed in LSARC 2005/254: OpenGL 1.5) by changing the SUNWgl* packages they deliver to not deliver directly to /usr/lib/libGL* or /usr/include/GL, but instead to /usr/lib/SUNWgl/libGL* and /usr/include/SUNWgl. As with the original Mesa delivery on x86, this case only delivers the Mesa software rasterizer (via the DRI swrast module), and does not include any hardware accelerated backends. The architecture is present however, should a future project deliver the required kernel-level DRI support for any DRI-supported graphics cards. (Any such project will also be responsible for updating the OpenGL selection algorithm to correctly select Mesa on hardware it can accelerate but Sun OpenGL cannot.) 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: X SPARC Graphics consolidations / Desktop C-Team 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
Where to integrate FOSS
Scott Rotondo wrote: Part of the problem seems to be that there is no good place to keep the source code. The choices seem to be: (a) Keep the source in an unknown, uncontrolled location (e.g. someone's home directory) Sources in someone's home directory can't be used for /contrib, since the source juicer build daemon used to build contrib packages won't be able to find them there. Couldn't we partition SFW into release and contrib trees and get the best of both worlds? Isn't SFW contrib just the Companion CD with a new name? It unfortunately falls into the same trap as any SFW change - not enough people to do the work, and given the way Source Juicer works, seems mostly pointless. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
bd - generic block device driver [PSARC/2009/646 FastTrack timeout 12/06/2009]
Garrett D'Amore - sun microsystems wrote: The bd driver will be used as a block-oriented device driver for devices that need general block device support. Because we might in the future like to offers support for some of these storage adapters on Solaris 10, we are requesting Patch binding, although we have no specific plans to backport at this time. bd is an unfortunate driver name as a very very different bd driver shipped with SunOS 4 through Solaris 10, for the ancient SunButtons SunDials input devices. (See bd(7M) on a Solaris 10 or older system.) While that wouldn't be a stopper on Nevada (though it might be confusing to those who upgrade), it would seem to block backporting to S10. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Xerces-C++ and Xalan-C++ Integration [LSARC/2009/637 FastTrack timeout 11/26/2009]
Jyri Virkki wrote: This project will deliver both 32-bit and 64-bit Xerces-C++ libraries. Xerces-C++ and Xalan-C++ imports interfaces from the Standard C Library and the Pthreads Library. Which C++ ABI? Which C++ standard library? -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
usbwcm: Wacom USB Tablet STREAMS module [PSARC/2009/621 FastTrack timeout 11/19/2009]
Alan Coopersmith wrote: I am sponsoring this fast-track for Pengcheng Chen of the USB team. The timer is set for next Thursday, November 19. This case was approved during ARC business at PSARC today. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
usbwcm: Wacom USB Tablet STREAMS module [PSARC/2009/621 FastTrack timeout 11/19/2009]
Darren J Moffat wrote: Alan Coopersmith wrote: I am sponsoring this fast-track for Pengcheng Chen of the USB team. The timer is set for next Thursday, November 19. The release binding requested is Patch. A copy of the usbwcm(7m) draft man page is available in the case materials directory as usbwcm.7m.txt. So there is an intent to backport this to Solaris 10 along with the Xorg wacom driver too ? Not necessarily - release binding is never an indication of intent, just a statement that the changes made are of a certain compatibility level such that the possibility is open, should the business case arise. Is the case really complete without the Xorg wacom driver ? Is there anything useful that can be done on the system without a user building wacom on there own ? It doesn't feel complete to me. Downloading and building the Xorg wacom driver is much easier than porting a kernel driver module from another kernel, so this is a huge step towards a complete solution and one which will allow many users to finish the needed steps on their own. (Unfortunately, we can't ship the available Xorg wacom driver with Solaris or OpenSolaris due to licensing issues, but that doesn't provent others from building, using, or redistributing it, while we work on a solution that can be included with the OS.) -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
usbwcm: Wacom USB Tablet STREAMS module [PSARC/2009/621 FastTrack timeout 11/19/2009]
I am sponsoring this fast-track for Pengcheng Chen of the USB team. The timer is set for next Thursday, November 19. The release binding requested is Patch. A copy of the usbwcm(7m) draft man page is available in the case materials directory as usbwcm.7m.txt. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: usbwcm: Wacom USB Tablet STREAMS module 1.2. Name of Document Author/Supplier: Author: Pengcheng Chen 1.3 Date of This Document: 12 November, 2009 2. Project Summary 2.1. Project Description: This case provides a STREAMS module to support Wacom USB tablets[1]. Wacom USB tablets are popular and used in applications, such as GIMP, Inkscape, and etc. This module is a port of the FreeBSD uwacom driver[2], which implements necessary interfaces for the Wacom X.org XInput driver[3] to work. 3. Business Summary 3.1. Problem Area: Solaris has no built-in support for Wacom USB tablets. Users can not use these tablets out-of-box. Drivers for Wacom tablets are available under other major OSes (like Windows and Linux). 4. Technical Description: 4.1. Details: Wacom USB Tablet STREAMS module is developed under the current Solaris USB Architecture (USBA) and the minimal Human Interface Device (HID) framework. The usbwcm module implements the same IOCTLs and input event format as FreeBSD uwacom driver does. With these interfaces, the Wacom Xorg XInput driver can be ported to Solaris with minor modifications. The usbwcm module must be pushed on top of the HID class driver (see hid(7D)). The usbwcm module translates data from Wacom USB tablet into input events expected by Wacom Xorg XInput driver. 4.2. Bug/RFE Number(s): 4.3. In Scope: Provide a STREAMS module supporting of the following Wacom USB Tablets: Wacom Graphire3 Wacom Graphire4 Wacom Bamboo Wacom Bamboo Fun Wacom Intuos3 Wacom Intuos4 Wacom Cintiq 21UX 4.4. Out of Scope: For Wacom tablets to work out-of-box, the Wacom Xorg XInput driver and configuration tools[3] are also necessary. Providing support in Xorg is a follow-on project - until it is available, users can download the wacom driver sources from X.Org and build and run them on their own. 4.5. Interfaces: +--+ | Interfaces Exported | +--+ | Interface|Stability label| Comments| |--| | EVTIOCGVERSION | Uncommitted | Get current version of the event | | | | interface implemented in this | | | | module | | | | | | EVTIOCGDEVID | Uncommitted | Get device IDs| | EVTIOCGBM| Uncommitted | Get bitmap of events reported by | | | | the device | | | | | | EVTIOCGABS | Uncommitted | Get absolute valuator parameters | +--+ 4.6. Doc Impact: man page: usbwcm(7M) 4.7. Admin/Config Impact: Configuration tools are provided with Wacom Xorg XInput driver[3], which has no direct interation with this STREAMS module. 4.10. Packaging Delivery: This STREAMS module will be integrated as part of the exising SUNWusb package. 5. Reference Documents: [1] Wacom website http://www.wacom.com [2] FreeBSD uwacom driver http://www.freshports.org/x11-drivers/input-wacom [3] Wacom X.org XInput driver http://linuxwacom.sourceforge.net 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
primary-controller frame buffer driver property [PSARC/2009/596 FastTrack timeout 11/09/2009]
Alan Coopersmith wrote: I am sponsoring this case on behalf of Edward Shu of the x86 video driver team. The timeout is set for next Monday, November 9. Since this case has converged, and gotten it's +1, and there are no remaining issues, it is now closed approved. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
NRPE - nagios-addons [LSARC/2009/604 FastTrack timeout 11/12/2009]
John Fischer wrote: /usr/etc/nrpe.cfg - NRPE Configuaration file /usr/etc ? Shouldn't that be just /etc? -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Nagios [LSARC/2009/603 FastTrack timeout 11/12/2009]
Darren J Moffat wrote: John Fischer wrote: SUNWnagiosr and SUNWnagiosu packages are Uncommitted. Given that SXCE will no longer exist very soon and OpenSolaris IPS collapses these down we should probably stop pretending we need separate root and usr packages. And given that IPS will be renaming packages, all SUNW* package names are effectively Obsolete/Volatile, so Uncommitted is just pretending IPS isn't coming. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
GCC4: The GNU Compiler Collection 4.X [LSARC/2009/575 FastTrack timeout 10/28/2009]
? wrote: Ada language support was not addressed, too. This is the second time the compiler project team is not implementing support. How do I appeal a PSARC case? First the case has to be completed. In the case of missing language support, I don't see anything to appeal though - this ARC case isn't blocking you from bringing along a followon project to add Ada support. If your complaint is the project team isn't signing up to do work they didn't agree to and haven't planned on, no ARC can help you with that - they don't assign resources. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
TigerVNC 1.0 [PSARC/2009/592 FastTrack timeout 11/06/2009]
Alan Coopersmith wrote: I am sponsoring this case for myself and have set the timeout for a week from today, next Friday, November 6. This case was approved today during PSARC business. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
[i18n-discuss] Locale name alias support at libc [PSARC/2009/594 FastTrack timeout 11/06/2009]
Ienup Sung wrote: Garrett D'Amore wrote at 10/30/09 21:28: It looks like you're planning on baking the list of aliases into the libc binary itself? I'd really rather not do that. Would it be better to put the aliases in a separate file -- call it locale_alias to match your man page? -- Garrett You're correct that I hope to bake the list of aliases into the libc since we don't expect that the list will change in the future. (The chance of it being updated significantly would be very slim.) The locale.alias list that libX11 uses is updated almost every libX11 release due to changes in various OS'es/distros, and the inevitable political upheavals. (Try as we might, we haven't convinced the world governments to make the names and boundaries of nations into a stable interface, so have to deal with things such as the breakup and renaming of the Balkan states.) The scm history for it: http://cgit.freedesktop.org/xorg/lib/libX11/log/nls/locale.alias.pre -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
primary-card frame buffer driver property [PSARC/2009/596 FastTrack timeout 11/09/2009]
I am sponsoring this case on behalf of Edward Shu of the x86 video driver team. The timeout is set for next Monday, November 9. The case requests a patch release binding. While the case is defined in a platform independent manner, the initial implementation will only cover x86 platforms as SPARC graphics drivers live in another consolidation. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: primary-card frame buffer driver property 1.2. Name of Document Author/Supplier: Author: Edward Shu 1.3 Date of This Document: 02 November, 2009 4. Technical Description 1. Summary The frame buffer driver property will expose the primary device to Xorg server or console driver. It is particularly helpful to the system with two or more graphics card attached. For the Xorg server, it must find the primary device to start at. Also, console must start on the primary graphics device when it is not directed to non-graphics device. 2. Discussion The frame buffer driver can also use visual ioctl to expose the primary graphics card information. But there are some drawbacks for adding the visual ioctl to the frame buffer driver. 1) It is difficult for the console query code to leverage the ioctl interface. Because the code there was bundled with dev_info pointer instead of standard driver interfaces like open, ioctl, etc. 2) The user land code don't know how many frame buffer driver that it should query using the ioctl. It can only enumerate the frame buffer device links, like /dev/fb0, fb1, fb2, fb3. Most likely, the links will not be extended to fb4 and more. But it is not guaranteed. So a driver property is used to expose the information. 3. Interface table Interface Name Classification Comments -- primary-card driver propertyCommittedprimary graphics device Every frame buffer driver will create a primary-card for it. And the value is a boolean value. True on the primary device and false on the others. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
xcompmgr transset [LSARC/2009/597 Self Review]
I am sponsoring this case for Stuart Kreitman of the X group. I've marked it Closed Approved Automatic as it simply passes through a program from the X.Org community. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: xcompmgr transset 1.2. Name of Document Author/Supplier: Author: Stuart Kreitman 1.3 Date of This Document: 02 November, 2009 4. Technical Description xcompmgr is a simple composite window manager capable of rendering drop shadows and, with the use of the transset utility, primitive window transparency. Designed solely as a proof-of-concept, xcompmgr is a lightweight alternative to Compiz Fusion and similar composite managers. Transset is a simple utility to toggle Translucency property on the next window clicked Usage: transset [ -display host:dpy | -d host:dpy ] [host:dpy] [opacity] This project delivers xcompmgr version 1.1.4. Transset is unversioned, but will be pushed upstream as part of the xcompmgr module Interfaces Exported --- xcompmgrVolatilePatch Release Binding transsetVolatilePatch Release Binding References in case directory: xcompmgr.1.txt - text dump of xcompmgr(1) man page 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: X Consolidation (Desktop C-Team) 6.5. ARC review type: Automatic 6.6. ARC Exposure: open
TigerVNC 1.0 [PSARC/2009/592 FastTrack timeout 11/06/2009]
I am sponsoring this case for myself and have set the timeout for a week from today, next Friday, November 6. The case is submitted to PSARC and cc'ed to LSARC since this updates PSARC 2007/545 for Xvnc and LSARC 2007/625 for vncviewer. The release binding is set to patch as there are no incompatible changes, but there are no plans for patch/update delivery at this time. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: TigerVNC 1.0 1.2. Name of Document Author/Supplier: Author: Alan Coopersmith 1.3 Date of This Document: 30 October, 2009 4. Technical Description This project replaces the VNC implementation used for Xvnc vncviewer, moving from the RealVNC open source release provided by RealVNC, Inc. to the TigerVNC community-maintained fork. RealVNC has quietly cut back on new open source releases of their software, with just two minor security fixes released since 2005. The TigerVNC community project was formed by the maintainers of several open source distros, who had to independently maintain the changes needed to make RealVNC work with current Xorg releases (RealVNC's source releases still only support XFree86 4.x), and developers from the TightVNC and TurboVNC variants, which provided enhancements over the original RealVNC sources. TigerVNC maintains compatibility with the core Remote Frame Buffer (RFB) protocol used by all VNC implementations, while supporting several extensions that RealVNC has not adopted, for better compression security. The specification of the protocol, with these extensions, is provided in the case materials as rfbproto.html. Several command line options have been added to the commands, including both new functionality, and variants of the existing colour options with the u removed for American spelling habits. No incompatible changes are made. The case materials include diffs of the man pages for reference. This project also provides a new command, x0vncserver, which connects to a running X server and exports its display over the RFB protocol to VNC clients. The vncserver command is modified by this project to start a GNOME session by default, instead of a simple twm xterm session. Users with existing $HOME/.vnc/xstartup scripts will not be affected by this change. The GNOME session will be started by running /etc/gdm/Xsession if it is found, otherwise, falling back to running /usr/dt/config/Xsession.jds. If neither of those are not found, then the default startup will fallback to the twm xterm session. Imported interfaces: /usr/bin/sshStable PSARC 2001/212 /usr/bin/vncconfig VolatilePSARC 2007/545 /usr/bin/vncpasswd VolatilePSARC 2007/545 /usr/bin/vncserver VolatilePSARC 2007/545 /usr/X11/bin/Xvnc VolatilePSARC 2007/545 /usr/bin/vncviewer Committed LSARC 2007/625 vncviewer hostname:display Committed LSARC 2007/625 All other vncviewer options VolatileLSARC 2007/625 /etc/gdm/Xsession Uncommitted LSARC 2003/261, LSARC 2009/433 /usr/dt/config/Xsession.jds Stable LSARC 2004/713, LSARC 2006/161 Exported interfaces: New vncviewer options: Volatilevncviewer.txt -DesktopSize, -LowColorLevel, -via, -PreferredEncoding Tight /usr/X11/bin/Xvnc ObsoletePSARC 2009/482 /usr/bin/Xvnc Volatile /usr/bin/x0vncserverVolatile References: 1. http://www.tigervnc.com/ 2. The RFB Protocol - rfbproto.html 3. TigerVNC man pages: Xvnc.txt, vncconfig.txt, vncpasswd.txt, vncserver.txt vncviewer.txt, x0vncserver.txt 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: X Consolidation / Desktop C-Team 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
TigerVNC 1.0 [PSARC/2009/592 FastTrack timeout 11/06/2009]
James Carlson wrote: Dumb off-topic non-architectural question, but this fast-track just reminded me: does this update also fix the core dumps that happen on v6-enabled machines? I have to type vncviewer 127.1:1 instead of localhost:1 or just :1, because the v6 ::1 causes vncviewer to drop core. If so, then the update is a really welcome addition. ;-} I'm not seeing core dumps when trying that with either the old or new versions of vncviewer, nor do I see any bug reports in bugster under solaris/xserver/vnc matching that description. We can take that discussion offline to see if we can figure out what's going on with that bug. This update does not fix the limitation that while vncviewer is capable of connecting to a RFB server over IPv6, the Xvnc server only listens for incoming connections on IPv4. That's a limitation that needs to be fixed upstream. (The vncviewer IPv6 support was originally a Fedora addition to RealVNC we picked up, and which the Fedora maintainer has integrated into TigerVNC upstream now.) -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
TigerVNC 1.0 [PSARC/2009/592 FastTrack timeout 11/06/2009]
James Carlson wrote: This update does not fix the limitation that while vncviewer is capable of connecting to a RFB server over IPv6, the Xvnc server only listens for incoming connections on IPv4. That's a limitation that needs to be fixed upstream. (The vncviewer IPv6 support was originally a Fedora addition to RealVNC we picked up, and which the Fedora maintainer has integrated into TigerVNC upstream now.) OK. Is there a project team working on those upstream issues? Not at Sun. I haven't checked if the upstream community is working on them. (The VNC project team at Sun is mostly me a couple hours a year doing updates, and other engineers occasionally doing a bug fix here and there. This is not a high priority project by any means.) -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
TigerVNC 1.0 [PSARC/2009/592 FastTrack timeout 11/06/2009]
Garrett D'Amore wrote: The specification of the protocol, with these extensions, is provided in the case materials as rfbproto.html. I don't see that file. Whoops, forgot to copy it in - it's there now, in both plain text html (It's just a dump of the current copy from http://www.tigervnc.com/ .) -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Fasttrack: LSARC/2009/568 Sun GlassFish Communication Server 2.0 (Project SailFin 2.0)
John Fischer wrote: Lloyd, I think that the status for this case should be closed not reviewed. Please see the following email for details: http://mail.opensolaris.org/pipermail/opensolaris-arc/2008-October/011763.html Specifically, it's closed *denied* not reviewed. Teams who get too many cases denied because no one on ARC has time to review will need to escalate to their management that they need to increase the number of engineers from their team who participate in ARC's so that the ARC case load can be more evenly shared among the teams using the ARC reviews. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
GCC4: The GNU Compiler Collection 4.X [LSARC/2009/575 FastTrack timeout 10/28/2009]
Raj Prakash wrote: usr/share/man/man7 usr/share/man/man7/fsf-funding.7 usr/share/man/man7/gfdl.7 usr/share/man/man7/gpl.7 Since those are not device drivers, the miscellaneous topics man pages belong in section 5 on SysV-based platforms like Solaris, instead of the BSD-style section 7. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
OpenGL 3.2 for the NVIDIA graphics driver [LSARC/2009/569 Self Review]
I am sponsoring this case for John Martin, and have marked it closed approved automatic, with a patch release binding, as it simply passes through Nvidia's updates to implement the new version of the OpenGL standard. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: OpenGL 3.2 for the NVIDIA graphics driver 1.2. Name of Document Author/Supplier: Author: John Martin 1.3 Date of This Document: 19 October, 2009 4. Technical Description This project is the delivery of OpenGL 3.2 / GLSL 1.50 support in the NVIDIA graphics driver. This is an update to OpenGL 3.0 / GLSL 1.30 [LSARC/2009/066] delivered in the R180 driver and OpenGL 3.1 / GLSL 1.40 [LSARC/2009/259] delivered in the R185 driver. The scope of the project is specific to delivery in the NVIDIA graphics driver as OpenGL 3.x introduces a new deprecation model where the intent to remove old features in future releases is declared. The committments to interface stability for this project may not apply to OpenGL 3.x implementations from other vendors. Each of those should be treated as separate projects. The Khronos group (http://www.khronos.org) announced the OpenGL 3.2 and GLSL 1.50 update on 03 August, 2009. Details of this announcement are at: http://www.khronos.org/news/press/releases/khronos-releases-opengl-3.2-third-major-opengl-release-within-twelve-months/ The specifications posted time of this announcement: OpenGL 3.2 Core Profile Specification http://www.opengl.org/registry/doc/glspec32.core.20090803.pdf OpenGL 3.2 Compatibility Profile Specification http://www.opengl.org/registry/doc/glspec32.compatibility.20090803.pdf OpenGL 1.50 Shading Language http://www.opengl.org/registry/doc/GLSLangSpec.Full.1.50.09.pdf New features: - LSARC/2009/066 discussed a new deprecation model introduced in OpenGL 3.0 including the NVIDIA implementation which will deliver deprecated features. To provide optional support of deprecated features, OpenGL 3.2 introduces core and compatibility crofiles. This superceeds the ARB_compatibility extension introduced in OpenGL 3.1 and discussed in LSARC/2009/259 and the compatibility profile restores features removed from the OpenGL 3.1 core specification. Appendix H.1 of the 3.2 Core Specification lists the new features. Deprecation of old features: As mentioned in the new features section above, core and compatibility profiles are introduced in OpenGL 3.2. The only feature marked for deprecation in the core profile is global component limit query. No feature was deprecated in the compatibility profile by OpenGL 3.2. Details are in Appendix H.2 of the 3.2 Core Specification. Support: Bugtraq: nvidia/nvidia/opengl Delivery: - The interfaces listed below are delivered by the NVDAgraphics SYSV package and the NVDAgraphics IPS package, in conjunction with the ogl-select SMF service [LSARC/2005/700]. There are no name changes to the headers or libraries for OpenGL 3.2 so existing build environments are not effected. In the first delivery of this project (driver 190.3x) delivers all of the OpenGL 3.2 and GLSL 1.50 interfaces with the possible following exception: glXCreateContextAttribsARB() does not yet support the GLX_CONTEXT_PROFILE_MASK_ARB attribute value. In order to create a core profile context, call glXCreateContextAttribsARB(), request OpenGL 3.2 as the version, and leave the GLX_CONTEXT_PROFILE_MASK_ARB attribute out. In order to create an OpenGL 3.2 compatibility profile context, call the old glXCreateContext() entry point. Interfaces Exported Interface Classification Comments - /usr/include/GL/gl.h Committed /usr/include/GL/glext.hCommitted /usr/include/GL/glx.h Committed /usr/include/GL/glxext.h Committed /usr/lib/libGL.so.1Committed /usr/lib/amd64/libGL.so.1 Committed The libraries /usr/lib[/amd64]/libGLcore.so.1 are private objects and should not be linked in for normal application development. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: X 6.5. ARC review type: Automatic 6.6. ARC Exposure: open
LiveCD session improvement [PSARC/2009/560 FastTrack timeout 10/22/2009]
[Dropped desktop-cteam, as it's an internal-only alias - please don't mix internal external aliases on the same mail - it causes confusion and bounces.] Is there some reason you're not submitting this to LSARC, which reviews all the other GNOME cases, including all previous gdm cases? (BTW, one of your imported interfaces is actually Obsolete now, since /usr/X11 was declared obsolete by PSARC/2009/482 - I don't know when the Prague G11n team plans to deliver the XKB keymaps to /usr/share instead though.) -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Suresh Chandrasekharan wrote: Submitting this fastrack timing out on 10/22/2009, seeking Solaris minor release binding. Suresh Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: LiveCD session improvement 1.2. Name of Document Author/Supplier: Author: Suresh Chandrasekharan 1.3 Date of This Document: 14 October, 2009 4. Technical Description 4.1. Details: gdm-2.28 is soon be integrating to OpenSolaris. Compared with the existing gdm-2.20.10 this is major rewrite. One of the capabilities of this gdm, if there's a backend libxklavier library to support it is the ability to select a keyboard layout from the gdm login screen. Both the already existing login locales menu and the new keyboard layout menu are placed on a panel at the bottom of the screen. Support to change the keyboard layout is needed at GDM level for machines shared by users who use different keyboards or users sharing a single keyboard with possibly different layouts. PSARC/2009/483 - libxklavier re-integration enables gdm-2.28 to display the keyboard layouts in the gdm screen. The backend library libxklavier is provided through that case. One major advantage of providing the gnome keyboard and locale selection at the gdm screen is that, we can effectively replace the text console based keyboard/language selection that we currently have in OpenSolaris 2009.06 LiveCD. The menu based selection can hold more keyboards/locales in them than the text console based selection. The initial feedback from xDesign is that we need to automatically popup the keyboard/language selection when user is booting up the LiveCD. We will also work with LiveCD team to disable the text based selection screens for keyboard layout and locales. 4.5. Interfaces: Imported Interfaces --- Interface Stability Notes - - - From PSARC/2009/483 SUNWlibxklavier /usr/lib/libxklavier.so.15.0.0 Volatilelibrary /usr/lib/libxklavier.so.15 Volatilesym link /usr/lib/libxklavier.soVolatilesym link SUNWlibxklavier-devel /usr/include/libxklavier/xkl-enum-types.hVolatile Header File /usr/include/libxklavier/xkl_config_item.h Volatile Header File /usr/include/libxklavier/xkl_config_rec.hVolatile Header File /usr/include/libxklavier/xkl_config_registry.h Volatile Header File /usr/include/libxklavier/xkl_engine.hVolatile Header File /usr/include/libxklavier/xkl_engine_marshal.hVolatile Header File /usr/include/libxklavier/xklavier.h Volatile Header File From PSARC/2009/117 and PSARC/2009/440 /usr/X11/lib/X11/xkb/* UncommittedXKB definition files directories. Obsoleted Interfaces --- Language/kbd selection text console screens in LiveCD from slim_source/usr/src/cmd/slim-instal/svc/live-fs-root Exported Interfaces No significant interfaces are exported 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: G11N 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
xscope 1.2 [LSARC/2009/549 Self Review]
I am sponsoring this case for myself, and have marked it closed approved automatic, with a release binding of patch, as it is a simple update to the new version of a community maintained tool, with no compatibility issues. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: xscope 1.2 1.2. Name of Document Author/Supplier: Author: Alan Coopersmith 1.3 Date of This Document: 09 October, 2009 4. Technical Description This case upgrades the xscope program in Solaris OpenSolaris from X.Org version 1.1 to version 1.2. This version adds: * Interactive debugging mode with breakpoints single stepping through requests * X11 extension protocol decoding for: BIGREQUESTS NCD-WinCenterPro LBX RANDR 1.0 MIT-SHM RENDER 0.11 * Decoding of bigrequest-encoded requests, GenericEvent encoded events, ServerInterpreted host addresses * NAS audio protocol decoding * -S option to toggle output on SIGUSR1 * -t option to terminate when all clients close * -r option to dump raw packet data The new man page and diffs from the xscope 1.1 man page are provided in the case materials. Exported interfaces: xscope command line options Volatile xscope interactive commands Volatile xscope output formatNot An Interface 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: X Consolidation / Desktop C-Team 6.5. ARC review type: Automatic 6.6. ARC Exposure: open
libgnomekbd re-integration [PSARC/2009/532 FastTrack timeout 09/13/2009]
Joerg Barfurth wrote: Suresh Chandrasekharan schrieb: Following PSARC/2009/483, case to re-integrate libxklavier, I'm submitting libgnomekbd re-integration request fasttrack. Seeking minor binding, timing out on 09/13/2009. Aren't we moving away from doing separate -root packages? Especially, if all they contain is a single gconf schema? Seperate -root packages are still required for SVR4 packaging. Once the consolidation being delivered to is converted to only building and delivering IPS packages, then -root packages can go away, but that point is still TBD for consolidations other than ON. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Synergy - Mouse/Keyboard sharing [LSARC/2009/489 FastTrack timeout 09/21/2009]
Alan Coopersmith wrote: I am sponsoring this case for Stuart Kreitman of the X team. The timeout is set for next Monday, Sept. 21, 2009. I'm told LSARC approved this at last week's meeting (Stuart I were at the X.Org conference so were unable to attend ourselves), so have marked the case closed approved. Thank you for your consideration. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
2009/530 [Removal of NIS+]
Raja Gopal Andra wrote: From my understanding after reading the PSARC case, the answer is that there will be no impact of removing NIS+ on S10 zones. In fact, shouldn't the availablity of S10 zones help with the transition steps that require a machine running S10? Can that be tested and documented as an option (along side the currently documented option of just having a natively running S9 or S10 machine) in the steps you listed in the fasttrack for the transition plan?(Just a suggestion, don't think it should be a requirement if it turns out to have an issue.) -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Where is the meta-architecture to support FOSS?
Joerg Schilling wrote: Alan Coopersmith Alan.Coopersmith at sun.com wrote: John Plocher wrote: James Carlson carlsonj at workingcode.com wrote: .. Thus FOSS is special. I believe FOSS *IS* Special - because doing a good job of integrating general cross-platform FOSS into OpenSolaris is actually HARDER than integrating something invented by the community specifically for the OS itself. So it's not the FOSS license that makes it special - it's the external control, for which we may or may not have some contribution to, that's the difference. Is there really any difference in the architecture If you have problems with the fact that other people control the development for their software, you need to rethink your relation to OSS. Don't put words in my mouth. I didn't say it was a problem, just that it was different, and that the difference was not due to the license, but the control, and that was what the ARC process has to adapt to deal with. If you paid any attention at all to what I do, you'd see that I've spent years working to integrate OSS from the X community to Solaris, to represent Solaris architectural constraints back to the X community and to make the two work together for the benefit of both the OpenSolaris and X.Org communities. The development is controlled by the people who make the work and BTW: if you like people from the community to write code for OpenSolaris, you of course need to allow them to decide on the future of OpenSolaris. Yep, that's what we've been working on doing, and to a certain amount have done - the people doing the work are making many of the decisions. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Where is the meta-architecture to support FOSS?
John Plocher wrote: James Carlson carlsonj at workingcode.com wrote: .. Thus FOSS is special. I believe FOSS *IS* Special - because doing a good job of integrating general cross-platform FOSS into OpenSolaris is actually HARDER than integrating something invented by the community specifically for the OS itself. So it's not the FOSS license that makes it special - it's the external control, for which we may or may not have some contribution to, that's the difference. Is there really any difference in the architecture of integrating Xorg's open source nvidia driver vs. Nvidia's proprietary driver? In neither case do we have control - we can influence both upstream sources to make changes, but once they publish a version, we are limited in the amount of changes we can or should make as we integrate it to Solaris. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
PSARC 2009/397 GnuPG and Friends - updated deliverables
Wyllys Ingersoll wrote: /usr/libexec/scdaemon Uncommitted Command /usr/libexec/gpg-protect-tool UncommittedCommand /usr/libexec/gpg-preset-passphrase Uncommitted Command /usr/libexec/gnupg-pcsc-wrapper Uncommitted Command /usr/libexec/gpg2keys_ldapUncommitted Command /usr/libexec/gpg2keys_hkp Uncommitted Command /usr/libexec/gpg2keys_finger Uncommitted Command /usr/libexec/gpg2keys_curlUncommitted Command There is no libexec on Solaris - those should be in /usr/lib or /usr/lib/gpg. /usr/share/man/man8/addgnupghome.8Uncommitted Manpage /usr/share/man/man8/applygnupgdefaults.8 Uncommitted Manpage Those need to be 1m man pages on Solaris. (8 is the BSD section for admin commands, but Sys V put them in 1m.) -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
GDB: The GNU Project Debugger [LSARC/2009/492 FastTrack timeout 09/22/2009]
George Vasick wrote: The stability of gdb interfaces is really up to its maintainers. Our goal is simply to port it to Solaris and preserve the exported interfaces as they come from the maintainers. What if I make a stability claim that Sun cannot honor down the road? If you state it will remain compatible, and the upstream makes incompatible change, Sun can honor a stability claim by choosing to not import the new versions, or choosing to modify them to preserve compatibility, or by importing them under a new name, such as gdb7. Again, for gdb, there's a very limited number of interfaces it makes sense to declare as Committed, because it's not the sort of thing we should be encouraging other software to build upon (other than things like ddd that enhance it).For a library interface, it would be a more interesting question - and more likely the upstream understands that breaking ABI means shipping new versions as .so.2 or similar. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
xdm 1.1.9 (X11R7) [LSARC/2009/512 Self Review]
I am sponsoring this case for myself. Since it is a straightforward upgrade to the latest open source release, with no controversial changes, I've marked it Approved Automatic, with Patch release binding. A text output copy of the new man page, and diffs from the old one, are available in the case directory for reference. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: xdm 1.1.9 (X11R7) 1.2. Name of Document Author/Supplier: Author: Alan Coopersmith 1.3 Date of This Document: 24 September, 2009 4. Technical Description This case replaces the X11R6 based xdm display manager currently shipped on Solaris in /usr/openwin with an X11R7 based version in /usr. The xdm software is split out of the previous SUNWxwopt package into the new SVR4 packages SUNWxdm SUNWxdm-root (which will be combined into a single xdm IPS package). Solaris Citizenship Status: --- xdm remains a resident alien of Solaris. This case, by following upstream changes, brings xdm slightly closer to becoming a good, full citizen of Solaris, but reaching full integration is out of scope for this case, and must wait for later projects. Previously implemented in xdm (and not regressed in this case): - Full PAM conversation support for authentication. - Control of root login via the CONSOLE parameter in /etc/default/login Changes made by this case: - Site-administered configuration files have moved from /usr to /etc In the SVR4 packages they are type e, class preserve. - Runtime data files logs have moved from /usr to /var - Only read-only, non-site-editable files remain in /usr - Secure-by-default: listening for incoming XDMCP connections is disabled in the default configuration. Sites wishing to allow remote sessions via XDMCP will need to edit the configuration files in /etc/X11/xdm to enable the XDMCP port and adjust the host access list. Known remaining obstacles to full citizenship: - SMF integration. No mechanism to start xdm automatically is currently provided, neither an /etc/rc*.d script nor an SMF manifest. xdm also does not manipulate process contracts to ensure that a segfaulting program in a user session does not cause SMF to kill the entire session and restart the xdm daemon. - Auditing. xdm does not call the Solaris Audit API's to record authentication attempts and results. - Use of logindevperm to set device ownership/permissions. - Use of the ASARC 1995/390 dtlogin pipe to inform the X server of the user logging in, so it can adopt that user's credentials There is no schedule at this time for those enhancements, but as xdm has been shipped in Solaris for over 15 years with some of these deficiencies, it is not a change to the status quo. Users needing any of the above missing features, or support for Sun Ray terminals or accessibility helpers, must continue to use gdm, which remains the preferred, recommended, and best supported display manager for Solaris OpenSolaris - xdm is just an alternative for sites who prefer it for some reason. New file layouts: - In accordance with PSARC 2009/482, the xdm files are directly integrated into /usr, not /usr/openwin nor /usr/X11. As noted above, several files have additionally moved beyond that to locations better fitting their purpose, and more closely matching the new locations used in upstream code and other OS'es. The xdm daemon binary itself is moved to /usr/sbin/xdm. The xdm configuration files are delivered to /etc/X11/xdm.Copies of the system-delivered ones (for reference if sites have modified them) are placed in /usr/lib/X11/xdm. The scripts that are run at various stages are delivered in /usr/lib/X11/xdm, along with a README informing sites that they can customize them by copying a script to /etc/X11/xdm and then changing the path to it in the master configuration file, /etc/X11/xdm/xdm-config. The xdmshell utility which was designed for sites which wanted to start in text console mode, but provide the ability to start xdm on demand by logging in as an xdm user, is delivered in /usr/lib/X11/xdm/xdmshell, since it is only intended to be run as a shell in the password database. The xdm.pid file in which xdm records its process id will be created as /var/run/xdm/xdm.pid. xauth authentication files for X servers started by xdm will be created in /var/run/xdm/authdir. The xdm log file will be created as /var/log/xdm.log. Backwards compatibility symlinks are left under /usr/openwin to aid in migration. Imported interfaces --- /usr/openwin locations for xdm ? Pre-ARC IPv6 support for xdm XDMCPCommitted PSARC 2002/443 XDM
xinput program [LSARC/2009/506 Self Review]
I am sponsoring this case for Stuart Kreitman of the X team. I've marked it Closed Approved Automatic as it simply bundles with Solaris OpenSolaris a new command line utility that X.Org has recently started shipping. A text output copy of the man page is provided in the case materials and is attached to this e-mail for easy reference. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: xinput program 1.2. Name of Document Author/Supplier: Author: Stuart Kreitman 1.3 Date of This Document: 21 September, 2009 4. Technical Description xinput is a small commandline tool to detect, list, configure and test XInput devices, using the XInput extension. This case adds version 1.4.2 of the X.Org xinput utility and documentation. Exported Interfaces: /usr/bin/xinput Uncommitted Patch Release Binding References: (in case materials) xinput.1.txtxinput(1) man page 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: X Consolidation / Desktop C-Team 6.5. ARC review type: Automatic 6.6. ARC Exposure: open -- next part -- An embedded and charset-unspecified text was scrubbed... Name: xinput.1.txt URL: http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20090921/273e62b3/attachment.txt
iBus integration [PSARC/2009/499 FastTrack timeout 09/24/2009]
Fuyuki Hasegawa - Sun Microsystems wrote: In order to reduce Solaris patches, we followed the original directories. Do you really have to patch it to change the path? Doesn't it offer ./configure flags for directory paths like most desktop open source software? (If not, that would seem a patch most upstreams would be happy to take, so that each distro doesn't have to patch it themselves.) -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
PSARC 2009/493 ld -z wrap option
Garrett D'Amore wrote: b) backed by well established precedent (e.g. drivers for new hardware that follow established architecture for devices of the given type) There's at least 10 years of precedent of introducing new public ld flags in self-review cases. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Obsolescence of /usr/X11 [PSARC/2009/482 FastTrack timeout 09/17/2009]
Alan Coopersmith wrote: I am sponsoring this fast-track for myself, with a timeout of Sept. 17, and a release binding of patch (though delivery is only planned for OpenSolaris Solaris Next at this time). This was approved today during PSARC business. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
64-bit only projects?
Chris Quenelle wrote: If an unbundled project wants to deliver only 64-bit binaries on sparc, should the 64-bit binaries go in the top-level bin directory? Or into bin/sparcv9 with a symlink pointing down to it? Or something else? I didn't see any examples of this in /usr/bin on a sparc lab machine with S10. Has anyone done this yet? The SPARC compilers might want to do this at some point. It's not in /usr/bin yet (the ARC case to move it there was just approved this morning), but /usr/X11/bin/Xorg is a simple 64-bit binary on SPARC. (On x86, it's isaexec'ed.) -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Synergy - Mouse/Keyboard sharing [LSARC/2009/489 FastTrack timeout 09/21/2009]
[Added cc of the TX/Xtsol experts to confirm my understanding. For their benefit, the proposal is to ship the synergy program to share keyboard, mouse keyboard between X servers on multiple machines. For details, see http://synergy2.sourceforge.net/ and http://arc.opensolaris.org/caselog/LSARC/2009/489/20090914_stuart.kreitman ] Darren J Moffat wrote: How does this work when the Solaris system is running with Trusted Extensions enabled ? In particular given that the screensaver is a trusted path concept and cut and paste is intercepted on trusted path and subject to authorisation. I think the answer is probably not well, and that's a good thing. In order to control the mouse and keyboard on the machines in the synergy group, synergy uses an X extension called XTEST which was originally designed for test suites to simulate input devices. The TX policy file for X will block usage of the XTEST extension in order to prevent clients being able to take control of clients with different security labels, so I don't think synergy will be able to run in TX by default. If it could run (such as if you modified the policy file, since it is a plain text file a site could vi) it would probably need to run in the global zone, and then since it's not label aware, it's clipboard sharing would probably violate the protections for copy and paste between differently labeled clients. In short, I think the best answer is probably for us to add a note to the man pages stating that synergy is not compatible with the restrictions of the TX multi-label desktop, and is not recommended for use there. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Synergy - Mouse/Keyboard sharing [LSARC/2009/489 FastTrack timeout 09/21/2009]
Darren J Moffat wrote: The bit that still isn't clear to me though is how I know what port numbers it is using - I couldn't work that out from the docs. Is it a fixed port number or a dynamic one ? The ssh port forwarding example on http://synergy2.sourceforge.net/security.html states The 24800 is the default network port used by synergy. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
GNOME 2.28 [LSARC/2009/475 FastTrack timeout 09/15/2009]
Brian Cameron wrote: [5] http://src.opensolaris.org/source/xref/jds/arc-documents/trunk/ gnome228/additional-materials/manpages.tar.gz [6] http://src.opensolaris.org/source/xref/jds/arc-documents/trunk/ gnome228/additional-materials/gtk-doc.tar.gz Materials for review should not be provided in compressed tarballs - please expand these into the case directory so they can be more easily reviewed. SUNWperl-authen-pam SUNWperl-authen-pam 0.16 0.16 SUNWperl-xml-parser SUNWperl-xml-parser 5.8.4 5.8.4 Which perl version are these provided for? Are they ready to support the newly delivered perl 5.10? (PSARC 2009/315) -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
GNOME 2.28 [LSARC/2009/475 FastTrack timeout 09/15/2009]
Brian Cameron wrote: I added the additional-materials/manpage directory in the case directory and provide the manpages in that directory. However, the gtk-docs are over 5,000 files and I thought we were moving away from storing large spews of data files in the case directories. Okay, so there's little point providing them, since any case that requires looking at hundreds, much less thousands, of files, is not a fasttrack, or anything short of a multi-month, multi-case, multi-meeting review. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
GNOME 2.28 [LSARC/2009/475 FastTrack timeout 09/15/2009]
Brian Cameron wrote: SUNWperl-authen-pam SUNWperl-authen-pam 0.16 0.16 SUNWperl-xml-parser SUNWperl-xml-parser 5.8.4 5.8.4 Which perl version are these provided for? Are they ready to support the newly delivered perl 5.10? (PSARC 2009/315) Currently they are provided for version 5.8.4. After reading PSARC 2009/315, I see that Perl 5.10 is binary-incompatible with 5.8, so the Desktop team will likely need to rebuild these modules after 5.10 is integrated into Solaris. Beyond that, I do not expect there is more that would need to be done, or am I missing something? Do we know what build Perl 5.10 will be integrated so that we can coordinate this? Normally we rebuild the Desktop stack on top of the latest build - 2. But in this case, it might make sense for the Desktop team to make plans to rebuild these modules in the same build that Perl 5.10 will be introduced. Perl 5.10 already integrated - it's in snv_122 and later, so you should have it when building the delivery for snv_124. (See CR 6841312.) I you'll either have to do parallel delivery for each version, much as you're already doing for several modules for Python 2.4 2.6, or decide only to support 5.10, and rebuild for it, and adjust the package dependencies to match. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Synergy - Mouse/Keyboard sharing [LSARC/2009/489 FastTrack timeout 09/21/2009]
I am sponsoring this case for Stuart Kreitman of the X team. The timeout is set for next Monday, Sept. 21, 2009. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering FCL--FOSS Check List 0. Introduction 0.1 Document History Version Author Changes Date 0.1 John Fischer Initial Draft 01/11/2008 0.2 John Fischer Modified based upon feedback from ARC members 01/29/2008 0.3 John Fischer Modified based upon feedback during committee 02/12/2008 review 0.4 John Fischer Modified based upon SAC review feedback 04/01/2008 0.5 John Fischer Modified based upon LSARC business meeting 06/10/2008 adding familiarity question and mod dates. 0.6 John Fischer Modified based upon user feedback about 06/20/2008 sections that were unanswerable. 0.2 Purpose Architecture review at Sun has allowed the company to evolve our projects within multiple disjoint groups while still maintaining a cohesive product line. Each architecture review was conducted within Sun's control. With the advent of Free Open Source Software processes the control that Sun as a company can wield has been diminished. Now that Sun is moving to a more fluid delivery mechanism with project Indiana we need to evolve the architecture review process. This document is meant to aid in the architecture review process. Each new project must complete this check list to help ensure that the overall resulting product conforms to Sun product standards. If the project deviates from these standards further review would be necessary by an architecture review committee. After the check list is completed the project team should be able to determine if a project can be automatically approved. This will occur if all checks result in no ARC review required answers. A committee member will assist the project team in filing the automatically approved fast track. An automatically approved fast track is still required in order to record the interfaces for future reference. If the project needs to have further review then follow the regular process for getting projects reviewed. 1.0 Project Information 1.1 Name of project/component Synergy - Mouse/Keyboard sharing 1.3.1, April 02-2006 1.2 Author of document Stuart Kreitman 2.0 Project Summary 2.1 Project Description Synergy lets you easily share a single mouse and keyboard between multiple computers with different operating systems, each with its own display, without special hardware. It's intended for users with multiple computers on their desk since each system uses its own monitor(s). Redirecting the mouse and keyboard is as simple as moving the mouse off the edge of your screen. Synergy also merges the clipboards of all the systems into one, allowing cut-and-paste between systems. Furthermore, it synchronizes screen savers so they all start and stop together and, if screen locking is enabled, only one screen requires a password to unlock them all. 2.2 Release binding What is is the release binding? (see http://opensolaris.org/os/community/arc/policies/release-taxonomy/) [ ] Major [X] Minor [ ] Patch or Micro [ ] Unknown -- ARC review required 2.3 Type of project Is this case a Linux Familiarity project? [X] Yes [ ] No 2.4 Originating Community 2.4.1 Community Name Synergy is hosted on Sourceforge. http://synergy2.sourceforge.net 2.4.2 Community Involvement Indicate Sun's involvement in the community [ ] Maintainer [ ] Contributor [X] Monitoring Will the project team work with the upstream community to resolve architectural issues of interest to Sun? [X] Yes [ ] No - briefly explain Will we or are we forking from the community? [ ] Yes - ARC review required prior to forking [X] No 3.0 Technical Description 3.1 Installation Sharable 3.1.1S Solaris Installation - section only required for Solaris Software (see http://opensolaris.org/os/community/arc/policies/install-locations/ for details) Does this project follow the Install Locations best practice? [X] Yes [ ] No - ARC review required Does this project install into /usr under [sbin|bin|lib|include|man|share]? [X] Yes [ ] No or N/A Does this project install into /opt? [ ] Yes - explain below [X] No or N/A Does this project install into a different directory structure? [ ] Yes - ARC
Obsolescence of /usr/X11 [PSARC/2009/482 FastTrack timeout 09/17/2009]
Sebastien Roy wrote: +1 with one minor question: On Thu, 2009-09-10 at 14:55 -0700, Alan Coopersmith wrote: Specifically, the major directory mappings will be: Previous location: New location: /usr/X11/bin /usr/bin /usr/X11/demo/usr/bin Would it make sense to have a /usr/demo/X11? If we had any software that we really wanted hidden there, yes. Right now, we don't. Most of what was in /usr/openwin/demo already moved to /usr/X11/bin since we got tired of telling users that things were hidden there, or finding that people had redelivered things like xeyes that were hidden there. Right now the only thing in /usr/X11/demo is glxgears, which all other distros ship in a normal bin directory. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Obsolescence of /usr/X11 [PSARC/2009/482 FastTrack timeout 09/17/2009]
I am sponsoring this fast-track for myself, with a timeout of Sept. 17, and a release binding of patch (though delivery is only planned for OpenSolaris Solaris Next at this time). This case is submitted to PSARC, as the traditional arbiter of the Solaris filesystem layout, but cc'ed to LSARC, as it affects cases that LSARC reviews. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Obsolescence of /usr/X11 1.2. Name of Document Author/Supplier: Author: Alan Coopersmith 1.3 Date of This Document: 10 September, 2009 4. Technical Description History: Historically Solaris delivered the X Window System software in the /usr/openwin hierarchy, with subdirs mirroring /usr - /usr/openwin/lib, /usr/openwin/bin, etc. ASARC/1996/268 noted that the differing install locations made it hard for users to compile software written for other platforms, so created symlinks from /usr/lib to /usr/openwin/lib, and /usr/include/X11 to /usr/openwin/include/X11, for the public libraries headers. (It notes From the customers that I have dealt with, they feel like *all* APIs belong in /usr/lib, /usr/include, and that Sun was just annoying and foolish for being different. but it took many years for Sun to take that advice to heart.) PSARC 2004/187 established /usr/X11 as the hierarchy for the X Window System software on Solaris, and began to phase out /usr/openwin. PSARC 2008/405 case declared /usr/openwin as Obsolete and removed the /usr/openwin hierarchy from the filesystem, leaving a symbolic link to /usr/X11 in its place for backwards compatibility. Numerous other ARC cases have established that /usr/bin /usr/lib are now the primary installation location for public binaries libraries on Solaris OpenSolaris, and that subsystem-specific hierarchies are now discouraged for commonly-used software. Change: --- This case declares /usr/X11 as Obsolete and allows any files currently delivered there to be delivered to the equivalent location under /usr. Moves of individual files may be considered ARC Self-Review, with a patch release binding, and not require ARC cases as long as they follow these rules: - Symbolic links from the /usr/X11 locations to the /usr locations must be delivered for any public interfaces. - Delivery to the normal Solaris locations, following the guidelines of the Recommended Installation Locations for Solaris-compatible Software Components ARC Best Practice document and this case. Specifically, the major directory mappings will be: Previous location: New location: /usr/X11/bin/usr/bin /usr/X11/demo /usr/bin /usr/X11/include/usr/include /usr/X11/lib/usr/lib /usr/X11/lib/modules/usr/lib/xorg/modules /usr/X11/lib/X11/app-defaults /usr/share/X11/app-defaults /usr/X11/lib/X11/fonts /usr/share/fonts /usr/X11/lib/X11/xkb/usr/share/X11/xkb /usr/X11/lib/X11/xserver/usr/lib/xorg /usr/X11/share /usr/share /usr/X11/share/man /usr/share/man A future case may remove the /usr/X11 hierarchy completely, and leave a single /usr/X11 - /usr symlink, as 2008/405 did for /usr/openwin, but there are many dependencies to resolve first. The /etc/X11 directory is not affected by this case, and will remain as-is. Rationale/Discussion: - We've had links from /usr/lib to /usr/X11/lib for the libraries since Solaris 2.6, so they'd be in the default path and not require -L or -R at build time, for easier compiling, so that would just replace the links with the real libraries. The programs and man pages would move into the same directories as gnome and the rest of the system, instead of being off in their own world, and one of the last parts of the system left in a separate subhierarchy of the filesystem. Having a separate /usr/X11R5 or /usr/X11R6 made more sense in the days when those were built and installed from a single source tree, so if you wanted a different version or a customized version, you built the entire window system and replaced the entire directory. And when we shipped SPARCstation 1's with 105Mb hard disks, being able to put /usr/openwin on a separate partition (local or remote) was crucial. But today, it just makes X different and harder to find and use. Since the LSB/FHS only allowed /usr/X11R6 as an exception to their everything under /usr, not /usr/foo rule, when the Linux distros moved to X11R7, they moved X into /usr/bin, /usr/lib, etc. Since X11R7 was also the release in which we split the X source tree
[xwin-discuss] Obsolescence of /usr/X11 [PSARC/2009/482 FastTrack timeout 09/17/2009]
Martin Bochnig wrote: I guess only the pkgdefs will be changed? Yes. Or are there plans to one day incorporate xwin into the OS/Net consolidation gate? Probably not. Not even remotely considering it, but that's completely unrelated - there's already many consolidations delivering files to /usr/bin /usr/lib, ON is in the minority there - some are already from X (the existing symlinks noted, the files for freetype fontconfig). Too much speaks against this. But in theory it could be done. Based on what criteria have previous decisions (maybe of less scale) been made? By whom? Merging consolidations? By the people who would be doing the work and responsible for maintaining it. The criteria here would be Does it make sense? and the answer is clearly no - the cost would be too high, the benefit non-existent. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
[xwin-discuss] Obsolescence of /usr/X11 [PSARC/2009/482 FastTrack timeout 09/17/2009]
Martin Bochnig wrote: I thought of it only because of Moinaks auto-builder (and my own insufficient steps towards that direction a year ago). Not combining consolidations for development purposes, just for allowing external distributors to build _everything_ in one rush, without interaction and during sleep. That would be a multi-day build, and adding X would still leave massive amounts outside (SFW, GNOME, Mozilla, etc.). I still do not understand all aspects of how Sun does this internally. Every consolidation generates packages individually and just delivers them into a spool area? Yes. Is there no automated A-to-Z tool, that compiles everything at once and then automatically combines the binary packages into a distro via distro-constructor (or in the past: How was it done for SXCE?). No. SXCE is built by combining the packages each consolidation delivers to the common WOS dock.OpenSolaris is currently built by converting the SVR4 packages in that dock to IPS packages, with some transformations along the way (the distro-import section of the IPS gate) - after the SXCE builds stop, consolidations will start converting to delivering IPS packages to a common repository. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
[xwin-discuss] Obsolescence of /usr/X11 [PSARC/2009/482 FastTrack timeout 09/17/2009]
Martin Bochnig wrote: Wouldnt it be cheaper if all used the same? Not after the huge cleaning bill we'd have to pay to clean up all the blood spilled in the spec files vs. ON-style makefiles deathmatch trying to decide which one to use, and the years of effort converting all the other consolidations to the one winner. This is why IPS doesn't include a package build system, we can't all agree on just one. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Public linked lists [PSARC/2009/476 FastTrack timeout 09/15/2009]
Garrett D'Amore wrote: These days with CTF they are completely unnecessary. CTF is Consolidation Private, and only available to things built in the ON consolidation, so it's not a useful replacement for anything. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Fast reboot support of GNOME restart dialog [LSARC/2009/454 FastTrack timeout 09/01/2009]
Jedy Wang wrote: Sorry if it wasn't clear, but as I see it, there is no need to check SMF and do something based on the result. Just reboot (or 'init 6'), and the right thing will occur. I don't see that an extra button to decide if fast or BIOS/Prom is necessary, as the vast majority of users either won't care or won't understand the difference (and the latter will only add to their confusion). Hi Randy, I do not think the option is not necessary. There are several student intents in the Desktop QE team who work on testing wondering how they can reboot to grub and enter another BE. So is it really a menu they want of BE's that the command should beactivate before rebooting, so they don't have to wait for the right moment to choose one in grub? -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Label Builder CLI [LSARC/2009/457 FastTrack timeout 08/31/2009]
John Fischer wrote: $ tsoltjds-getlabel --min=admin_low --max=admin_low \ Between our usual advice to not embed branding names in commands, because the commands almost always outlast the brand name, and the knowledge we're already moving away from JDS as a brand name for the desktop, it seems strange to be making new commands with the jds name in. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Firefox 3.5.x on S10 [LSARC/2009/446 FastTrack timeout 08/27/2009]
Hemantha Holla wrote:
Alan Coopersmith wrote:
Hemantha Holla wrote:
Alan Coopersmith wrote:
(though you need to be cleaning
either LD_LIBRARY_PATH variant from the environment you use to
fork/exec()
other processes, so you don't break existing gnome apps if you call
them
as external file viewer helpers).
Since this env variable will be only set, instead of being exported, any
spawned processes will not be poisoned with the private libraries.
If it's not exported, it won't even affect the Firefox binary, so that
doesn't make sense.
I am sorry; I misunderstood launching Firefox like this
LD_LIBRARY_PATH_32=/usr/lib/gnome-private/lib $prog ${1+$@}
to mean that LD_LIBRARY_PATH_32 is only set and not exported.
That causes it to be exported in the environment of $prog and it's children, but
not other processes started in the shell script.
Actually LD_LIBRARY_PATH* needn't be set to run Firefox. Since RUNPATH
is set to /usr/lib/gnome-private/lib while building Firefox and the
newer GNOME components, Firefox will pick up the new versions even
without setting LD_LIBRARY_PATH.
So instead of setting LD_LIBRARY_PATH, will unsetting it if user has
already set it, be enough to prevent this attack ?
If you don't need to set it, the best solution would be to just remove
the shell script code to set it, and let any setting from the environment
pass through on it's own. This isn't an attack, just preventing the
path you set from affecting other processes - if you don't set one, then
that's not a problem.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
ConsoleKit [LSARC/2009/432 OnePager]
Brian Cameron wrote: Alan: - Alan Coopersmith asked why some scripts are installed to /usr/lib and others to /usr/lib/ConsoleKit/scripts. The difference is that the files installs to /usr/lib are libexec programs which would normally be installed to /usr/libexec on Linux. So will you be putting them all under /usr/lib/ConsoleKit or not? Currently the ConsoleKit pkgconfig file does not expose the libexecdir that ConsoleKit is configured with, so other modules (such as GDM) can't easily figure out that they are installed to a non-standard directory. So how is it finding them when they're not installed under libexec? Therefore, I do not plan to make this change unless it would otherwise cause a TCR/TCA. I don't think it's worth a TCR, would just be nicer to be consistent. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Firefox 3.5.x on S10 [LSARC/2009/446 FastTrack timeout 08/27/2009]
Hemantha Holla wrote: Alan Coopersmith wrote: (though you need to be cleaning either LD_LIBRARY_PATH variant from the environment you use to fork/exec() other processes, so you don't break existing gnome apps if you call them as external file viewer helpers). Since this env variable will be only set, instead of being exported, any spawned processes will not be poisoned with the private libraries. If it's not exported, it won't even affect the Firefox binary, so that doesn't make sense. The following list seem like things needed to build firefox, but which don't need to be shipped to users of firefox - is there some reason these are needed, or is it just an artifact of the spec-files build system? (Though it would seem easy enough to just not deliver the -devel packages for private components to the WOS.) Some other teams have requested availability of some of the newer libraries through contracts. These files will allow those teams to link to the newer versions easily. If there is some other formal way in which these can be made available to those teams, there is no need to ship the -devel packages. You can deliver the -devel packages to those teams without delivering them to all customers, or you can deliver them to the WOS and accept that customers may see them and try using them. (The -private in the directory name should be a strong clue that they shouldn't expect support for them.) -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
EOF of redxblue [LSARC/2009/450 Self Review]
I am sponsoring this case for Stuart Kreitman and have marked it closed approved automatic - should anyone think this needs discussion, please ask and it will be converted to a fasttrack. As usual, the release binding is Patch for the announcement of obsolecence, and Minor for the removal. -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: EOF of redxblue 1.2. Name of Document Author/Supplier: Author: Stuart Kreitman 1.3 Date of This Document: 19 August, 2009 4. Technical Description * redxblue.c - Converts a RGB (24-bit) format rasterfile to a BGR one or * a XRGB (32-bit) format rasterfile to a XBGR one, or vice versa. It * does this by switching the red and blue bytes. redxblue is a utility to produce xBGR Sun Rasterfiles from xRGB format. We know of no users of this utility outside of Xsun splash image generation from archived images. All of these components will not be needed when the Xsun EOL is completed. The convert(1) utility, a component of ImageMagick is the recommended replacement utility. It provides translation and manipulation of all contemporary image file types. This case announces the EOF of, and removes, the redxblue utility and documentation. Exported Interfaces: Patch Release: /usr/openwin/bin/redxblue SUNWxwoptObsolete Minor Release: /usr/openwin/bin/redxblue SUNWxwoptRemoved /usr/openwin/share/man/man1/redxblue.1 SUNWxwmanRemoved 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: X Consolidation / Desktop C-Team 6.5. ARC review type: Automatic 6.6. ARC Exposure: open
ConsoleKit [LSARC/2009/432 OnePager]
Brian Cameron wrote: - Alan Coopersmith asked why some scripts are installed to /usr/lib and others to /usr/lib/ConsoleKit/scripts. The difference is that the files installs to /usr/lib are libexec programs which would normally be installed to /usr/libexec on Linux. So will you be putting them all under /usr/lib/ConsoleKit or not? -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
Firefox 3.5.x on S10 [LSARC/2009/446 FastTrack timeout 08/27/2009]
and pc file
/usr/lib/gnome-private/lib/pkgconfig/libglade-2.0.pc
and pc file
/usr/lib/gnome-private/lib/${MACH64}/pkgconfig/libglade-2.0.pc
/usr/lib/gnome-private/lib/pkgconfig/libgnomecanvas-2.0.pc
and pc file
/usr/lib/gnome-private/bin/pkg-config Project private
pkg-config 0.23
/usr/lib/gnome-private/bin/intltool-extract Project Private
intltool 0.40.5
/usr/lib/gnome-private/bin/intltool-merge
/usr/lib/gnome-private/bin/intltool-prepare
/usr/lib/gnome-private/bin/intltool-update
/usr/lib/gnome-private/bin/intltoolize
/usr/lib/gnome-private/bin/gtkdoc-check Project Private
gtk-doc 1.10 binaries
/usr/lib/gnome-private/bin/gtkdoc-depscan
and pc file
/usr/lib/gnome-private/bin/gtkdoc-fixxref
/usr/lib/gnome-private/bin/gtkdoc-mkdb
/usr/lib/gnome-private/bin/gtkdoc-mkhtml
/usr/lib/gnome-private/bin/gtkdoc-mkman
/usr/lib/gnome-private/bin/gtkdoc-mktmpl
/usr/lib/gnome-private/bin/gtkdoc-rebase
/usr/lib/gnome-private/bin/gtkdoc-scan
/usr/lib/gnome-private/bin/gtkdoc-scangobj
/usr/lib/gnome-private/bin/gtkdoc-scanobj
/usr/lib/gnome-private/bin/gtkdocize
/usr/lib/gnome-private/share/pkgconfig/gtk-doc.pc
SUNWdbus-priv-devel dbus-glib libraries
SUNWdbus-bindings-priv-devel
SUNWgnome-base-libs-priv-devel glib, cairo, atk and pango
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager]
Brian Cameron wrote: - Alan Coopersmith raised the issue that we need a follow-up case to EOL CDE Login. Personally I think that it would make more sense if the engineers within the Desktop team who are responsible for CDE login were to follow-up with such a case. It would be better, I think, if those people who best understand how CDE login works were to be responsible for such a case and answering questions about how the transition will be managed, etc. While EOL'ing dtlogin can be a separate case, this case must go forward with gdm as default, since we know that has happened without ARC review already. Things that were treated in previous gdm ARC cases as advice of before gdm becomes the default login screen must be treated as TCR's or TCA's for the now that gdm is default get-well plan. Pretending that gdm is not default is irresponsible and ignoring the reality of our existing OpenSolaris releases, and all Nevada builds 128 and later. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
daemon() in libc [PSARC/2009/444 FastTrack timeout 08/24/2009]
Joerg Schilling wrote: Vladimir Kotal Vladimir.Kotal at sun.com wrote: It's older and more common than that. It's a BSD-ism. Yep, the beast is quite old. The daemon() function is present in libc sources of 4.4BSD-Lite with a date of 1993. It can be also found in 4.3BSD-Reno with a date of 1990 but not in libc (in libutil). SunOS was never based on 4.3 but on 4.2 + additions from 4.3 Did you check the SCCS when it appeared first? That is not relevant to this case. It is sufficient to know that it has been in BSD Linux libc for many years. Exact dates are historical trivia, and don't affect whether it's a good idea to ship it now. (What version SunOS was based on is even more irrelevant, since we're not talking about modifying SunOS, or using SunOS as historical precedent.) -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
daemon() in libc [PSARC/2009/444 FastTrack timeout 08/24/2009]
Darren Reed wrote: One could argue that the original daemon() does not offer much flexibility and that this approach to daemonization is actually not sufficient in SMF world. While this is true, it is out of scope of this case to provide modern alternative. While providing an alternative interface is both out-of-scope, and missing the point of providing a BSD/Linux compatible interface, have you discussed with the SMF team whether daemon() should be putting the process into a new process contract? -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
daemon() in libc [PSARC/2009/444 FastTrack timeout 08/24/2009]
Garrett D'Amore wrote: From what I could tell, the daemon() function is not present on Linux (glibc). http://www.kernel.org/doc/man-pages/online/pages/man3/daemon.3.html -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
