December 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Need help: How to apply diffs generated by `cvs diff' 24 years, 4 months

Adrian Aichner

>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes: Martin> I tried to apply Daniel Pittman's patch created by `cvs Martin> diff' to my workspace using `patch -d /my/workspace'. Martin> However, it only patched the files in the root directory, Martin> like configure.in. Files in the lwlib/ directory couldn't Martin> be found by patch, even though the headers for those files Martin> look like: On Windows NT, the patch.exe that comes with the win32 binary works fine. Which patch program are you using? Best regards, Adrian

1 participants
0 comments

Need help: How to apply diffs generated by `cvs diff' 24 years, 4 months

Martin Buchholz

I tried to apply Daniel Pittman's patch created by `cvs diff' to my workspace using `patch -d /my/workspace'. However, it only patched the files in the root directory, like configure.in. Files in the lwlib/ directory couldn't be found by patch, even though the headers for those files look like: Index: lwlib/xlwradio.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/Attic/xlwradio.h,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 xlwradio.h --- xlwradio.h 1999/07/30 09:13:56 1.1.2.1 +++ xlwradio.h 1999/12/16 09:34:00 The documentation for `patch' indicates that it should look at the Index: line when patching. So why couldn't it find the file to patch? More generally, what is the procedure for applying patches generated by `cvs diff'? Why doesn't cvs generate headers that look like this instead? patch understands those. Index: lwlib/xlwradio.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/Attic/xlwradio.h,v retrieving revision 1.1.2.1 diff -u -r1.1.2.1 xlwradio.h --- lwlib/xlwradio.h 1999/07/30 09:13:56 1.1.2.1 +++ lwlib/xlwradio.h 1999/12/16 09:34:00 I'm using patch 2.5. Should I bother the CVS or the patch maintainers with a bug report? If so, which program is buggy? Martin

2 participants
1 comments

Re: Jobs assignments 24 years, 4 months

