Move GNU tar to /usr/bin [PSARC/2007/628 FastTrack timeout 11/08/2007]
Don Cragun wrote: > There is also a GNU rmt command that will move from > /usr/sfw/libexec/grmt to /usr/libexec/rmt. We have no /usr/libexec this case appears to be precedent setting without detailing what the precedent for /usr/libexec is. I know we have /usr/sfw/libexec but that only has the above mentioned rmt and some gcc stuff. I can't approve this case without the rules for /usr/libexec being defined. Personally I do not think we should have /usr/libexec in Solaris we already have a huge amount of non .so content in /usr/lib including what on GNU systems goes in /usr/libexec. I think that this rmt could live in either /usr/gnu/libexec/rmt /usr/lib/grmt or similar, but not /usr/libexec - unless the rules are defined and we expect more than just this to live there. -- Darren J Moffat
vncviewer [LSARC 2007/625: fasttrack timeout 11/7/2007]
I'm happy with the need for this and vino. However I'm not at all happy with only a Volatile taxonomy. I think at very very least the pathname and the hostname:port needs to be Committed other options can be Volatile but I suspect some of them could be Committed too. -- Darren J Moffat
Move GNU tar to /usr/bin [PSARC/2007/628 FastTrack timeout 11/08/2007]
Darren J Moffat wrote: > Don Cragun wrote: > > There is also a GNU rmt command that will move from > > /usr/sfw/libexec/grmt to /usr/libexec/rmt. > > We have no /usr/libexec this case appears to be precedent setting > without detailing what the precedent for /usr/libexec is. There is _absolutely_ no need to have grmt as there is the rmt from the star package that is a superset of all other known rmt packages. ARC already decided to replace /etc/rmt by the rmt from star. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Move GNU tar to /usr/bin [PSARC/2007/628 FastTrack timeout 11/08/2007]
Don Cragun wrote: > 4.1 Details > > The actual binary moves from /usr/sfw/bin/gtar to /usr/bin/gtar. > A link is left behind from /usr/sfw/bin/gtar to /usr/bin/gtar. > In addition /usr/gnu/bin/tar will be a link to /usr/bin/gtar. > There is also a GNU rmt command that will move from > /usr/sfw/libexec/grmt to /usr/libexec/rmt. Please do not balcanize OpenSolaris! Instead of adding unneeded communication software better implement PSARC/2004/480 It contains the decision to replace /etc/rmt & /usr/sbin/rmt by the rmt program that comes with star. This program implements a superset of all known rmt implementations and is the only grant for compatibility. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Move GNU tar to /usr/bin [PSARC/2007/628 FastTrack timeout 11/08/2007]
Don Cragun writes: > There is also a GNU rmt command that will move from > /usr/sfw/libexec/grmt to /usr/libexec/rmt. What is "/usr/libexec"? There's no such thing on Solaris. Is this project intentionally proposing a new /usr entry? If so, I'd like to see a good definition of its semantics for the filesystem(5) page. Otherwise, I think this belongs in "/usr/lib", unless there's some technical reason to prefer "libexec." -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Move gdb from /usr/sfw/bin to /usr/bin [PSARC/2007/630 Self Review]
As an aside, has gcc already moved to /usr/bin? One nagging thought about moving the compilers to /usr/bin is that it seems to give a level of precedence to the GNU compilers and tools that is higher than we offer for our *own* tools (Studio). I.e. if gdb and gcc are in /usr/bin, then why not dbx and cc? I realize that this may not be the place to fully explore the idea of bundling Studio, but I'd hate for other parties to miscontrue this action as meaning our own Studio tools were "2nd class" on Solaris systems. -- Garrett Don Cragun wrote: > I am submitting this case for April Chin. > It seeks a minor release binding. > > I believe it qualifies for self review and am marking it closed > approved. If anyone disagrees, let me know and I will change it to a > fast track with the normal one week timer. > > Cheers, > Don > > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2007 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: >Move gdb from /usr/sfw/bin to /usr/bin > 1.2. Name of Document Author/Supplier: >Author: April Chin > 1.3 Date of This Document: > 01 November, 2007 > 4. Technical Description > > 4.1 Summary > > The GNU debugger, gdb, was initially introduced into Solaris with > PSARC/2005/423 Add g77, gdb and autoconf to WOS > > This project moves the gdb binary from /usr/sfw/bin to /usr/bin > and moves the gdb manpage from /usr/sfw/share/man to /usr/share/man. > > 4.2 Details > > /usr/sfw/bin/gdb will move to /usr/bin/gdb. A symbolic link > will be left behind from /usr/sfw/bin/gdb to the new location. > > The manpage /usr/sfw/share/man/man1/gdb.1 will move to > /usr/share/man/man1/gdb.1. > > > 5. References > PSARC/2005/423 Add g77, gdb and autoconf to WOS > PSARC 2007/345 Move GNU make to /usr/bin > PSARC 2004/742 Move gcc, gnumake, binutils and bison from CCD to WOS > PSARC 2005/185 Enabling Serendipitous Discovery > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > SFW > 6.5. ARC review type: Automatic > 6.6. ARC Exposure: open > >
Move gdb from /usr/sfw/bin to /usr/bin [PSARC/2007/630 Self Review]
On 02/11/2007, Garrett D'Amore wrote: > As an aside, has gcc already moved to /usr/bin? > > One nagging thought about moving the compilers to /usr/bin is that it > seems to give a level of precedence to the GNU compilers and tools that > is higher than we offer for our *own* tools (Studio). > > I.e. if gdb and gcc are in /usr/bin, then why not dbx and cc? > > I realize that this may not be the place to fully explore the idea of > bundling Studio, but I'd hate for other parties to miscontrue this > action as meaning our own Studio tools were "2nd class" on Solaris systems. One could argue that as long as Sun Studio isn't redistributable and isn't open source (like was promised 2 years ago by Schwartz) it is a second class citizen in the OpenSolaris community. I certainly feel like one when I'm using it sometimes (i.e. tarballs don't always include latest patches, etc.). -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "We don't have enough parallel universes to allow all uses of all junction types--in the absence of quantum computing the combinatorics are not in our favor..." --Larry Wall
Move GNU tar to /usr/bin [PSARC/2007/628 FastTrack timeout 11/08/2007]
> Is it unreasonable to suggest/recommend/request that the documentation be > edited for delivery into ON? This component will be delivered via SFW and not ON - and while I share the concern about the discrepancy in the name, we also try to avoid making gratuitous changes to the files delivered components by the consolidation. Admitted, this is perhaps a small enough change that warrants it being done but in general I would recommend against it (perhaps a better idea would be to patch the file with a small note at the beginning indicating it refers to GNU tar but I would leave that to the project team to decide). > Cool. Will the man page reference both /usr/bin/gtar and /usr/gnu/bin/tar as > alternative ways of getting to the same program? (I.e. this may be another > case where the documentation needs to be edited to reflect actuality.) > > I understand a desire to minimize changes relative to upstream sources, but I > think accuracy of the documentation trumps (or should trump) that concern. I think that should be left to the project team. dsc
Move gdb from /usr/sfw/bin to /usr/bin [PSARC/2007/630 Self Review]
> Date: Fri, 02 Nov 2007 09:35:23 -0700 > From: "Garrett D'Amore" > > As an aside, has gcc already moved to /usr/bin? > gcc is also on the list of SFW tools which will move to /usr/bin shortly. April
Move gdb from /usr/sfw/bin to /usr/bin [PSARC/2007/630 Self Review]
>As an aside, has gcc already moved to /usr/bin? > >One nagging thought about moving the compilers to /usr/bin is that it >seems to give a level of precedence to the GNU compilers and tools that >is higher than we offer for our *own* tools (Studio). > >I.e. if gdb and gcc are in /usr/bin, then why not dbx and cc? > >I realize that this may not be the place to fully explore the idea of >bundling Studio, but I'd hate for other parties to miscontrue this >action as meaning our own Studio tools were "2nd class" on Solaris systems. +1: the Solaris developer tools should install symlinks in /usr/bin (as per the decision to collapse /usr/ccs/bin into /usr/bin). Why did we get /usr/ucb/cc but never /usr/bin/cc. "Not this ARC case", clearly. Casper
Move GNU tar to /usr/bin [PSARC/2007/628 FastTrack timeout 11/08/2007]
>> I understand a desire to minimize changes relative to upstream sources, but >> I >> think accuracy of the documentation trumps (or should trump) that concern. > >I think that should be left to the project team. I think that's an architectural matter. Casper
Move gdb from /usr/sfw/bin to /usr/bin [PSARC/2007/630 Self Review]
> > As an aside, has gcc already moved to /usr/bin? > > > > gcc is also on the list of SFW tools which will move to /usr/bin shortly. If there's a list, I'd prefer to see it all as a single thing to see how it all plays together than one at a time where the big picture can be lost. Gary..
Move gdb from /usr/sfw/bin to /usr/bin [PSARC/2007/630 Self Review]
Gary Winiger wrote: >>> As an aside, has gcc already moved to /usr/bin? >>> >>> >> gcc is also on the list of SFW tools which will move to /usr/bin shortly. >> > > > If there's a list, I'd prefer to see it all as a single thing > to see how it all plays together than one at a time where the > big picture can be lost. > > Gary.. > +1. I don't see that we really need all these little fast track/auto-approvals, when one larger fast track (it would probably still qualify as such) to do them at once would suffice. -- Garrett
Move ant from /usr/sfw/bin to /usr/bin [PSARC/2007/629 Self Review]
> I am submitting this case for April Chin. > It seeks a minor release binding. > > I believe it qualifies for self review and am marking it closed > approved. If anyone disagrees, let me know and I will change it to a > fast track with the normal one week timer. Lets have the whole chunk. Is there some reason that these need to be done piece meal? Gary..
Move ant from /usr/sfw/bin to /usr/bin [PSARC/2007/629 Self Review]
> Lets have the whole chunk. Is there some reason that these > need to be done piece meal? If there isn't consider the recent ones derailed or waiting need spec until the big picture becomes available. I trust the case owner will choose between derail and waiting need spec and update the IAMs appropriately. If there is a reason, please state it. Perhaps it's to meet some critical business need, then please group those together and say what the need may be. Gary..
Move ant from /usr/sfw/bin to /usr/bin [PSARC/2007/629 Self Review]
>> I believe it qualifies for self review and am marking it closed >> approved. If anyone disagrees, let me know and I will change it to a >> fast track with the normal one week timer. > > Lets have the whole chunk. Is there some reason that these > need to be done piece meal? Do you mean a case for moving the contents of all of /usr/sfw out to their expected location? I've been intending to file an overall case covering such details but have been side-tracked as of late working on the Open^H^H^H^H The-release-that-shall-not-be-named :-) prototype so I haven't had the time to finalize the details of the overall case (given there are over 30,000 files to track down). So in the meantime, I suggested to April and the others doing the hard work to continue with the individual cases until I can finish tracking down the details for the overall case. Is there an issue with having these individual cases coming one-by-one? dsc
Move ant from /usr/sfw/bin to /usr/bin [PSARC/2007/629 Self Review]
>Date: Fri, 02 Nov 2007 10:02:13 -0800 (PST) >From: Gary Winiger > > Lets have the whole chunk. Is there some reason that these > need to be done piece meal? > >Gary.. Upper management wants to see weekly progress on OpenSolaris project issues. April, Basabi, Carol, Cindy, and Craig and lower management will get dinged on performance reviews if they wait to put them all in a single case when everything is ready at the end. However, I imagine that they could put together a list of utilities that are currently on the roadmap if it will help evaluate the little cases as they come through. - Don
Move ant from /usr/sfw/bin to /usr/bin [PSARC/2007/629 Self Review]
> If there isn't consider the recent ones derailed or waiting > need spec until the big picture becomes available. I trust > the case owner will choose between derail and waiting need > spec and update the IAMs appropriately. If there is a reason, > please state it. Perhaps it's to meet some critical business > need, then please group those together and say what the need > may be. The big picture is that the components delivered under /usr/sfw should instead be delivered in their "expected" locations per PSARC 2005/185 Enabling serendipitous discovery and other related cases including PSARC 2007/047 /usr/gnu The intent is to move the existing components that are under /usr/sfw and as I mentioned in an earlier email, there hasn't been an overall case that covers the whole wad due to time constraints and in my opinion, making progress on individual components made sense while waiting for a case that covers the rest. dsc
Move ant from /usr/sfw/bin to /usr/bin [PSARC/2007/629 Self Review]
> >> I believe it qualifies for self review and am marking it closed > >> approved. If anyone disagrees, let me know and I will change it to a > >> fast track with the normal one week timer. > > > > Lets have the whole chunk. Is there some reason that these > > need to be done piece meal? > > Do you mean a case for moving the contents of all of /usr/sfw out to > their expected location? I've been intending to file an overall case > covering such details but have been side-tracked as of late working on > the Open^H^H^H^H The-release-that-shall-not-be-named :-) prototype so I > haven't had the time to finalize the details of the overall case (given > there are over 30,000 files to track down). So in the meantime, I > suggested to April and the others doing the hard work to continue with > the individual cases until I can finish tracking down the details for > the overall case. > > Is there an issue with having these individual cases coming > one-by-one? Yup. That's my point. Particularly when they lead to questions of what are the other related components. Certainly we have some idea of chunks of related stuff, 30,000 individual cases seems the wrong way to do things. Perhaps some big picture proposal and then a here's the first chunk. Perhaps you're saying the big picture is alread there. "Let's get stuff to where folk will find it" -- Bart's case last year, or maybe earlier this year. I've no objections to moving the stuff to where it should have been all along (in retrospect), nor that it's self review, it's seeing things that appear related coming piece meal. Gary..
Move ant from /usr/sfw/bin to /usr/bin [PSARC/2007/629 Self Review]
> Upper management wants to see weekly progress on OpenSolaris project > issues. April, Basabi, Carol, Cindy, and Craig and lower management > will get dinged on performance reviews if they wait to put them all in > a single case when everything is ready at the end. I'm certainly not asking for anyone to be marked down on their performance. Upper management can't be that mico-managing, I'd expect they have some sort of end game in mind and have layed out an agreed to time line to get that end accomplished. > However, I imagine that they could put together a list of utilities > that are currently on the roadmap if it will help evaluate the little > cases as they come through. Sure. What's the end game and what are the incremental chunks, how do they relate to good architecture..? Gary..
2007/631 Class E IP Address Configuration
I'm sponsoring this self-reviewed case for Sangeeta Misra. Its state is closed approved automatic; please let me know if you'd like this run as a regular fasttrack. Class E IP Address Configuration Today ifconfig does not allow the configuration of addresses in the Class E range (240.0.0.0/4). For instance the following ifconfig commands fail : #ifconfig bge0 251.1.2.3/24 ifconfig: SIOCSLIFADDR: bge0: Cannot assign requested address # ifconfig ce0 248.53.129.24 up ifconfig: SIOCSLIFADDR: ce0: Cannot assign requested address In light of Internet draft, draft-fuller-240space-00.txt, the above command should be allowed (see CR 6605607.) Note that the draft does not specify a default netmask for Class E. Since the RIPv1 routing protocol does not handle CIDR, using /32 as the default netmask for Class E is the best solution to keep the code changes minimal and avoid bugs. This fasttrack is being submitted for two specific behavior changes: o The behavior of SIOCSLIFADDR ioctl needs to be modified to allow the setting of a class-E address. It currently returns EADDRNOTAVAIL when passed an address in the Class E range. o The route(1M) command currently assigns a default netmask of 255.255.255.0 to destinations in the Class E range as shown in the following example: # route add 248.53.129.0 192.168.81.25 add net 248.53.129.0: gateway 192.168.81.25 # route get 248.53.129.0 route to: 248.53.129.0 destination: 248.53.129.0 mask: 255.255.255.0 gateway: surya5 interface: bge0 flags: recvpipe sendpipe ssthreshrtt,ms rttvar,ms hopcount mtu expire 0 0 0 0 0 0 1500 0 This current behavior is wrong as per the route(1M) man page: If a subnet mask is not specified, the mask used is the sub- net mask of the output interface selected by the gateway address, if the classful network of the destination is the same as the classful network of the interface. Otherwise, the classful network mask for the destination address is used. Network addresses in the Class E range have no pre-defined netmask. Thus the route command's behavior should be changed so that when a mask is not specified for a IP address from Class E address block, /32 should be used as a default. Release binding requested: Patch
Move ant from /usr/sfw/bin to /usr/bin [PSARC/2007/629 Self Review]
> The big picture is that the components delivered under /usr/sfw should > instead be delivered in their "expected" locations per > > PSARC 2005/185 Enabling serendipitous discovery I guessed that. And 30,000 closed self reviews doesn't make sense to me. Are there really 30K thing in the /usr/sfw tree today? > and other related cases including > > PSARC 2007/047 /usr/gnu > > The intent is to move the existing components that are under /usr/sfw > and as I mentioned in an earlier email, there hasn't been an overall > case that covers the whole wad due to time constraints and in my > opinion, making progress on individual components made sense while > waiting for a case that covers the rest. I guess we're having email skew, I'll shut up for a while and work on my "Day Job". I think I've made my point of seeing the forrest rather than the trees. Gary..
2007/631 Class E IP Address Configuration
Sebastien Roy writes: > This fasttrack is being submitted for two specific behavior changes: Are there any macro changes to go along with this? What will inet_lnaof(), inet_netof(), and inet_makeaddr() do when faced with Class E addresses? I'm not sure this change is fully specified. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
2007/631 Class E IP Address Configuration
James Carlson wrote: > Sebastien Roy writes: >> This fasttrack is being submitted for two specific behavior changes: > > Are there any macro changes to go along with this? > > What will inet_lnaof(), inet_netof(), and inet_makeaddr() do when > faced with Class E addresses? > > I'm not sure this change is fully specified. Okay, in that case, this is a fasttrack which expires on Nov. 9th. I'll let Sangeeta answer your questions. -Seb
Move gdb from /usr/sfw/bin to /usr/bin [PSARC/2007/630 Self Review]
Casper.Dik at Sun.COM wrote: > +1: the Solaris developer tools should install symlinks in /usr/bin (as per > the decision to collapse /usr/ccs/bin into /usr/bin). > > Why did we get /usr/ucb/cc but never /usr/bin/cc. > > "Not this ARC case", clearly. In fact, it's an ARC case approved last year: LSARC/2006/280 Tools DVD for S10u2 I believe it's delivered in some installs, but not others, and don't know the details of which are which. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
2007/631 Class E IP Address Configuration
James Carlson wrote: >Sebastien Roy writes: > > >>This fasttrack is being submitted for two specific behavior changes: >> >> > >Are there any macro changes to go along with this > > Yes there is. Here is the difference between onnv and the fixed version: nptbld-x-52% diff -c /ws/onnv-clone/usr/src/uts/common/netinet/in.h in.h *** /ws/onnv-clone/usr/src/uts/common/netinet/in.h Tue Oct 30 23:09:28 2007--- in.hFri Nov 2 06:47:15 2007 *** *** 328,337 --- 328,348 #define IN_CLASSD_NET 0xf000U /* These aren't really */ #define IN_CLASSD_NSHIFT28 /* net and host fields, but */ #define IN_CLASSD_HOST 0x0fffU /* routing needn't know */ + + #define IN_CLASSE(i)(((i) & 0xf000U) == 0xf000U) + #define IN_CLASSE_NET 0xU + #define IN_MULTICAST(i) IN_CLASSD(i) + /* + * We have removed CLASS E checks from the kernel + * But we preserve these defines for userland in order + * to avoid compile breakage of some 3rd party piece of software + */ + #ifndef _KERNEL #define IN_EXPERIMENTAL(i) (((i) & 0xe000U) == 0xe000U) #define IN_BADCLASS(i) (((i) & 0xf000U) == 0xf000U) + #endif #define INADDR_ANY 0xU #define INADDR_LOOPBACK 0x7F01U >What will inet_lnaof(), inet_netof(), and inet_makeaddr() do when >faced with Class E addresses? > >I'm not sure this change is fully specified. > > > I had discussed this issue with Erik Nordmark(he is being cced)., He advised against changing code in the above functions as they are classful code ( given Class E is being defined as Classless) Sangeeta
2007/631 Class E IP Address Configuration
James Carlson wrote: > Sebastien Roy writes: >> This fasttrack is being submitted for two specific behavior changes: > > Are there any macro changes to go along with this? > > What will inet_lnaof(), inet_netof(), and inet_makeaddr() do when > faced with Class E addresses? Those routines assume classfull IP addresses, and such a thing was obsoleted when CIDR was introduced. There is no classfull mask associated with Class E, and if we tried to convince the IETF that they should pick one just so that the above (de-facto obsolete) routines can do something with Class E, I think folks would laugh at us and wonder why we haven't heard of CIDR yet. Thus the behavior of the above classfull routines is undefined with Class E. Should we make that be part of the specification/case? Erik
Move ant from /usr/sfw/bin to /usr/bin [PSARC/2007/629 Self Review]
Don Cragun wrote: >> Date: Fri, 02 Nov 2007 10:02:13 -0800 (PST) >> From: Gary Winiger >> >> Lets have the whole chunk. Is there some reason that these >> need to be done piece meal? >> >> Gary.. >> > > Upper management wants to see weekly progress on OpenSolaris project > issues. April, Basabi, Carol, Cindy, and Craig and lower management > will get dinged on performance reviews if they wait to put them all in > a single case when everything is ready at the end. > That sounds kind of crummy. But instead of waiting to do them all, maybe they could be "grouped" a bit more. Sending little bits of make-work one utility at a time still seems like the wrong way to go about this. > However, I imagine that they could put together a list of utilities > that are currently on the roadmap if it will help evaluate the little > cases as they come through. > Yes, please. - Garrett
Move ant from /usr/sfw/bin to /usr/bin [PSARC/2007/629 Self Review]
>Do you mean a case for moving the contents of all of /usr/sfw out to >their expected location? I've been intending to file an overall case >covering such details but have been side-tracked as of late working on >the Open^H^H^H^H The-release-that-shall-not-be-named :-) prototype so I >haven't had the time to finalize the details of the overall case (given >there are over 30,000 files to track down). So in the meantime, I >suggested to April and the others doing the hard work to continue with >the individual cases until I can finish tracking down the details for >the overall case. > >Is there an issue with having these individual cases coming >one-by-one? Yes, because it's just too much work and email to do it one by one. Is there a rule that an ARC case needs to delivered as one deliverable? If not, then put them in one case and make "staged delivery" part of the case. One important issue here is that the more cases like this we see, the less diligent we might become and then suddenly we WILL have /usr/libexec which, I think, we clearly do not want. Approving all target directories exactly once is in the best interest of both the project team and PSARC. Casper
2007/631 Class E IP Address Configuration
Erik Nordmark writes: > James Carlson wrote: > > Sebastien Roy writes: > >> This fasttrack is being submitted for two specific behavior changes: > > > > Are there any macro changes to go along with this? > > > > What will inet_lnaof(), inet_netof(), and inet_makeaddr() do when > > faced with Class E addresses? > > Those routines assume classfull IP addresses, and such a thing was > obsoleted when CIDR was introduced. > There is no classfull mask associated with Class E, and if we tried to > convince the IETF that they should pick one just so that the above > (de-facto obsolete) routines can do something with Class E, I think > folks would laugh at us and wonder why we haven't heard of CIDR yet. > > Thus the behavior of the above classfull routines is undefined with > Class E. Should we make that be part of the specification/case? That'd help make the case complete. The alternative would be to specify that they assume a /32 mask, just like everything else. That'd make them consistent. Your choice, but I'd probably opt for consistency. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
2007/631 Class E IP Address Configuration
Sangeeta Misra writes: > Yes there is. Here is the difference between onnv and the fixed version: I wasn't asking for a code review, but for a list of the new interfaces and stability that are proposed as part of this project. They appear to be: IN_CLASSE() Committed Macro in netinet/in.h IN_CLASSE_NET Committed Macro in netinet/in.h It looks like in.h(3HEAD) is in need of an update because it doesn't list the committed interfaces we offer. As yours is a small change, I won't hold you to it, but "it'd be nice to have." I'm not sure if the example code in getnetbyname(3SOCKET) needs an update, but you might want to take a quick look. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Move ant from /usr/sfw/bin to /usr/bin [PSARC/2007/629 Self Review]
Casper.Dik at Sun.COM writes: > Is there a rule that an ARC case needs to delivered as one deliverable? The ARC has no such rule, and does allow projects to specify whatever sort of delivery scheme is needed to satisfy the needs of the project. However, some consolidations do have their own rules about ARC citation that (unfortunately) require separate cases to be run. > One important issue here is that the more cases like this we see, the less > diligent we might become and then suddenly we WILL have /usr/libexec which, > I think, we clearly do not want. Yes, I agree. If we could get that one case, that'd be much better than 30,000 paper cuts. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Move GNU tar to /usr/bin [PSARC/2007/628 FastTrack timeout 11/08/2007]
Shouldn't this page have A LINE ADDED to it that tells the user that there are multiple tars on the system and where to look for them? -John David.Comay at Sun.COM wrote: >> IOW, wouldn't it make more sense to rename the info page to >> "gtar.info"? (Of course, that has its own implications for people >> working on Linux systems used to typing "info tar" you just can't win!) > > Perhaps it makes sense to also deliver a gtar.info but the information > in the file will still refer to just "tar". > >> Btw, the man pages have the same issue, right? They have to be gtar.1, >> not tar.1, to avoid collision with our Solaris versions. > > gtar.1 will be delivered under /usr/share/man. tar.1 will be delivered > under /usr/gnu/share/man as a link to gtar.1 > > dsc > ___ > opensolaris-arc mailing list > opensolaris-arc at opensolaris.org
Move GNU tar to /usr/bin [PSARC/2007/628 FastTrack timeout 11/08/2007]
Joerg Schilling wrote: > There is _absolutely_ no need to have grmt as there is the rmt from > the star package that is a superset of all other known rmt packages. > > ARC already decided to replace /etc/rmt by the rmt from star. > And when this integrates, there will be no issue. - jek3
Move GNU tar to /usr/bin [PSARC/2007/628 FastTrack timeout 11/08/2007]
Joseph Kowalski wrote: > Joerg Schilling wrote: > > There is _absolutely_ no need to have grmt as there is the rmt from > > the star package that is a superset of all other known rmt packages. > > > > ARC already decided to replace /etc/rmt by the rmt from star. > > > And when this integrates, there will be no issue. What do you understand by "this"? J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
2007/631 Class E IP Address Configuration
On Fri, 2007-11-02 at 11:01 -0700, Erik Nordmark wrote: > There is no classfull mask associated with Class E, and if we tried to > convince the IETF that they should pick one just so that the above > (de-facto obsolete) routines can do something with Class E, I think > folks would laugh at us and wonder why we haven't heard of CIDR yet. > > Thus the behavior of the above classfull routines is undefined with > Class E. Should we make that be part of the specification/case? I think that depends on how much remaining use there is of these functions. Saying that the entire behavior is "undefined" is too loose (but only because I remember the original implementation of #pragma in the GNU cpp). It would better to say that the functions use an unspecified value for the address mask. BTW, the current man pages make no mention of the "de-facto obsolete" status of those three functions -- we should probably declare inet_lnaof(), inet_netof(), and inet_makeaddr() Obsolete as part of this case. - Bill
2007/631 Class E IP Address Configuration
Bill Sommerfeld writes: > BTW, the current man pages make no mention of the "de-facto obsolete" > status of those three functions -- we should probably declare > inet_lnaof(), inet_netof(), and inet_makeaddr() Obsolete as part of this > case. In fact, if you can't come up with a clear definition of how these now-valid Class E cases should be handled, I'd argue that they _must_ be marked Obsolete. The only issue with that is that existing applications will be confused. I suppose that's just as well ... -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
2007/631 Class E IP Address Configuration
On Fri, 2007-11-02 at 16:13 -0400, James Carlson wrote: > In fact, if you can't come up with a clear definition of how these > now-valid Class E cases should be handled, I'd argue that they _must_ > be marked Obsolete. The long-standing realities of CIDR cause me to believe that they must be marked Obsolete even if someone picks a default netmask for class E. - Bill
2007/631 Class E IP Address Configuration
How will the configuration of class E addresses be handled by routed? The relevant document from the IETF appears to be: http://www.ietf.org/internet-drafts/draft-wilson-class-e-01.txt Can this draft please be included in the materials for this case? Eventually there will be an RFC for this but since we can't yet cite an RFC# (and drafts do expire), it would be good to include the relevant specification as it exists at this point in time. One issue with the specification is that it lists class E as extending from 240.0.0.0 - 255.255.255.255. 255.255.255.255 is today used as all-ones broadcast address. Darren
2007/631 Class E IP Address Configuration
Darren Reed wrote: > How will the configuration of class E addresses be handled by routed? > RIPV1 wont be able to handle Class E , but RIPv2 should ( in.routed has both version) I will be filing a seperate RFE for Quagga to handle Class E. > The relevant document from the IETF appears to be: > http://www.ietf.org/internet-drafts/draft-wilson-class-e-01.txt > > Can this draft please be included in the materials for this case? > > Eventually there will be an RFC for this but since we can't yet > cite an RFC# (and drafts do expire), it would be good to include > the relevant specification as it exists at this point in time. > OK. > One issue with the specification is that it lists class E as extending > from 240.0.0.0 - 255.255.255.255. 255.255.255.255 is today > used as all-ones broadcast address. I see the range to be 240.0.0.0 - 255.255.255.254 Sangeeta
Move gdb from /usr/sfw/bin to /usr/bin [PSARC/2007/630 Self Review]
Shawn Walker wrote: > On 02/11/2007, Garrett D'Amore wrote: > >> As an aside, has gcc already moved to /usr/bin? >> >> One nagging thought about moving the compilers to /usr/bin is that it >> seems to give a level of precedence to the GNU compilers and tools that >> is higher than we offer for our *own* tools (Studio). >> >> I.e. if gdb and gcc are in /usr/bin, then why not dbx and cc? >> >> I realize that this may not be the place to fully explore the idea of >> bundling Studio, but I'd hate for other parties to miscontrue this >> action as meaning our own Studio tools were "2nd class" on Solaris systems. >> > > One could argue that as long as Sun Studio isn't redistributable and > isn't open source (like was promised 2 years ago by Schwartz) it is a > second class citizen in the OpenSolaris community. I certainly feel > like one when I'm using it sometimes (i.e. tarballs don't always > include latest patches, etc.). > Which argues for Sun Studio being properly included in Solaris, even it it is not provided on OpenSolaris. Maybe I'm biased, but links such as /usr/bin/java -> ../jdk/ would be appropriate. This seems to work well for the DEVX releases becasue Sun Studio is bundled. Not so well for a vanilla Express. - jek3
Move GNU tar to /usr/bin [PSARC/2007/628 FastTrack timeout 11/08/2007]
Casper.Dik at Sun.COM wrote: > >>> I understand a desire to minimize changes relative to upstream sources, but >>> I >>> think accuracy of the documentation trumps (or should trump) that concern. >>> >> I think that should be left to the project team. >> > > I think that's an architectural matter. > +1
Move gdb from /usr/sfw/bin to /usr/bin [PSARC/2007/630 Self Review]
On 02/11/2007, Joseph Kowalski wrote: > Shawn Walker wrote: > > On 02/11/2007, Garrett D'Amore wrote: > > > >> As an aside, has gcc already moved to /usr/bin? > >> > >> One nagging thought about moving the compilers to /usr/bin is that it > >> seems to give a level of precedence to the GNU compilers and tools that > >> is higher than we offer for our *own* tools (Studio). > >> > >> I.e. if gdb and gcc are in /usr/bin, then why not dbx and cc? > >> > >> I realize that this may not be the place to fully explore the idea of > >> bundling Studio, but I'd hate for other parties to miscontrue this > >> action as meaning our own Studio tools were "2nd class" on Solaris systems. > >> > > > > One could argue that as long as Sun Studio isn't redistributable and > > isn't open source (like was promised 2 years ago by Schwartz) it is a > > second class citizen in the OpenSolaris community. I certainly feel > > like one when I'm using it sometimes (i.e. tarballs don't always > > include latest patches, etc.). > > > Which argues for Sun Studio being properly included in Solaris, even it > it is > not provided on OpenSolaris. > > Maybe I'm biased, but links such as /usr/bin/java -> ../jdk/ would > be appropriate. This seems to work well for the DEVX releases becasue > Sun Studio is bundled. Not so well for a vanilla Express. And especially not well in light of the fact that Express is supposed to be discontinued; leaving us with only a (*dear I hope) reference distribution. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "We don't have enough parallel universes to allow all uses of all junction types--in the absence of quantum computing the combinatorics are not in our favor..." --Larry Wall
Move ant from /usr/sfw/bin to /usr/bin [PSARC/2007/629 Self Review]
James Carlson wrote: > Casper.Dik at Sun.COM writes: >> Is there a rule that an ARC case needs to delivered as one deliverable? > > The ARC has no such rule, and does allow projects to specify whatever > sort of delivery scheme is needed to satisfy the needs of the project. There is an expectation (based on managing dependencies) that a project that won't be delivering at one time or in one place put that information IN THEIR ARC PROPOSAL so that ramifications (if any) can be understood. -John
Move gdb from /usr/sfw/bin to /usr/bin [PSARC/2007/630 Self Review]
Shawn Walker wrote: > On 02/11/2007, Joseph Kowalski wrote: > >> Shawn Walker wrote: >> >>> On 02/11/2007, Garrett D'Amore wrote: >>> >>> As an aside, has gcc already moved to /usr/bin? One nagging thought about moving the compilers to /usr/bin is that it seems to give a level of precedence to the GNU compilers and tools that is higher than we offer for our *own* tools (Studio). I.e. if gdb and gcc are in /usr/bin, then why not dbx and cc? I realize that this may not be the place to fully explore the idea of bundling Studio, but I'd hate for other parties to miscontrue this action as meaning our own Studio tools were "2nd class" on Solaris systems. >>> One could argue that as long as Sun Studio isn't redistributable and >>> isn't open source (like was promised 2 years ago by Schwartz) it is a >>> second class citizen in the OpenSolaris community. I certainly feel >>> like one when I'm using it sometimes (i.e. tarballs don't always >>> include latest patches, etc.). >>> >>> >> Which argues for Sun Studio being properly included in Solaris, even it >> it is >> not provided on OpenSolaris. >> >> Maybe I'm biased, but links such as /usr/bin/java -> ../jdk/ would >> be appropriate. This seems to work well for the DEVX releases becasue >> Sun Studio is bundled. Not so well for a vanilla Express. >> > > And especially not well in light of the fact that Express is supposed > to be discontinued; leaving us with only a (*dear > I hope) reference distribution. > Not so fast... Just 2 days ago Tim asserted that there will always be a difference between the Sun distribution and the OpenSolaris distribution. I believe these will mostly be additions. Besides, one great question to me is where OpenSolaris will get java? Sure, an distro can get either the Sun Java or (soon) the OpenJDK one, but it isn't owned by the OpenSolaris community. This is just a distro decision separable from a community. This seems to still be an open issue. Clearly, my suggestion only applies if a unique Sun distribution exists. - jek3
Caller context flags [PSARC/2007/632 FastTrack timeout 11/09/2007]
I'm sponsoring this fast-track for Jim Wahlig. This case seeks Minor binding.
Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
This information is Copyright 2007 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
Caller context flags
1.2. Name of Document Author/Supplier:
Author: Jim Wahlig
1.3 Date of This Document:
02 November, 2007
4. Technical Description
One of the uses of the caller_context structure is to pass information
between the caller of a vnode operation (VOP) and a File Event Monitor
(FEM). It is used by both NFS and CIFS servers.
Monitors often need to perform operations that would block the
caller. For example, an NFSv4 delegation monitor may need to
perform an over-the-wire operation to recall a delegation. The
problem is that the caller may not be in a position to block and
has no way to communicate that state to the monitor.
Proposed Solution
This case proposes to add a flags field (cc_flags) to the caller_context
structure as well as values to communicate the behavior needed by the
caller.
The new caller context structure looks like this:
typedef struct caller_context {
pid_t cc_pid; /* Process ID of the caller */
int cc_sysid; /* System ID, used for remote calls */
u_longlong_tcc_caller_id; /* Identifier for (set of) caller(s) */
uint64_tcc_flags; <-- NEW FLAG FIELD
} caller_context_t;
The first two new flags to be defined:
#define CC_WOULDBLOCK 0x1 /* set upon return by monitor */
#define CC_DONTBLOCK0x2 /* set by caller */
The caller sets CC_DONTBLOCK in cc_flags to direct the monitor not to
perform an operation that might block. In the case where a monitor would
perform a blocking operation and CC_DONTBLOCK is set, the monitor
sets CC_WOULDBLOCK in the cc_flags and returns EAGAIN to the caller.
The first consumer of this new field would be the NFS server. The flags
passed would inform the monitors on delegated files whether to wait for
the delegation to be returned or just kick off the recall and return
an error. The NFS server will set CC_DONTBLOCK to inform the
delegation monitors not to wait for a delegation to be returned when
there is a conflict. Instead, the monitors will return EAGAIN and set
the CC_WOULDBLOCK flag after issuing the delegation recall.
Exported Interfaces
||
Interface Name | Classification | Comments
=
||
CC_WOULDBLOCK | consolidation | set when returning EAGAIN to an op
| private| that would have been blocked.
||
CC_DONTBLOCK || set by caller to indicate that op's
|| should not block.
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
PSARC/2007/617 p7zip 4.55
I'm sponsoring the following fast-track for myself. I'm setting the time-out to one week from today: November 9, 2007. Release binding is Patch due to the desire to include this in the S10 updates. Thanks, Danek === 1. Background This project proposes to integrate p7zip[1,2], a freeware archiving and compression utility. It is similar in usage to zip, as opposed to gzip or tar, and compresses as well as archives. The compression algorithm is LZMA[3], which, compared to bzip2, generally gives higher compression ratios, and is generally more cpu and memory friendly on decompression. These factors are the primary motivators for inclusion in Solaris; in particular, delivery of S10, Update 5 is at risk due to the size of the CD1 image, and compressing the packages more than they are currently is desired. In addition, it should provide some relief to customers in terms of reduced CPU usage during installation and upgrade. This project requests a Patch binding due to its binding to the updates. It intends to integrate into the SFW consolidation. 2. Architecture The architecture, as relevant to integration in Solaris is simple. There are three executables: 7z, 7za, and 7zr. The first is the most general. It supports multiple archive and compression formats through shared-object plugins. 7za does not use any plugins, and hence supports fewer formats. 7zr is even further reduced, supporting only the 7z archive and compression formats. Despite the non-obvious utility of 7za and 7zr on modern systems, all three executables are being delivered in order to meet expectations of users of p7zip on other platforms, where all three are provided. For the purposes of this ARC case, however, only the 7z archive format and LZMA compression algorithms are supported. Bzip2, gzip, zip, rar, tar, cpio, and its myriad other capabilities will likely be present, but their presence will not be guaranteed on an ongoing basis. As a caution to anyone who uses 7z, it is not useful as a general purpose archiver on unix systems, as it does not store user and group permissions. This is thanks to its Windows heritage. However, there is no issue with its usage for compression of individual files. For those interested in the actual archive format (and others available), compression, commandline options, and other features, the man pages are available in the materials directory of this case, and more information yet may be found at [1]. All exported interfaces not mentioned in section 3 below are considered Volatile. 3. Exported Interfaces SUNWp7zip Uncommitted Package name /usr/bin/7z CommittedExecutable location /usr/bin/7za Uncommitted Executable location /usr/bin/7zr Uncommitted Executable location 7z, 7za, 7zr Uncommitted Commandline syntax /usr/lib/7z Project Private Plugin directory 4. References [1] http://www.7-zip.org/ [2] http://p7zip.sourceforge.net/ [3] http://en.wikipedia.org/wiki/Lempel-Ziv-Markov_algorithm
PSARC/2007/617 p7zip 4.55
Danek Duvall wrote: > I'm sponsoring the following fast-track for myself. I'm setting the > time-out to one week from today: November 9, 2007. Release binding is > Patch due to the desire to include this in the S10 updates. > > Thanks, > Danek > > === > > 1. Background > > This project proposes to integrate p7zip[1,2], a freeware archiving > and compression utility. It is similar in usage to zip, as opposed > to gzip or tar, and compresses as well as archives. The compression > algorithm is LZMA[3], which, compared to bzip2, generally gives > higher compression ratios, and is generally more cpu and memory > friendly on decompression. I hope the p7zip binary will be included, it is needed by star. I also hope that someone creates a version that _really_ deals with stdin/stdout and delivers a compress(1) compatible interface. The current "p7zip" is a shell script that creates an intermediate /tmp/ file. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
PSARC/2007/617 p7zip 4.55
On Fri, Nov 02, 2007 at 11:27:08PM +0100, Joerg Schilling wrote: > I hope the p7zip binary will be included, it is needed by star. "binary"? You do mean the script, like you talk about later, right? I can do that. Consider /usr/bin/p7zipUncommitted Executable location added to the interface table. I've put the man page in the materials directory with the rest. > I also hope that someone creates a version that _really_ deals with > stdin/stdout > and delivers a compress(1) compatible interface. You'll have to talk to the upstream maintainers to fix that. Thanks, Danek
PSARC/2007/617 p7zip 4.55
Danek Duvall wrote: > On Fri, Nov 02, 2007 at 11:27:08PM +0100, Joerg Schilling wrote: > > > I hope the p7zip binary will be included, it is needed by star. > > "binary"? You do mean the script, like you talk about later, right? I can > do that. I am talking about the script, but I would like to see something better. I am not sure whether I had to modify the script to make it work. I have to fetch an original version again... Anyway, an executable "p7zip" in PATH allows star to automatically unpack 7z compressed tar archives. > Consider > >/usr/bin/p7zipUncommitted Executable location > > added to the interface table. I've put the man page in the materials > directory with the rest. > > > I also hope that someone creates a version that _really_ deals with > > stdin/stdout > > and delivers a compress(1) compatible interface. > > You'll have to talk to the upstream maintainers to fix that. I believe I did but I did not get an answer. J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de(uni) schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
PSARC/2007/617 p7zip 4.55
On Fri, 2007-11-02 at 15:15 -0700, Danek Duvall wrote: > There are three executables: 7z, 7za, and 7zr. The first is the > most general. It supports multiple archive and compression formats > through shared-object plugins. 7za does not use any plugins, and > hence supports fewer formats. 7zr is even further reduced, > supporting only the 7z archive and compression formats. ... > For the purposes of this ARC case, however, only the 7z archive > format and LZMA compression algorithms are supported. Bzip2, gzip, > zip, rar, tar, cpio, and its myriad other capabilities will likely > be present, but their presence will not be guaranteed on an ongoing > basis. Given this caveat, why not make "7zr" the "Committed" variant and have 7z and 7za be "Uncommitted"? - Bill
PSARC/2007/617 p7zip 4.55
On Fri, Nov 02, 2007 at 06:50:06PM -0400, Bill Sommerfeld wrote: > On Fri, 2007-11-02 at 15:15 -0700, Danek Duvall wrote: > > There are three executables: 7z, 7za, and 7zr. The first is the > > most general. It supports multiple archive and compression formats > > through shared-object plugins. 7za does not use any plugins, and > > hence supports fewer formats. 7zr is even further reduced, > > supporting only the 7z archive and compression formats. > ... > > For the purposes of this ARC case, however, only the 7z archive > > format and LZMA compression algorithms are supported. Bzip2, gzip, > > zip, rar, tar, cpio, and its myriad other capabilities will likely > > be present, but their presence will not be guaranteed on an ongoing > > basis. > > Given this caveat, why not make "7zr" the "Committed" variant and have > 7z and 7za be "Uncommitted"? I want to commit to the executable name which most people expect (and is thus the least likely to disappear from upstream), and I believe that the more common commandline invocation is 7z. If anyone has data to the contrary, I'm more than happy to switch the stability classifications. Danek
2007/631 Class E IP Address Configuration
Sangeeta Misra wrote: > Darren Reed wrote: > >> How will the configuration of class E addresses be handled by routed? >> > > RIPV1 wont be able to handle Class E , but RIPv2 should ( in.routed > has both version) I will be filing a seperate RFE for Quagga to handle > Class E. So this means in.routed will be modified to only announce configured class E networks using RIPv2? >> The relevant document from the IETF appears to be: >> http://www.ietf.org/internet-drafts/draft-wilson-class-e-01.txt >> >> Can this draft please be included in the materials for this case? >> >> Eventually there will be an RFC for this but since we can't yet >> cite an RFC# (and drafts do expire), it would be good to include >> the relevant specification as it exists at this point in time. >> > OK. > >> One issue with the specification is that it lists class E as extending >> from 240.0.0.0 - 255.255.255.255. 255.255.255.255 is today >> used as all-ones broadcast address. > > I see the range to be 240.0.0.0 - 255.255.255.254 This seems to be in contrast with what the Internet draft above says, in that the class E space being made available for private use is 240.0.0.0/4 (or 240.0.0.0 - 255.255.255.255.) If I do "ifconfig ce0 240.0.2.1 netmask 255.0.0.0 up" happens, how will the system respond to ping packets addressed to 255.255.255.255 on other network interfaces? With the other inet_* functions being announced as obsolete, should we be thinking about doing the same for inet_addr() (255.255.255.255 will be a valid address after this) ? Darren
More compatibility with GNU gettext in gettext(3c) [PSARC/2007/634 FastTrack timeout 11/09/2007]
I am sponsoring this fast track for Kenjiro Tsuji. It times out on Friday, November 9th. New and updated man pages are in the case's materials directory. This case seeks a patch binding so it will be possible to port this work back into a Solaris 10 update although there are no plans to do so at this time. The updates provided here are fully backwards compatible with version 0.0, so existing applications should not be adversly affected by this update to version 1.0. (For those of you who have been involved in recent cases moving stuff from /usr/sfw into /usr/bin, this case is not related to those cases. This case merely updates the version of GNU gettext() related functions to match current technology. Another related case will be filed soon; there are two cases rather than one because this case delivers changes into the ON consolidation while the other case will deliever changes into the SFW consolidation.) Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: More compatibility with GNU gettext in gettext(3c) 1.2. Name of Document Author/Supplier: Author: Kenjiro Tsuji 1.3 Date of This Document: 02 November, 2007 2. Project Summary 2.1. Project Description The current Solaris libc supports the GNU gettext feature that was introduced by PSARC/2001/072 [1]. The version number of the supported GNU MO file format is 0.0. The GNU gettext package has been updated to bump the MO version number up to 1.0. This project makes the GNU gettext feature in libc more compatible with the GNU gettext package by supporting version 1.0 of the GNU MO file format. Patch release binding is requested. 3. Technical Description In addition to supporting version 1.0 of the GNU MO file format in the gettext(3c) family of functions in libc, the following items will be also updated: - Adding __GNU_GETTEXT_SUPPORTED_REVISION() macro into /usr/include/libintl.h. This macro is required to tell the GNU packages that the Solaris runtime supports the GNU gettext feature. A new manpage for libintl.h(3HEAD) will be created for this change. - Adding the following two symbols into libc: _nl_msg_cat_cntr _nl_domain_bindings These symbols are also required to tell the GNU packages that the Solaris runtime supports the GNU gettext feature. The gettext(3C) manpage will be updated for this change. Enhancements to make the utilities in the GNU gettext package available on Solaris systems will be handled in a separate PSARC case. 4. Interfaces Exported interface Classification Interface type === == == __GNU_GETTEXT_SUPPORTED_REVISION() Uncommitted macro in _nl_msg_cat_cntrUncommitted symbol in libc _nl_domain_bindings Uncommitted symbol in libc 5. References [1] Kenjiro Tsuji, PSARC/2001/072: GNU gettext support 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
GNU gettext 0.16.1 [PSARC/2007/635 FastTrack timeout 11/09/2007]
I am submitting this fast track for Kenjiro Tsuji. It times out on Friday, November 9th. This case seeks a patch binding so it will be possible to port this work back into a Solaris 10 update although there are no plans to do so at this time. (For those of you who have been involved in recent cases moving stuff from /usr/sfw into /usr/bin, this case is not related to those cases. This case adds new GNU utilities to /usr/bin that had never been in /usr/sfw/bin and creates a few symlihks in /usr/sfw for utilities that have had a 'g' added to the start of their names in /usr/bin to avoid clashes with other utilities already present in /usr/bin. PSARC/2007/634 was recently submitted and is closely related to this case. There are two cases rather than one because this case delivers changes into the SFW consolidation while the other case will deliever changes into the ON consolidation.) Sincerely, Don Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: GNU gettext 0.16.1 1.2. Name of Document Author/Supplier: Author: Kenjiro Tsuji 1.3 Date of This Document: 02 November, 2007 2. Project Summary 2.1. Project Description This project introduces the utilities in version 0.16.1 of the GNU gettext package into the Solaris WOS. Patch release binding is requested. 4. Technical Description The GNU gettext package is a set of utilities for handling message files for the GNU gettext and the runtime support. Solaris systems already offer some of those utilities (/usr/bin/msgfmt, /usr/bin/gettext, and /usr/bin/xgettext). This proposal will install the GNU utilities corresponding to them into /usr/bin/ with a 'g' prefix and install symbolic links to them into /usr/gnu/bin/ without the 'g' prefix. The remaining GNU gettext package utilities (envsubst, msgattrib, msgcat, msgcmp, msgcomm, msgconv, msgen, msgexec, msgfilter, msggrep, msginit, msgmerge, msgunfmt, msguniq, and ngettext) are not currently present on Solaris systems. To provide better GNU environment compatibility, these utilities will be installed into /usr/bin/ without a 'g' prefix. Runtime support for the utilities in this project is provided by PSARC/2007/634 (More compatibility with GNU gettext in gettext(3c)). This project, therefore, has a dependency on PSARC/2007/634 and must not integrate before it. 5. Interfaces Exported interface Classification Interface type === == == SUNWgnu-gettext Uncommitted Package name /usr/bin/envsubst Uncommitted Command /usr/bin/ggettext Uncommitted Command /usr/bin/gmsgfmtUncommitted Command /usr/bin/gxgettext Uncommitted Command /usr/bin/msgattrib Uncommitted Command /usr/bin/msgcat Uncommitted Command /usr/bin/msgcmp Uncommitted Command /usr/bin/msgcommUncommitted Command /usr/bin/msgconvUncommitted Command /usr/bin/msgen Uncommitted Command /usr/bin/msgexecUncommitted Command /usr/bin/msgfilter Uncommitted Command /usr/bin/msggrepUncommitted Command /usr/bin/msginitUncommitted Command /usr/bin/msgmerge Uncommitted Command /usr/bin/msgunfmt Uncommitted Command /usr/bin/msguniqUncommitted Command /usr/bin/ngettext Uncommitted Command /usr/gnu/bin/gettextUncommitted Symbolic link /usr/gnu/bin/msgfmt Uncommitted Symbolic link /usr/gnu/bin/xgettext Uncommitted Symbolic link /usr/share/man/man1/envsubst.1 Uncommitted manpage /usr/share/man/man1/ggettext.1 Uncommitted manpage /usr/share/man/man1/gmsgfmt.1 Uncommitted manpage /usr/share/man/man1/gxgettext.1 Uncommitted manpage /usr/share/man/man1/msgattrib.1 Uncommitted manpage /usr/share/man/man1/msgcat.1Uncommitted manpage /usr/share/man/man1/msgcmp.1Uncommitted manpage /usr/share/man/man1/msgcomm.1 Uncommitted manpage /usr/share/man/man1/msgconv.1 Uncommitted manpage /usr/share/man/man1/msgen.1 Uncommitted manpage /usr/share/man/man1/msgexec.1 Uncommitted manpage /usr/share/man/man1/msgfilter.1 Uncommitted manpage /usr/share/man/man1/
Move gdb from /usr/sfw/bin to /usr/bin [PSARC/2007/630 Self Review]
Shawn Walker wrote: > On 02/11/2007, Garrett D'Amore wrote: > >> As an aside, has gcc already moved to /usr/bin? >> >> One nagging thought about moving the compilers to /usr/bin is that it >> seems to give a level of precedence to the GNU compilers and tools that >> is higher than we offer for our *own* tools (Studio). >> >> I.e. if gdb and gcc are in /usr/bin, then why not dbx and cc? >> >> I realize that this may not be the place to fully explore the idea of >> bundling Studio, but I'd hate for other parties to miscontrue this >> action as meaning our own Studio tools were "2nd class" on Solaris systems. >> > > One could argue that as long as Sun Studio isn't redistributable and > isn't open source (like was promised 2 years ago by Schwartz) it is a > second class citizen in the OpenSolaris community. I certainly feel > like one when I'm using it sometimes (i.e. tarballs don't always > include latest patches, etc.). > I agree with this and would also posit that whether or not Sun Studio is present is not PSARC's problem but rather a problem for the relevant business group in Sun to think about and decide about what to do. Darren
Move gdb from /usr/sfw/bin to /usr/bin [PSARC/2007/630 Self Review]
Gary Winiger wrote: >>> As an aside, has gcc already moved to /usr/bin? >>> >>> >> gcc is also on the list of SFW tools which will move to /usr/bin shortly. >> > > > If there's a list, I'd prefer to see it all as a single thing > to see how it all plays together than one at a time where the > big picture can be lost. > I'm with Gary on this. It seems like there is a bigger picture/architectural change here to which gdb fits in (now) and gcc in the future. It would be nice if that could be presented to the ARC. Other tools that come to mind (after gcc): gas and the rest of the GNU binutils (ld, strip, objdump, etc.) Darren
