RE: cvs abusing stderr?
Harald Dunkel wrote: Any special reason why cvs prints a list of cvs server: Updating modulename on stderr instead of stdout? This is surely just a log message, which is supposed to be printed on stdout. On a huge project the _real_ error messages are hidden between all the garbage. It would be nice if this could be fixed. I can't comment on why these messages go to stderr instead of stdout, but I will mention that the global -q flag suppresses them. I use '-q' so much it's in my .cvsrc file ;-) -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Patch for making CommitID configurable
Peter Backes wrote: [a lot of stuff] Just see TeX. Without doubt, and you will surely agree, one of the best programs, perhaps the best program, ever written. I've used it. Can't stand it. I don't have the time, nor the patience, to learn all the arcane commands you need to know in order to make things happen. And I shouldn't *have* to learn all that stuff. To me, the whole point of having a computer is that it takes care of all that complexity, and lets me focus on what's important - the document's contents and, to a minor extent, its formatting. Peter, it is clear that you and I have fundamentally different, and probably irreconcilable, approaches and philosophies on software development. These differences are extremely unlikely to be resolved in this forum. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Patch for making CommitID configurable
Peter Backes wrote: Just think about what *is* the big advantage of CVS besides working on RCS files instead of a strange ever-changing file format? ever-changing? I think you're exaggerating here. When was the last time the RCS file format changed? What's the point in having the rcsfile(5) specification have the newphrases spec, if you aren't going to use it? (http://www.daemon-systems.org/man/rcsfile.5.html) I don't see any. If you do not need this core feature, there are much better alternatives to pick from, like Subversion, and they provide much more than just writing a commit ID without ever using it! Incrementally adding a new feature is a lot less of a change, and a lot less drastic, than switching to an entirely new system. The way you're talking, it sounds as if you are saying that, once a program is released, it should never change, and if you want new features you should write a whole new, different program to add those features. Is that really what you're proposing? Having said this, it is obvious that it should also be a question of whether CommitID should be kept as a feature *at all*. No, it is not obvious at all. It is only obvious if one is intent on keeping the status quo. It is much better to use the loginfo feature with the already present commitlog and then pick the changeset from this one (and that is already possible entirely without any change to cvs itself!) instead of relying on writing some hard-to-retrieve info into rcs files. For what definition of better? Better for _you_, perhaps, but not for the dozens or hundreds of users (like me) who _want_ this feature. Using commitinfo requires - each and every installation to make the same changes to their existing commitinfo scripts; this requires hundreds of hours of wasted, duplicated effort. Sure, you could make a generic commitinfo script available - but if anyone already *has* a commitinfo script, then they won't be able to use the canned one. - tracking the commit ID in a separate database. Separating the commit information (i.e. the ID and the log) is not a good idea. When does a commit ID make sense? Only in a distributed environment, where a revision must be identified uniquely independent of it's number. Huh? Not! The commit ID allows me to determine which files were committed in a single operation. It has no bearing on distributed environments. I'm looking at a file, and the log says Fixed such-and-such a bug. I want to know what other files were committed at the same time. Currently, I have to rely on narrowing it down by timestamp, using a difficult-to-remember, not very obvious technique for entering timestamps. Or, I could just type in the commitID and there it is. How about tags? Don't they also provide just the solution to the problems commit ID was added for? Assuming that each and every commit is tagged, perhaps. But that's not necessarily the case, and it's certainly not a practise I would encourage. Another alternative might be to provide a patch to the RCS maintainer to support any of the newphrase formats that CVS has introduced... Please don't ... RCS is stable, and the files it writes have been the same for years And your point would be... what, exactly? Does RCS not have any kind of a test suite to check for problems? So please don't change rcs anymore except for bug fixes! So, let me get this straight. Just because *you* don't see any value in a new feature, you want to prevent everyone else from using that feature? (that was a rhetorical question, by the way - I'm sure that is not what you intended). Can you provide some objective reasons for not changing RCS? So far, all you've given us is an impassioned plea for keeping the status quo, without really giving any substantial reasons. CVS is to be built upon the things given by RCS, not the other way around. CVS *was* originally built on RCS. Why should it remain that way forever? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: some files are missed in importing
[EMAIL PROTECTED] wrote: (Hmmm, question: can a .cvsignore ignore .cvsignore ?) Yep. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: some files are missed in importing
root wrote: when I typed this command, some important files are ignored # cvs import -ko -I ! -m source v2.2.1_final test first | grep ^I /root/log # cat log I netsnmp/sedscript I netsnmp/net-snmp-config I netsnmp/config.status I netsnmp/net-snmp-config-x I netsnmp/configure-summary I netsnmp/CVS Don't import directories named CVS. You will just cause problems for CVS. ... what should I do to solve this problem? All you've shown us are the files which were successfully imported. How can we help you figure out the problem if you don't tell us which files *didn't* get imported? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: some files are missed in importing
root wrote: When I typed this command, some important files are missed. This is not a chat group, it is an email list. You must allow a minimum of 24 hours for your message to reach others, and for them to respond. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: no password after user change?
Wenslauw wrote: Mind you, I didn't do a login before that. Then I changed the user to the right one and tried the same cvs co blaproj again. This time too without doing a login first. I was surprised to see it checks out the source for blaproj... Is this a configuration issue or a bug? I'm quite curious. A 'cvs login' lasts until you explicitly issue a 'cvs logout' command. Is there a .cvspass file in your home directory? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: cvs problem
Dionysis wrote:
Recently, I experienced problems with the cvs system. Sometimes, a
user commits the changes of a file or adds a file to the repository,
and then another user updates his repository, but cannot see these
changes.
I guess this problem may have been reported again. Any ideas about
what the problem might be? What are the possible causes?
Hmmm... well, the description you've given is not very specific, so there
could be a great number of causes.
If I were to hazard a guess, I'd suspect that one of the people involved is
working with a Sticky file - either the changes were checked in on a
branch and the people who can't see the changes are on a different branch
(or the trunk), or the person/people who can't see the changes have checked
out a non-branch tag or a specific date. Use 'cvs stat' on the files that
can't see the changes, and make sure that Sticky Date: is (none) and
Sticky Tag: is either (none) or a branch tag, and make sure the branch
tag is the same one where the files were checked in.
Also, check the log ('cvs log') for the file and verify that the changes
actually made it into the repository. Use 'cvs diff -rX -rY [filename]' to
double check that the changes look reasonable (where X is the revision
before the checkin, and Y is the revision after the checkin).
--
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. ( http://www.leitch.com )
Columnist, C/C++ Users Journal ( http://www.cuj.com/experts )
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Patch for preserving edit on files when checking out
Darren Bowles wrote: Please find attached my CVS patch for preserving editor flag upon multiple checkouts. Or not :=) The list server strips attachments. Could you please re-submit, with the patch in the text of the message? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: CVS Sources Using Automake 1.9.5.
Derek Price wrote: I've restandardized on the latest Automake version for convenience re the earlier discussion: http://lists.gnu.org/archive/html/bug-cvs/2005-03/msg00048.html. Please regenerate build files with Automake 1.9.5 before committing changes to their sources. I'm pretty green at Automake. Which files does this affect? On Cygwin, I just run ./configure make and in Visual Studio, I just load and build the Visual Studio workspace. Is there anything else I should be doing? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: incrementing revision numbers ... behavior?
Frank Hemer wrote: I have noticed that cvs add foo generates an initial revision number of 2.1 if there exist files in the repository that have revision numbers =2.x. Is this expected behavior? Yes, under certain conditions. See https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_4.html#SEC47 -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: this happens sometimes
Romeo Gourgue wrote two variations on the following: Some times when I do a CVS commit, text like the following is appended to the bottom of the file that I have committed: ** date: Friday, February 18, 19105 @ 14:44 author: username Update of /data/implementation/cvs/operational/bin In directory system:/data/frodo1/aroman/bin Modified Files: emacs-init.el ops-env Log Message: This does not happen every time. When it does happen, I edit it out and recommit; but it is annoying. This started happening right after the aussie-wizard replacement on SOGS. As part if that project, Otto installed a new version (1.12.9) of CVS. Since then, I have used both the new and the old (1.11) versions of CVS; and have seen this problem with similar frequency in both versions. First of all, this is not a chat group, you cannot expect an instant response. If your second post was because of a suspected error in sending, then you should state that in your message. Check your email notification script. This looks like the text that would normally be sent via email to anyone watching the directory. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: GNULib save-cwd.c on Windows Visual Studio 6.0
Jim Meyering wrote: Is it an option to use a more modern/POSIX-compliant development environment on Windows? I know that Cygwin now has fchdir and it looks like MKS has support for it, too. If you opt to continue using Visual Studio 6 in spite of this, it must have some important redeeming features. The problem with the cygwin build is that it requires Cygwin.dll as well. The MSVC build stands alone, not requiring any external DLLs. I don't think it is reasonable to require all Windows users to download and install Cygwin just to run CVS. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: [bug-gnulib] GNULIB wait-process module.
Bruno Haible wrote: libsigsegv. Only about SIGFPE I'm not sure whether you can catch it on Windows as well. According to the MSDN, SIGFPE is one of the signals you can handle. I haven't used it myself, so I can't comment on implementation details. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: lib/xtime.h is included twice
Derek Price wrote: I'm ok with this if you'd like to apply it, Jim. Patch has been committed on 1.11 branch and on the trunk. Since this is such a small patch, should I still update ChangeLog and NEWS? ChangeLog doesn't seem to mention build fixes very much; there are one or two mentions in NEWS. I would be nice to give Georg credit for finding the problem and submitting the original patch, so I will put an entry in NEWS, but (to be consistent with other fix the build changes) not in ChangeLog. OK? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: lib/xtime.h is included twice
[EMAIL PROTECTED] wrote: All changes go into ChangeLog, only significant user-visible changes go into NEWS. See the GNU coding standards for more details: http://www.gnu.org/prep/standards/ Noted. And bookmarked for future reference - thanks for that information. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: lib/xtime.h is included twice
Georg Schwarz wrote: I cannot judge this. I was just following the example given in http://cvsweb.NetBSD.org/bsdweb.cgi/src/share/misc/style?rev=H EADcontent-type=text/x-cvsweb-markup Oh, dear. Time to send NetBSD a note suggesting they change the example, if they want to remain ISO/ANSI compliant. Can anyone confirm if [EMAIL PROTECTED] is the correct contact for this? If you think different naming conventions are more appropriate, I don't mind. If you're referring to the leading underscore, then that's not just a naming convention, it's a violation of the ANSI/ISO C standard (paragraph 7.1.3, Reserved Identifiers). If you're referring to the lower-case d, then I have no strong attachment to it. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: lib/xtime.h is included twice
[EMAIL PROTECTED] wrote: Dear cvs developers, for cvs 1.11.19 and earlier, lib/xtime.h is included twice, which breaks compiling on IRIX 5.3. The following patch prevents this: --- lib/xtime.h.orig2005-03-01 15:53:11.0 +0100 +++ lib/xtime.h 2005-03-01 15:54:20.0 +0100 @@ -12,6 +12,9 @@ * functions */ +#ifndef _XTIME_H_ +#define _XTIME_H_ ISO C Standard reserves names beginning with underscore and an uppercase character, or beginning with two underscores. I recommend changing this to something like: #ifndef XTIME_HEADER_INCLUDEd #define XTIME_HEADER_INCLUDEd (note: the lower-case d at the end is deliberate - it's my technique to reduce the chances of a name collision.) -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: lib/xtime.h is included twice
Derek Price wrote: Jim.Hyslop wrote: | [EMAIL PROTECTED] wrote: | | Dear cvs developers, | | for cvs 1.11.19 and earlier, lib/xtime.h is included twice, which | breaks compiling on IRIX 5.3. The following patch prevents this: | | --- lib/xtime.h.orig2005-03-01 15:53:11.0 +0100 +++ | lib/xtime.h 2005-03-01 15:54:20.0 +0100 @@ -12,6 +12,9 @@ | * functions */ | | +#ifndef _XTIME_H_ +#define _XTIME_H_ | | ISO C Standard reserves names beginning with underscore and an | uppercase character, or beginning with two underscores. I recommend | changing this to something like: | | #ifndef XTIME_HEADER_INCLUDEd #define XTIME_HEADER_INCLUDEd | | (note: the lower-case d at the end is deliberate - it's my | technique to reduce the chances of a name collision.) I'm ok with this if you'd like to apply it, Jim. Will do. Georg, have you tested your patch on any other platforms? It should be harmless, but I've been bitten by enough harmless-looking patches to be wary :-) -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Changing passwords for CVS Users (pserver protocol)
Derek Price wrote: The patch does what you said it would on stable, but something else is wrong on feature. The new watch6-2 test fails - basically, the previous watch add appears to be failing without reporting the error. I've attached a revised patch, with the failing tests (which, again, pass on stable). OK, I'll look into the problems on feature. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Changing passwords for CVS Users (pserver protocol)
Guus Leeuw jr. wrote: Guess the dev mailing list is not really frequented, and also monitored? Does seem that way, doesn't it? Nobody's responded to my messages about the default watch attributes. I know many people monitor this list via gmane's NNTP interface - maybe there's a problem with gmane. Do you monitor this by email or by USENET? I'm subscribed to the mail list. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
RE: Problems with cvs watch add and directories
I wrote: OK, my understanding is, if you issue: cvs watch add [dirname] (where [dirname] specifies a directory) then, if any subdirectories are added to [dirname], you will automatically get a watch for that new directory. Right, I finally figured it out. If you say: cvs watch add with *no* file or directory arguments, *then* it adds the 'D' entry to fileattr. Same with the watch on/off commands. So there is a discrepancy between the documentation and the actual behaviour. Which is correct? I can submit a doc patch fairly quickly, but I'm not sure I can figure it out enough to submit a source code patch. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Problems with cvs watch add and directories
OK, my understanding is, if you issue: cvs watch add [dirname] (where [dirname] specifies a directory) then, if any subdirectories are added to [dirname], you will automatically get a watch for that new directory. However, CVS doesn't seem to be doing this. I've tried using version 1.11.9 and 1.12.9, and neither one will add the D entries to CVS/fileattr, and if you add a subdirectory, then no CVS/fileattr file is created. Yes, I know these are both old versions, but I've checked the NEWS file and there is no mention of any bug fixes to 'cvs watch'. Here is a sequence of commands that illustrates the problem: [EMAIL PROTECTED]:$ cvs co cvs-test/jhyslop cvs checkout: Updating cvs-test/jhyslop [EMAIL PROTECTED]:$ cd cvs-test/jhyslop/ [EMAIL PROTECTED]:$ mkdir subdir [EMAIL PROTECTED]:$ cvs add subdir Directory /cvs/cvs-test/jhyslop/subdir added to the repository [EMAIL PROTECTED]:$ cvs watch add subdir [EMAIL PROTECTED]:$ cvs watchers [EMAIL PROTECTED]:$ cat /cvs/cvs-test/jhyslop/CVS/fileattr cat: cannot open /cvs/cvs-test/jhyslop/CVS/fileattr [at this point, I would expect the fileattr to exist, since I issued a 'watch add' command] [EMAIL PROTECTED]:$ cd subdir [EMAIL PROTECTED]:$ echo some stuffafile [EMAIL PROTECTED]:$ cvs add afile cvs add: scheduling file `afile' for addition cvs add: use 'cvs commit' to add this file permanently [EMAIL PROTECTED]:$ cvs ci -m a file afile RCS file: /cvs/cvs-test/jhyslop/subdir/afile,v done Checking in afile; /cvs/cvs-test/jhyslop/subdir/afile,v -- afile initial revision: 1.1 done [EMAIL PROTECTED]:$ cvs watch add . [EMAIL PROTECTED]:$ cat /cvs/cvs-test/jhyslop/subdir/CVS/fileattr Fafile _watchers=jhyslopedit+unedit+commit [well, OK, it created the fileattr file, but where's the entry D _watchers=jhyslopedit+unedit+commit I *did* specify a directory name. Hmm... maybe it doesn't like '.' as a directory specifier] [EMAIL PROTECTED]:$ cd .. [EMAIL PROTECTED]:$ cvs watch add subdir [EMAIL PROTECTED]:$ cat /cvs/cvs-test/jhyslop/subdir/CVS/fileattr Fafile _watchers=jhyslopedit+unedit+commit [Still no 'D _watchers=' entry in fileattr] [EMAIL PROTECTED]:$ cd subdir [EMAIL PROTECTED]:$ mkdir nowatches [EMAIL PROTECTED]:$ cvs add nowatches Directory /cvs/cvs-test/jhyslop/subdir/nowatches added to the repository [EMAIL PROTECTED]:$ cd nowatches [EMAIL PROTECTED]:$ cvs watchers [EMAIL PROTECTED]:$ cat /cvs/cvs-test/jhyslop/subdir/nowatches/CVS/fileattr cat: cannot open /cvs/cvs-test/jhyslop/subdir/nowatches/CVS/fileattr [still nothing] [EMAIL PROTECTED]:$ vi /cvs/cvs-test/jhyslop/subdir/CVS/fileattr [ at this point, I manually added the line D _watchers=jhyslopedit+unedit+commit to fileattr] [EMAIL PROTECTED]:$ cd .. [EMAIL PROTECTED]:$ mkdir haswatches [EMAIL PROTECTED]:$ cvs add haswatches Directory /cvs/cvs-test/jhyslop/subdir/haswatches added to the repository [EMAIL PROTECTED]:$ cat /cvs/cvs-test/jhyslop/subdir/haswatches/CVS/fileattr D _watchers=jhyslopedit+unedit+commit [Oh, look, there it is - but only because it was there to begin with] As the last line of my log indicates, if the fileattr _already_ contains a 'D' entry, then new directories behave as expected. It's only if the fileattr does not already have a 'D' entry that there's a problem. So, am I doing something wrong, or is this a bug that nobody's noticed yet? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