John S. J. Anderson

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes: Preface/Disclaimer: Ben wrote the text file that became jobs.html; I made it into HTML. There are some changes I'm comfortable making; there are some I'm not comfortable making. As I've indicated below those changes that I'm not comfortable making I'm waiting to hear from Ben on. Others may or may not wish to pitch in. As per Vin's earlier mail, I've changed the format of "name <name(a)xemacs.org>" links. I also did the s/Japanese/I18N/ change that's been discussed at length, and altered the description of that job based on mail that's been over this list. Feedback on that is urgently warranted. As for Hrvoje's suggestions: Hrvoje> Jan stated clearly he had not the time to be the core patch Hrvoje> tender, so he should likely be removed. However, you can Hrvoje> probably add me and him as the "secondary" for that job. done. Hrvoje> Stephen Turnbull objected against the "Japanese Liaison" Hrvoje> thing. Please take that objection into account. see above. Hrvoje> I did work on the LispRef manual. You can add me as the Hrvoje> "secondary" there. The same goes for the Internals manual and Hrvoje> PROBLEMS. done, done, done. Hrvoje> Sandra Wambold should be added as the primary FAQ maintainer, Hrvoje> Christian Nybo secondary (until he returns to claim his Hrvoje> position, or to resign). done. (nb: Christian has no xemacs.org address; fixing that may or may not be a priority, depending on his continuing participation.) Hrvoje> The "general design issues" job should be removed. Noone Hrvoje> should claim to be the primary person, and many more could be Hrvoje> listed as secondary. Ben: I need some guidance here. Hrvoje> You could add Kyle Jones as secondary for the portable dumper. done. Hrvoje> Remove the "minimal tagbits" job. That work is done, and Hrvoje> further developments, when they happen, do not require a Hrvoje> steady "job". Ben: Again with this one. Hrvoje> Windows support should include Adrian Aichner (and perhaps Hrvoje> more people) as secondary. done. Adrian also has no xemacs.org address (that I'm aware of). Hrvoje> Redisplay should include Jan Vroonhof as secondary. done. Hrvoje> Customize should include me and Didier Verna as secondary. done, and also Didier's follow-up about configure. Anyone else? john. -- ------------------------------------------------------------------------ John S Jacobs Anderson \ <URL:http://www.xemacs.org> You'll have to pry my Emacs from my cold \ jacobs(a)xemacs.org dead oversized control-pressing left pinky finger. -- Randal L. Schwartz

2 participants
1 comments

Re: Need help: How to apply diffs generated by `cvs diff' 24 years, 4 months

Hrvoje Niksic

Martin Buchholz <martin(a)xemacs.org> writes: > I tried to apply Daniel Pittman's patch created by `cvs diff' to my > workspace using `patch -d /my/workspace'. However, it only patched > the files in the root directory, like configure.in. Files in the > lwlib/ directory couldn't be found by patch, even though the headers > for those files look like: > > Index: lwlib/xlwradio.h > =================================================================== > RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/Attic/xlwradio.h,v > retrieving revision 1.1.2.1 > diff -u -r1.1.2.1 xlwradio.h > --- xlwradio.h 1999/07/30 09:13:56 1.1.2.1 > +++ xlwradio.h 1999/12/16 09:34:00 > > > The documentation for `patch' indicates that it should look at the > Index: line when patching. So why couldn't it find the file to > patch? > > More generally, what is the procedure for applying patches generated > by `cvs diff'? Try: POSIXLY_CORRECT=yes patch -d ... I think that works for RCS/CVS-style diffs. It used to work out of the box before the FSF people fucked up `patch'. Version 2.1 worked just fine. :-(

1 participants
0 comments

Re: [configure: feature request] Support configuration like `i386-linux'. 24 years, 4 months

Karl M. Hegbloom

>>>>> "Kyle" == Kyle Jones <kyle_jones(a)wonderworks.com> writes: Kyle> Karl M. Hegbloom writes: >> I would like if I could say `configure i386-linux', rather than >> `configure i386-debian-linux'. Here's why (one paragraph at >> top of page): Kyle> This makes no sense to me. Including the vendor type does Kyle> nothing prevent applications from wildcarding matches Kyle> against that field. Changing the string from three Kyle> components to two will break code. If you want to type Kyle> less, just type 'configure' and leave off the other stuff. Did you follow the link I posted and read the paragraph about it? I'm not the one who made that policy. I don't know why they decided that. It really doesn't matter to me, personally, what goes in that string as long as XEmacs builds and I can edit, read, and do other neat things with it. I will just use "i386-debian-linux".

2 participants
1 comments

Re: Jobs assignments 24 years, 4 months

Hrvoje Niksic

john s jacobs anderson <jacobs(a)xemacs.org> writes: > >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)iskon.hr> writes: > > Preface/Disclaimer: Ben wrote the text file that became jobs.html; I > made it into HTML. There are some changes I'm comfortable making; > there are some I'm not comfortable making. I understand that. My message was meant mostly for Ben. > Hrvoje> You could add Kyle Jones as secondary for the portable > Hrvoje> dumper. > > done. Has Kyle agreed? Near the beginning of my message, I wrote: [ In the following comments, it goes unsaid that a job should be given to someone iff he/she agrees to it. I didn't feel like repeating it in every entry. ]

2 participants
1 comments

Re: Weird byte-compiler tests 24 years, 4 months

Tor Arntsen

On Dec 20, 4:47, Hrvoje Niksic wrote: >ObXEmacs: what Perl mode are people actually *using*? The cperl mode >we ship behaves horribly. We're using perl-mode around here. I assume that's and "old" perl mode? -Tor

1 participants
0 comments

Re: [configure: feature request] Support configuration like `i386-linux'. 24 years, 4 months

Jan Vroonhof

karlheg(a)inetarena.com (Karl M. Hegbloom) writes: > I would like if I could say `configure i386-linux', rather than > `configure i386-debian-linux'. Here's why (one paragraph at top of > page): > > <URL:http://www.debian.org/doc/debian-policy/ch5.html> > .1 Architecture specification strings > > If a program needs to specify an architecture specification string > in some place, the following format has to be used: > > <arch>-<os> That idea seems broken to me. Configure machine types always have been been triples. > Note, that we don't want to use `<arch>-debian-linux' to apply to > the rule `architecture-vendor-os' since this would make our > programs incompatible to other Linux distributions. I would even prefer that they used <arch>-debian-linux since that is a good indication of the distribution used to compile it. Yet another data point to go by. I am not sure why that string would make them incompatible but even if that is so, it doesn't help much as Redhat uses i686-redhat-linux Jan

2 participants
1 comments

Re: Weird byte-compiler tests 24 years, 4 months

Jan Vroonhof

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > I'm sure I didn't write the additional code -- I patched it from a > message on xemacs-beta, which might have come from Jan. Its from me. I'm fairly sure I also send this as a patch at least semi-officially. > Does anyone remember what these tests were supposed to do, To illustrate a few problems with too aggressive optimizing by the byte-compiler. > and why they weren't applied? Because AFAIK, these particular problems in the byte-compiler aren't fixed yet. Jan

1 participants
0 comments

Re: Interesting CVS size stats 24 years, 4 months

Karl M. Hegbloom

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Martin Buchholz <martin(a)xemacs.org> writes: >> cvs.xemacs.org. Given that cvs.xemacs.org is also used by some >> people for real work, even doing this experiment was slightly >> naughty. Jan> But it only needs to be done once. Anyway 30MB is Jan> doable. That means it is only diskspace that is the problem Jan> which means that CVSup is a real option if only we had a Jan> server :-). There are Debian packages of `cvsup' now, in "potato". If a Debian server could be set up for that, you won't have to deal with building and installing cvsup.

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta December 1999