[request-sponsor] three requests back on the 'awaiting sponsor' list
On Fri, Jan 15, 2010 at 7:32 PM, Ethan Quach ethan.quach at sun.com wrote: FYI, These three bugs are back on the 'awaiting sponsor' list because the sponsor is no longer with Sun. 6424003 - pkginfo -l can't handle long package names properly 606 - Package name length definitions inconsistent 6443055 - pkgchk and pkgtrans are not able to deal with 32 char package names Given the future of this software (or the decision that it hasn't got one), I'm thinking it's best to drop these. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
[request-sponsor] three requests back on the 'awaiting sponsor' list
On Fri, Jan 15, 2010 at 8:29 PM, James Carlson carlsonj at workingcode.com wrote: Peter Tribble wrote: On Fri, Jan 15, 2010 at 7:32 PM, Ethan Quach ethan.quach at sun.com wrote: FYI, These three bugs are back on the 'awaiting sponsor' list because the sponsor is no longer with Sun. 6424003 - pkginfo -l can't handle long package names properly 606 - Package name length definitions inconsistent 6443055 - pkgchk and pkgtrans are not able to deal with 32 char package names Given the future of this software (or the decision that it hasn't got one), I'm thinking it's best to drop these. Won't these things still be issues for third-party packages? Third-party? Doubtful that they would use package names as long as SUNWstaroffice-gnome-integration. When I reported some of these and requested a sponsor, fixing them seemed like a good idea; 18 months with no access to the source has intervened, and a change in direction has come about, and I'm not sure I can muster the enthusiasm. If enough people think that fixing bugs in this area is worthwhile, then I'm prepared to reconsider. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
[request-sponsor] I would like a sponsor to fix bug 6269516
On 7/8/07, Richard Lowe richlowe at richlowe.net wrote: This (and the other, similar, message) appear to be resends of prior mail. http://mail.opensolaris.org/pipermail/request-sponsor/2006-April/001200.html Well spotted! I *thought* it looked rather familiar! (And lest anyone get distracted, integrated soon after.) and http://mail.opensolaris.org/pipermail/request-sponsor/2005-July/000756.html Chaos? confusion? Spam? Well, it's got me confused, at the least. I'm not sure what can be achieved by a straight cut-n-paste of old messages, with just the name changed. hank wrote: I would like a sponsor to fix bug 6269516, along with 4858191 + 4430296. Details and diffs at http://www.petertribble.co.uk/Solaris/fixes/4/ Contributor Agreement OS0019 1. 6269516 I've made the /usr/bin version accept -x, and the xpg4 version accept -d This affects the usage message, comments, and the manpage will need to be modified to suit. I've enabled -o support for the xpg4 version. This makes the usage message and the getopt statement identical, removing the need to check if XPG4 is defined. The differences in behaviour that still exist relate to the default behaviour of the -r flag, and the output format. (The bug report appears to have not been entirely cleansed of my old URL.) 2. 4858191 See also 4430296 Yes, I know it's closed, but it should be fixed. Linux and BSD support -m, and it's very useful as filesystems grow ever larger. (And no, -h isn't the answer - it produces scaled numbers which aren't the same thing, and which can't be processed numerically [possibly by tools which can't handle more than 32-bits worth].) So I've added the m flag to the comment, usage messages, getopt, and the output section gets an extra if. I've also turned off the m flag if -k is given, and vice-versa. (Should -h be handled in this manner too?) 3. Restructuring I've defined output formats to simplify the mess of ifdefs in the printsize() routine. Hank This message posted from opensolaris.org ___ request-sponsor mailing list request-sponsor at opensolaris.org ___ request-sponsor mailing list request-sponsor at opensolaris.org -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
[request-sponsor] 1122699 : ls -k
I'm looking for a sponsor for: Bug ID 1122699 Synopsis*ls* ls: would like to have -k option like du does (I have interpreted this as simply 'change the units for the space used from blocks to k if -k is specified as well as -s'.) Suggested fix at: http://cr.opensolaris.org/~ptribble/1122699/ -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
[request-sponsor] 4838106 - /usr/ucb/df
Mike, On 10/29/06, Mike Gerdts mgerdts at gmail.com wrote: 4838106 /usr/ucb/df -i -t nfs fails strangely The attached patch will fix this bug. Contributor agreement is OS0018. I already have sponsors (Rich Brown and Alok Aggarwal) for this one, and this will hopefully be finished pretty soon. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -- next part -- An HTML attachment was scrubbed... URL: http://mail.opensolaris.org/pipermail/request-sponsor/attachments/20061029/07fff7b2/attachment.html
[request-sponsor] 6424003 pkginfo -l can't handle long package names properly
I would like a sponsor for 6424003. Suggested fix is in the bug report. (Note that the bug report is slightly inaccurate. It's broken on all platforms, but the output sometimes looks plausible.) -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
[request-sponsor] 6415252 srchcfile could be improved
I would like a sponsor to fix 6415252. (Gives a nice boost to pkgchk, pkginfo -l, and pkgrm.) Details and diffs at http://www.petertribble.co.uk/Solaris/fixes/5/ Contributor Agreement OS0019 There are 2 main modifications: 1. Every instance of WRITEDATA is protected by checking that cfTmpVfp is non-NULL. Most were already, but now all are. (4 times.) 2. All invocations of the getstr routine have been replaced. The problem is that the separator string was dynamic, so it was constructed afresh using strlcpy and strlcat each time. But there are only two different forms, so I have replaced getstr by two similar functions, one for each form of invocation. In addition, using strpbrk to search for the characters we're looking for is inefficient. Not only does it involve a function call, but we may have to call strlen as well. The revised implementation uses fixed lookup tables to scan the string, in an identical manner to the existing fast character checking elsewhere in this file. this also streamlines the logic a little. -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
[request-sponsor] 6416837 /usr/ucb/ls needs /bin/ls enhancements
I would like a sponsor for 6416837 (see also 6231493). I'm not expecting a great rush based on the response to my other ucb fixes... In this case I would also appreciate advice from a sponsor as to the approach to take before I get in too deep. I can imagine 3 approaches: 1. Cut-n-paste the missing code from /bin/ls into the /usr/ucb/ls source. Advantages: it's easy, retains current behaviour, and I've done it once already. Disadvantages: it doesn't do anything to make future synchronization easier. 2. Replace /usr/ucb/ls by the /bin/ls source and modify that to get the BSD behaviour back. Advantages: cleaner to do, makes patching future changes easy, we pick up other fixes that have been made to ls for free. Disadvantages: needs more testing to ensure that old behaviour is preserved. 3. Generate /usr/ucb/ls from the /bin/ls source using #ifdef, rather like the xpg4 variant is created. Advantages: only one codebase, future merges are trivial. Disadvantages: as 2, and it involves messing with the /bin/ls source and could be very complex to successfully generate 3 binaries from a single source. -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
[request-sponsor] du option merge 6269516
I would like a sponsor to fix bug 6269516, along with 4858191 + 4430296. Details and diffs at http://www.petertribble.co.uk/Solaris/fixes/4/ Contributor Agreement OS0019 1. 6269516 I've made the /usr/bin version accept -x, and the xpg4 version accept -d This affects the usage message, comments, and the manpage will need to be modified to suit. I've enabled -o support for the xpg4 version. This makes the usage message and the getopt statement identical, removing the need to check if XPG4 is defined. The differences in behaviour that still exist relate to the default behaviour of the -r flag, and the output format. (The bug report appears to have not been entirely cleansed of my old URL.) 2. 4858191 See also 4430296 Yes, I know it's closed, but it should be fixed. Linux and BSD support -m, and it's very useful as filesystems grow ever larger. (And no, -h isn't the answer - it produces scaled numbers which aren't the same thing, and which can't be processed numerically [possibly by tools which can't handle more than 32-bits worth].) So I've added the m flag to the comment, usage messages, getopt, and the output section gets an extra if. I've also turned off the m flag if -k is given, and vice-versa. (Should -h be handled in this manner too?) 3. Restructuring I've defined output formats to simplify the mess of ifdefs in the printsize() routine. -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
[request-sponsor] /usr/ucb/file 4319640
I would like a sponsor to fix bug 4319640. Details follow; diff attached. Contributor Agreement OS0019 1. 4319640 Just as it says in the bug description, $* has been changed to $@. In addition, the file command is execed, which is slightly quicker. -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -- next part -- A non-text attachment was scrubbed... Name: file.sh.diff Type: text/x-patch Size: 334 bytes Desc: not available URL: http://mail.opensolaris.org/pipermail/request-sponsor/attachments/20060418/38ba6766/attachment.bin
