Re: SVN: Checksum mismatch problem
Bruce Korb wrote: Philip Martin wrote: The capital 'I' in 'Is' looks wrong. ... That's what I wanted: a nice, simple answer that was short of re-pulling the entire repository. ``delete the entire ada sub-dir from the working copy and update will download it again.'' Thank you! (I don't want to go chase how the capitalization got to be wrong. I certainly don't go fiddling with stuff in the Ada directory. Someone did something somewhere.) Cheers - Bruce Sometimes I run commands to walk down the filesystem and do things to the files in them. With CVS this was never a problem, never a false hit, because CVS did not keep a pristine copy of the database around. Example: find . -name foo -print0 | xargs -r0 sed --in-place 's/foo/bar/g' But now I find that I need to be aware that in the .svn directory is a pristine copy of the same file. The above won't match because the pristine copy always has .svn-base appended to the end. But the following would match and would edit both the working copy and the pristine copy in the .svn directory. find . -name 'foo*' -print0 | xargs -r0 sed --in-place 's/foo/bar/g' I have no idea if this is possibly the type of thing that happened to you or not. But I thought I would mention it because it seems plausible. Bob
Re: How to make an application look somewhere other than /lib for ld-linux.so.2
Mark Cuss wrote: I'm pretty certain that I'm not the only person who struggles with the Oh, that app was built on RH 8 so it won't run on RH 7.3 problems, so I'm trying to find a solution where I can configure my build system in such a way that I can distribute a set of libraries with my applications to that it will run on any distro - at least all of the Red Hats, Fedora Cores, and RHELs anyways. Why restrict yourself to a small subset of the list of distros? With a little bit of effort you can handle Debian, Ubuntu, SuSE, Mandrake and others too. This question was asked a while go on another mailing list. I posted what I do there in that list. Here is a pointer to an archive of my method of platform independence. Basically I bundle all of the libraries and wrap the executable in a script wrapper. http://subversion.tigris.org/servlets/ReadMsg?listName=usersmsgNo=32310 This is off-topic for this list. But I am happy to discuss the issues with you either directly or in a more appropriate forum. Bob
Re: Mail. Mail! Mail?
Bernard Leak wrote: Firstly, thanks to Bob Proulx for the helpful pointer to the Debian search widget. This is a genuinely useful-looking tool. How pleasing! Not wanting to take credit inappropriately, it was Zack who suggested the Debian package search page. I was the mailx history rant! :-) But unless he thinks this is another thing I should just know about, You have to draw the line somewhere. Take for example the contrived problem of documenting fully the process of waking up and going to work in the morning. Spend no more than 25 words describing how to tie your shoes. Is it sufficient for someone who has never seen shoelaces before to replicate the task and learn to tie their shoes? Probably not. True story. One of my friends was picking up his and the neighbor's kids in the car one day. My friend has an older car with crank windows. The neighbor kids had never seen that before and very politely (I was impressed) asked how could they please put the window down? It surprised me, but they had not ever seen a crank window before and eventually needed to ask for help. Those are the types of scenes I think about when I and others ask for help. I tried quite hard to find out the answers I needed before I first posted my question. And we appreciate that. I often spend a huge amount of time searching and creating test cases and then posting a note only to find that I missed something very simple. Oh well. One has to do the research first just the same. But then once done don't fear asking for help. Not having made an effort will show. As it will also show having made an honest effort to figure things out. How difficult does it have to be to find something out before adding it to the documentation looks like a benefit to other people? I don't think I have ever heard of anyone else having this particular problem before. Mind you there are a *lot* of potential problems. If you are forcing me to state an opinion I would say I think something needs to be asked three times before it becomes a frequently asked question. So no, I actually don't think this is a big deal and would not do anything taking huge effort to make sure it did not happen again. But if the problem did appear a few times or by judgement someone thought that it would be likely to happen then it would be useful to work to avoid. If you have a lot of time to waste you might try finding Mail in the Linux Documentation Project tree. You do have a lot of time to waste, don't you? I mean, it *might* be in there. Somewhere. Yes, I tried this at length before I gave up and made my posting. Again, I didn't think there was much point in mentioning it. The name is an unfortunately common word. I like the links browser. It has some really nice features. But one of the worst things about it is the fact that the name cannot be searched for with any reasonable success. (For those interested look at the extended project Elinks, as in 'apt-get install elinks', successful because you can search for that name.) Picking an unsearchable project name is a bad thing that we know is a bad thing today. But back when Mail was created, who knew? Does Bob think that if I don't know that Mail = mail I am roughly equally likely not to know about cat or grep? If so, he is clearly looking down on me from a position of such altitude as to be quite unable to recognise the problems the rest of us have. I am sorry my treatise on the history of mailx disturbed you so greatly. It was not my intention. I was really only working from the premise of, See one, do one, teach one. The reason I shared that essay was that if you don't know about it that it will make no sense. But if you do know about it then many things make sense. I often learn great things from the people who work hard to share their knowledge. In that same spirit I try to give it back when I can. Bob
Re: Mail. Mail! Mail?
Zack Weinberg wrote: Bernard Leak [EMAIL PROTECTED] writes: Fine - but then it tells me (actually, the docs said this already) that I need the Mail program in my path. Not wanting to be obstructive or anything, but ... wot? This program should have been included with your operating system (I am assuming you are using a Unix variant). Not having it indicates a monumental error in the packaging or installation of your OS. mailx is the traditional command-line-mode mail user agent. Even if you don't use it it may be required by other programs. Just to add to Zack's fine answer and to tie some of these things together. In the old, old days the program /bin/mail was a simple command line mail program. Functional. But very stark. No way to specify a -s subject string on the command line for example. BSD added to this program and many others. They called their mail program mail as well and installed it in /usr/ucb/mail IIRC. Having the same program names worried others. So the program was also called called Mail to differentiate it from /bin/mail. The 1994 Makefile installs the program as both mail and Mail. http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/mail/Makefile?rev=1.1content-type=text/x-cvsweb-markup But having a program name which only differed by case bothered ATT and so in SysV they called the program mailx. This was distributed to most of the commercial unix systems of the day such as HP-UX where mailx is found but Mail is not. In the old days (old, not old old) everyone used either Mail or mailx depending on whether they were running a BSD or a SysV flavor system. Mail/mailx was vastly superior to /bin/mail. I used mailx for years. I know people who still only use mailx for mail. Habits die hard. POSIX has generally favored SysV and standardized on the mailx name and functionality. POSIX standard system are required to supply a mailx program. http://www.opengroup.org/onlinepubs/009695399/utilities/mailx.html In response the *BSD generally include a symlink to all three mail, Mail and mailx for compatibility. Debian supplies both for compatibility to either too. However RH only supplies Mail and do not supply mailx and miss on POSIX compatibility. And the reverse compatibility with BSD when HP-UX supplies only mailx and does not supply a Mail program. So you may have to switch from one to the other name for this functionality because it is used by a lot of scripts and programs. Now it wants 'sendmail'. ExCUSE me! I need to have *sendmail* installed in order to submit a test report? Perhaps more to the point, am I required to have *configured* it? [...] There is also the standard Unix low-level interface for sending mail, /usr/sbin/sendmail. Agreed. /usr/sbin/sendmail is a defacto standard interface to a generic Mail Transport Agent for sending mail. Also used by a lot of scripts and programs. Again, not having an MTA installed indicates a monumental error in the packaging or installation of your OS. You should have gotten all this stuff automatically, and the installation sequence should have prompted you for mail information and then set up the MTA for you. Agreed. However if you are working in some port environment you may be trying to bootstrap these things along and may want/need gcc to get other components bootstrapped. You may not have a working system to begin with. If you are trying to make progress regardless of the system problems you can probably replicate the Mail/mailx functionality. It reads standard input. It mails the contents to the address provided on the command line. The -s option sets the subject. I do not think any other options are used. As long as you do that then you can fake things out with a replicant. Bob
Re: Accessing the subversion repository
Christopher Faylor wrote: I don't think fsh is a good idea. That could mean potentially hundreds of persistent ssh connections sitting around on the server. There would at most be one per user making commits to the depot. Do you really have hundreds of people making commits? You probably have hundreds of people pulling sources by anonymous read-only access but that is a different path. I will agree that the default timeout value for fsh is too long. The default is apparently ten hours unless changed. For me personally 15 minutes is a good value and I would set the default on the server to something short. Bob
