A contributor agreement is needed for all contributions, regardless of
size or complexity.
If you are doing this yourself as an individual, you sign. If you are
submitting something on behalf of your company, an executive from your
company needs to sign.
Let me know if you have more questions.
Marc Glisse wrote:
> I created a patch for this RFE:
> Basically the way in.talkd works is that it uses the first tty in utmpx that
> belongs to the right user. This tty may not be writeable. In this patch I
> modify the loop that looks for the first tty that belongs to the right user
> to make it find the first one that has the group write permission. I tried to
> make the patch as minor as possible to make it unlikely to break anything.
> There is already some code duplication between process.c and announce.c, and
> this slightly increases it. Refactoring the code would make for a cleaner
> solution, but it is more work, both to make and to review. An other solution
> would be for in.talkd to run as user talkd and group tty, this way a tty not
> being writable would probably make the current code try the next tty, but
> that is also more complicated than adding a simple stat (need to check
> exactly what privileges in.talkd needs) (besides, I tried modifying the
> manifest file, but in.talkd was still started root:root).
> I tested the patched in.talkd on S10U1 by simply substituting it to the
> original /usr/sbin/in.talkd (plus the appropriate svcadm disable/enable
> talk). When I talk a user who is not logged in, I get "[Your party is not
> logged on]". When I talk a user whose ttys are all "mesg y", it works. When I
> talk a user whose ttys are all "mesg n", I get "[Your party is refusing
> messages]". Now the only case that differs between the original version and
> mine: when I talk a user who has some ttys with "mesg n" and some with "mesg
> y", my version always finds one of the "mesg y" ttys whereas the original one
> often answers "refusing messages".
> I do not have a contributor agreement yet (currently trying to figure out who
> is supposed to sign it), I don't know if it is necessary for such a short
> This message posted from opensolaris.org
> request-sponsor mailing list
> request-sponsor at opensolaris.org