[request-sponsor] three requests back on the 'awaiting sponsor' list
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? -- James Carlson 42.703N 71.076W carlsonj at workingcode.com
[request-sponsor] three requests back on the 'awaiting sponsor' list
Peter Tribble wrote: On Fri, Jan 15, 2010 at 8:29 PM, James Carlson carlsonj at workingcode.com wrote: 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. Good point. Given that the packages would fail on S8, they probably wouldn't bother doing that. 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. OK. (I'd thought that the old System V packaging stuff had made it into the ON consolidation as usr/src/cmd/svr4pkg/ ... so why no access to the source?) -- James Carlson 42.703N 71.076W carlsonj at workingcode.com
[request-sponsor] I'd like to participate in opensolaris development
Gary Mills writes: Is there a way that I can contribute to opensolaris development? I've Absolutely! I enjoy tracking down bugs and fixing them. I thought that the bite- sized bugs would be a good place to start, but all of them seem to be already assigned to somebody else. Are there any bugs left? There seem to be 612 bugs marked with the oss-bite-size keyword. Quite a few are in defer - no resource available state, so I'm sure there's something in there. It's all a question of what you want to work on. There are also quite a few bugs and RFEs on defect.opensolaris.org; well worth looking through. I've spent many frustrating hours on the opensolaris web site trying to figure out how I can contribute code. Most of this led me in circles or in wrong directions. Perhaps you can refer me to the right place. Step 0 is to decide where you want to contribute. OpenSolaris is composed of a set of consolidations -- call them repositories if you like. Each one has a different purpose. Perhaps the most commonly discussed one is OS-Net, or ON. That has the OS kernel, most device drivers, and much of the networking features. There are many others, including SFW, X, Desktop, Install. Step 1 is to read the documentation for the area where you want to contribute and then follow it. The rules for each consolidation are similar, but different, due to the differing needs and goals of the consolidations. In general, for contributions on your own, you'll need: - Some work that you've done - Architectural, design, and code reviews (as appropriate) - A signed contributor agreement - A sponsor to get the bits integrated That last bit is intended to be a temporary measure, due to problems with the infrastructure. In the future, you'll be able to file an RTI (request to integrate) and then integrate directly. For contributions to a project, things are quite a bit simpler. Just contact the folks on the project team using the mailing list for that project, ask where you can help (if it isn't already obvious), and then contribute. For most projects, the source is accessible via Mercurial or SVN, and once you're part of the project team, you can change it yourself. There is no step 2. ;-} -- James Carlson, Solaris Networking james.d.carlson at sun.com 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
[request-sponsor] Requesting sponsor for CR #6807179 (ksh93 does unneccesary |libc::getpwnam()| lookups for ~(modifer)pattern patterns)
Casper.Dik at Sun.COM writes: http://cr.opensolaris.org/~gisburn/ksh93_integration_cr_6807179_002/ The webrev doesn't include the CR in the comments. Have you done 'hg commit'? The webrev was created by the contributor; he's not going to use my workspace to do the putback :-) OK; looks better. -- James Carlson, Solaris Networking james.d.carlson at sun.com 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
[request-sponsor] sponsor needed for the convmv utility integration
Michal P?nka writes: 4. Fill some kind of Onepager document explaining the project I'm working on, but where to get it? The one-pager form is here: http://www.opensolaris.org/os/community/arc/handbook/onepager/ But you almost certainly don't want that. Assuming that this is a fairly trivial utility (and it looks like it is), all you'll need is a fast-track request, and that just requires some simple (hopefully *short*) descriptive material. There's a brief introduction to the process here: http://www.opensolaris.org/os/community/arc/ And the short answer is to find an ARC member or intern that you know and ask privately for help with your fast-track. (I can probably do that if you want, but I think the best candidate in this particular case would be ienup.sung at sun.com -- a PSARC intern with lots of i18n experience.) -- James Carlson, Solaris Networking james.d.carlson at sun.com 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
[request-sponsor] Dual boot OpenSolaris, Ubuntu and FreeBSD impossible
Leandro Martinez writes: I see, I wonder why I cant use my current grub... Your current grub likely doesn't have the extensions necessary to boot from ZFS. anyway, thanks a lot for the help, I will try that; but, just how I should install OpenSolaris grub? I assume I have to start booting from the live cd, but then what? should I run the command 'grub-install'? because I dont know what parameters I should pass it on. The usual way to do this is to run /boot/solaris/bin/update_grub. If you want to run the utility by hand, it's invoked like this: /usr/sbin/installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c0d0s0 ... though if you ever have to do that, that might be worthy of a bug. -- James Carlson, Solaris Networking james.d.carlson at sun.com 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
[request-sponsor] Shooting my mouth off
Ceri Davies writes:
What I'm trying to achieve is to, at the very least, get Alice up to
a point where somebody might be interested in at least working with her
on getting a correct patch out so that a potential sponsor (who, let's
face it, have real jobs to do too) can be bothered to choose that bug to
work on.
Does anyone else agree that this might be a problem, and are they able
to see a way out?
It's indeed a problem to have a bug assigned to someone who is not
going to produce a viable fix, and I think we're seeing that problem
occurring now.
Not producing a viable fix can occur for many reasons. You're citing
a particular though noteworthy case -- a poor-quality patch -- but
there are many others that happen in real life, including people who
start working on a problem but then get distracted elsewhere, or
instances where the bug becomes part of a bigger project, or those
times the submitter just falls under a bus.
Let's also take the whole sponsor question away, as that is a
temporary issue that's being fixed. The one problem I see there --
the there's already a request on the table problem -- is an
artifact, but it's not the underlying problem.
The underlying problem is that Alice isn't going to fix the problem.
It has to be up to Bob to take it away from Alice. If I were Bob, I'd
first send Alice a private message saying, hey, it looks like you're
not working on 1243567, and I've got a good way to fix it; mind if I
take ownership? The answer (in my experience) is almost always go
ahead, and the problem's solved. Most submitters know when they're
either doing nothing or are completely under water.
If Alice doesn't respond or gives some unsatisfactory answer (in Bob's
eyes), I believe the escalation path ought to be the community group
responsible for the technology area. Bob should compose a message
there saying, Alice {has proposed an unworkable solution for, doesn't
appear to be working on} this bug, and I have a better solution
documented $HERE. I request that the Core Contributors vote to
release this bug to me. In the role of directing the technology, I
think the community group should have the power to release the bug
from another's grip.
If the community group itself doesn't agree with Bob, he should
certainly do some soul-searching. If he still feels he's right and
the rest of the world is wrong, the OGB would be the natural next step
for such a conflict, but I'd hope that path would never be used, and
that it should almost never be successful.
--
James Carlson, Solaris Networking james.d.carlson at sun.com
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
[request-sponsor] Shooting my mouth off
Pete Bentley writes: On Fri, Feb 01, 2008 at 10:07:09AM -0500, James Carlson wrote: Let's also take the whole sponsor question away, as that is a temporary issue that's being fixed. Sorry to sidetrack what is a very useful thread, but just how temporary a problem is that likely to be? I don't have an exact date quite yet, but if you're interested in the solution to the problem, I suggest checking out the SCM Migration project. I'd _estimate_ that it'd likely happen by summer time. The big gating item right now is tools -- we need people to test the new tools, review the changes that are being made, and (in some cases) to volunteer to make the necessary updates. And how about the situation where the sponsor becomes unresponsive (possibly for very valid reasons)? If the sponsor becomes unresponsive, then I'd suggest sending mail here first to ask for a new sponsor, and (if that doesn't work) to Bonnie Corwin directly pointing out the problem. This shouldn't happen. Case in point, bug 6445725 (newfs / zpool create on firewire device hangs the OS) which really needs fixing before other contributors can do useful work on the firewire subsystem. Jurgen Keil submitted a working and reasonable looking (to me) patch well over a year ago, and even prodded the sponsor back in August (see http://mail.opensolaris.org/pipermail/zfs-discuss/2007-August/042143.html) and yet this still appears to be stuck. You're not Jurgen Keil, so I think the first thing to do would be to ask him. I don't see the evidence that suggests that this is the sponsor's problem rather than (possibly) some other problem that merely hasn't been discussed on the list. It's not unusual for a sponsor or a code reviewer to send private feedback or a request for additional testing. Those sorts of things can cause delays that are otherwise hard to understand if you're not part of that conversation. But let's suppose you're right and the sponsor is the road block here. In that case, if you were Jurgen Keil, you'd look at both the sponsor table: http://opensolaris.org/os/bug_reports/request_sponsor/ and the bug itself: http://bugs.opensolaris.org/view_bug.do?bug_id=6445725 Both show the RE as Alan Perry. If contacting him doesn't work (I don't know off hand if it does or doesn't work), then post here asking for a sponsor who does respond. If that doesn't work, then I'd recommend asking Bonnie for help. Cases like that should be quite unusual, and it's unclear to me whether you've diagnosed a real problem in this instance or if you just don't have enough information to make such a call. -- James Carlson, Solaris Networking james.d.carlson at sun.com 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
[request-sponsor] Shooting my mouth off
Ceri Davies writes: It occurs to me that I've been reviewing patches posted here where it might not actually be welcome. Tell me to shut up if necessary, although I'm concerned that this review should happen and preferably in good time after a submission is posted (rather than after the potentially long wait for a sponsor to come forward). I'd much rather see request-sponsor used just for requesting a sponsor and not for submitting patches or for reviews. Yes, all changes need thorough review, and comments should always be welcome, but this just isn't the right forum for it. Not everyone who should be looking at the proposed changes (or the review comments themselves) is actually on this list. Seeing those submitters go to the relevant community or project mailing list with a proposed patch (or better yet a pointer to a webrev) would be greatly preferred, and if we can gently guide them there when they mistakenly post changes here, that'd be good. -- James Carlson, Solaris Networking james.d.carlson at sun.com 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
[request-sponsor] Shooting my mouth off
Antonello Cruz writes: After building the tools, go the the top of your workspace (I don't think it will work on cr.opensolaris.org/~avinashj you'll have to do it locally) and run 'ws' to set the environment. Then run wx webrev. However, for it to work, you'll have to properly checkout the files you want to edit with wx edit files to edit wx edit seems fairly unlikely for an external (non-SWAN) user who doesn't have teamware access. Instead, you'll want to pull the hg-enabled tools from the SCM Migration web site: http://www.opensolaris.org/os/project/scm-migration/ (Look for downloads on that page.) Those packages will install the necessary tools in /opt/onbld. You can then run hgsetup to set up your $HOME/.hgrc file to work with the tools, and webrev will work as expected. When you're ready for review, just scp -r that webrev directory out to some web site (such as cr.opensolaris.org). -- James Carlson, Solaris Networking james.d.carlson at sun.com 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
[request-sponsor] Fix for bug-6440628
Ceri Davies writes:
- cmd = parsecmd(*argv++);
+ if (fopen(*(argv+1)){
[...]
Finally, this check should take place during argument parsing in main().
More comments:
- Why *(argv+1)? What's wrong with the equivalent but clearer
argv[1]?
- Won't this change -- if it could be made to compile -- just dump
core? The previous code dereferenced argv *first*, and *then*
incremented the pointer. You've changed that to skip over the
first argument, and then (with the +1) dereference the second,
and to leave argv still pointing at the first argument.
- The return value from fopen is discarded after being checked
(implicitly against NULL). Besides the usual ON rule that
pointers aren't booleans and shouldn't be tested that way, this
call leaks the file handle returned by fopen. Are you sure you
wanted to open the file at all?
Don't expect your code reviewers or sponsor or random contributors on
request-sponsor to make your code compile or fix the design. Please
make it right _first_, and then seek a review.
--
James Carlson, Solaris Networking james.d.carlson at sun.com
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
[request-sponsor] Could someone please provide hints for bugids: 4432948 , 4829659 , 5075505
Mark Martin writes: 4432948 , 4829659 , 5075505 are all hidden [...] Could someone please peek behind the firewall and provide either the synopsis or (even better) open the bugs up for public consumption? I have no idea how to open them up, but these are: 4432948 ufsdump/ufsrestore should support using ssh instead of rsh for remote tape acces [sic] [Fix-Understood state, priority 4, RFE] 4829659 ufsdump fails with 'star' rmt code [Accepted state, priority 4, Defect] 5075505 flarcreate to remote tape/boot system and install flash archive from remote tape [Accepted state, priority 3, RFE] Of those, I'd imagine that the first two would be of importance to someone looking at CR 4496994, and probably pretty easy to reproduce. -- James Carlson, Solaris Networking james.d.carlson at sun.com 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
[request-sponsor] Bug ID 6614951 and 6614275
Varrun Ramani writes: My name is Varrun Ramani.My SCN No is OS0178.I am taking up the bug ID's 6614275 and 6614951. Bug ID Description 6614275 Hostname instead of IP address should be passed to ldap_init(). 6614951 In getopt.h, the name member of the struct option should be of type const char * I think you have those bug numbers interchanged. 6614951 (the ldap_init issue) already has an assigned engineer. You'll want to contact the RE (natalie.li at sun.com) if you're interested in working on this. 6614275 (the 'struct option' issue) has no RE, so it should be free for adoption. -- James Carlson, Solaris Networking james.d.carlson at sun.com 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
[request-sponsor] [6236983] request sponsor
ashwin writes: I Would like to work on this bug # 6236983 if i am allowed to ( An Engineer is assigned) .Requesting sponsor for the same. My SCA number is OS01444 The bug has an assigned engineer (RE) who is working on it, and has a fix in code review now. -- James Carlson, Solaris Networking james.d.carlson at sun.com 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
[request-sponsor] [tools-compilers] Bug ID 6515400 and gccfss?
Alan Coopersmith writes: Mark Martin wrote: Presumably this requires some sort of ARC or fast-track or similar approval, can anyone confirm this? I didn't check all the files, but the ones I saw were all of the form of fixing function prototypes or adding type casts - nothing that requires review beyond basic code-review. ARC would only get involved if you're changing function definitions or other interfaces, and then only if they're functions exposed to other applications/modules/etc. ... or otherwise changing the architecture of the system or some significant component. I don't see any architecture here to be reviewed, so the only approval I'd think would be necessary would be the RTI (requiring design and code review, as needed). -- James Carlson, Solaris Networking james.d.carlson at sun.com 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
[request-sponsor] Adding status support to dd
Frank Van Der Linden writes: Matty wrote: Howdy, Most Linux and BSD distributions ship with a version of dd that displays the status of a copy operation when a SIGUSR1 signal is received. Just a correction. I know this is late in the game, and I don't want to prolong the discussion much, since this isn't the right list, but: *BSD uses SIGINFO, which is generated via the tty code when the user presses ^T. Several tools implement a status handler that uses SIGINFO. CR 6310532, now celebrating its first birthday. -- James Carlson, Solaris Networking james.d.carlson at sun.com Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
[request-sponsor] Adding status support to dd
James Carlson writes: Frank Van Der Linden writes: Matty wrote: Howdy, Most Linux and BSD distributions ship with a version of dd that displays the status of a copy operation when a SIGUSR1 signal is received. Just a correction. I know this is late in the game, and I don't want to prolong the discussion much, since this isn't the right list, but: *BSD uses SIGINFO, which is generated via the tty code when the user presses ^T. Several tools implement a status handler that uses SIGINFO. CR 6310532, now celebrating its first birthday. Ah, surprise. I filed it even longer ago. ;-} -- James Carlson, Solaris Networking james.d.carlson at sun.com Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
[request-sponsor] request sponsor for 6518038: cron crontabshould support multiple timezones
Don Cragun writes: # TZ=US/Pacific are allowed by the standard, you can do the same thing in a manner compatible with the standard. However that could leads you to interpreting comments which would be bad. Agreed. I was not suggesting that this exact form is a good idea; only that the standards allow comments in crontab files. They don't allow the comments to be interpreted. More importantly, though, this still wouldn't be portable. If we did this, then crontab files created on Solaris that use this new construct would *NOT* be interpreted correctly if copied over to some other system. Yes, the comments would be ignored, but the resulting crontab file would be misinterpreted: the time zone would not be adjusted for the entries that follow, and thus it'd fail to start the jobs when the user expected them to be started. So, merely changing these things into comments is not a solution to the portability problem. Which standard would we be in breach of? SVID3, POSIX.1-2001, POSIX.2-1988, XPG3, XPG4, SUS, SUSv2, SUSv3, ... I think it's much simpler to say something like this: Solaris supports a proper superset of the standards listed below. The user can choose to add variable=value lines to his crontab(4) file. If he chooses to do so, then his crontab will not be in compliance with those standards, and may not be portable to other operating systems that support only those standards. Crontab(4) files that are in compliance with those standards will always work properly on a Solaris system. In other words, just as it is with adding (say) /opt/csw/bin to your $PATH, it's the user's choice whether he wants to walk outside the standards. He doesn't have to. -- James Carlson, Solaris Networking james.d.carlson at sun.com Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
[security-discuss] sync as non privileged user (Was Re: [request-sponsor] 4967733 and 6400646)
Darren J Moffat writes: Dan Price wrote: I know that at some point the performance guys wanted to make sync's by non-root users do nothing, but IIRC it was deemed too risky or something. Maybe we should go do that for Nevada. Anyone in request-sponsor land have some background info they could point us at? [...] I think these might be ideally specified as basic privileges, that is all users have them by default (just like the ability to see the existence of others processes in ps output) but they can be removed by the system admin. I think it'd be a little odd to have a privilege that works like this. The implication seems to be that if you have the privilege, then sync does what it's always done. If you don't, then sync silently does nothing at all. (I don't see any clear way for sync(2) to return a failure ...) For zones, why would I want to choose between allowing zones to operate more quickly (by removing this privilege) and allowing zone users to save their work during thunderstorms? I'm not sure I know how a customer should make such a decision. -- James Carlson, KISS Networkjames.d.carlson at sun.com Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
[request-sponsor] Re: sponsor request for CR6482159
Gavin Maltby writes: On 10/26/06 15:25, James Carlson wrote: (For what it's worth, we have no way to reject bugs.) Can I log an rfe for one :-) It leads to an amusing paradox ... -- James Carlson, KISS Networkjames.d.carlson at sun.com Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
[request-sponsor] telnet(1) cannot handle more than 15 fds
Jonathan Adams writes: Couldn't you just start main() with: closefrom(3); to close any extra file descriptors? Yes, that'd be much better. -- James Carlson, KISS Networkjames.d.carlson at sun.com Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
[request-sponsor] telnet(1) cannot handle more than 15 fds
Chris Elving writes: Due to the 32-bit ABI's stdio file descriptor limit, an interposer is being used to F_DUPFD non-stdio file descriptors to 256 and above. This mitigates a problem with 3rd party modules and plugins that use fopen(3C), et al. streams in processes such as Apache HTTP Server that open a large number of file descriptors. Unfortunately, using the interposer causes failures when a child process (e.g. CGI program) subsequently invokes telnet(1). If telnet passed the correct nfds value to select(3C), that failure would be eliminated. Thanks! That's the key piece I was missing. In that case, I suspect that closefrom() won't fix the problem, as the socket() call will return a descriptor that's above the limit and run into the problem again. -- James Carlson, KISS Networkjames.d.carlson at sun.com Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
