10:22 p.m.
[Moved to xemacs-beta]
On Wed, 2003-02-05 at 23:32, Uwe Brauer wrote:
I updated and tested the new auctex reales, but then I had
difficulties with the patch.
First I unpackages the Original auctex-11.13.tgz in the main tree,
renamed the old one auctex-10g the new one auctex. I copied all the
CVS files and dir
I would strongly recommend against that. It may work if done carefully,
but you really shouldn't even try. See below.
from 10g to former 11.13, after the necessary change
in the Makefile Changelog etc, succesfull generating the bindis,
testing etc etc
I tried
>
> Here's a brief rundown of how a package gets released:
> -----------------------------------------------------
> You
> - hack hack hack
> - cvs diff -u > cool-new-patch.diff
but got
cvs diff: in directory .:
cvs [diff aborted]: *PANIC* administration files missing
Which looks pretty bad.
Yup, probably this is due to something wrong in the copying of the CVS/
dirs and files.
I did a diff -u auctex-10g auctex > auctex.patch but this is not
what
is required.
Nope, but it is actually pretty close.
"diff --exclude CVS -Nru auctex-10g auctex > auctex.patch"
...would result in almost what you're looking for, but it's not worth
much since the you won't be able to commit from the new auctex dir due
to the same problems you saw with "cvs diff".
At this point, I think this would be the best way to proceed:
1) rm -rf the auctex-10g dir
2) Move away the (new) auctex dir, into somewhere safe, let's say
~/auctex-new
3) cd to packages/xemacs-packages
4) cvs update
5) cd to auctex (that should reappear in cvs update, if it do
6) Start processing the files from ~/auctex-new one by one (excluding
all CVS/*)
- For all files that exist in both dirs, just copy the one from
~/auctex-new overwriting the existing one in xemacs-packages/auctex
- For files that exist in xemacs-packages/auctex but not in
~/auctex-new, do a "rm foo ; cvs rm foo" in
xemacs-packages/auctex. But *only* if the files are not needed any
more.
- For files that are in ~/auctex-new but not in
xemacs-packages/auctex, copy and "cvs add" them in the latter.
7) Update Makefile and package-info.in (provides) with files
removed/added as necessary.
8) Do a "cvs diff -u > ~/auctex-sync.patch" and send ~/auctex-sync.patch
to xemacs-patches, we'll take a look.
A useful way of checking the status of a dir is "cvs -nq update".
Sorry my first contact with CVS, please tell me where is
the right place to discuss this, since I am not sure to send this
question to xemacs-beta, or xemacs-patches.
See <http://www.xemacs.org/Lists/index.html>;. Basically, if unsure, go
for xemacs-beta. But extensive general CVS support is somewhat
off-topic there... try to seek information elsewhere. You can also mail
me directly about this, I'll try to help out.
<http://www.cvshome.org/communication.html> could be useful too.
HTH,
--
\/ille Skyttä
scop at xemacs.org
12:17 a.m.
New subject: Syncing packages to upstream one oh one. (was: Welcome to The XEmacs Development Team.)
|--==> "VS" == Ville Skytt <Ville> writes:
VS> At this point, I think this would be the best way to proceed:
Yep, looks good. I generally do my syncing like this:
1) diff -urNb xemacs-pkg-src/ upstream-src/ > initial-patch.diff
I use that as a starting point and reference if I need it. I *don't*
send 'initial-patch.diff' to xemacs-patches, it's only for my own
personal use to aid in syncing.
2) find xemacs-src/ -type f | xargs grep -l \
"[Xx][Ee]macs [Cc]hange" > files-to-inspect-closely
This should give you a list of files in the XEmacs package source that
have been modified for XEmacs. This isn't a definitive list because
those "XEmacs change" comments aren't always used, but it is a good
starting point.
I'll go through these files one by one and see if those changes are
still needed in the upstream. If so, create a diff (diff -u our-file
their-file > upstream.diff) and send it upstream, asking if they could
incorporate it into their next release.
3) Look for '*.upstream' files in xemacs-pkg-src/ and rename the equiv
upstream-src/ files accordingly
4) Make a backup of xemacs-pkg-src/ then rm all the files (sans
any CVS/*) from xemacs-pkg-src/. Dump upstream-src/* into
xemacs-pkg-src/
5) M-x cvs-update RET /path/to/xemacs-pkg-src/ RET
The resulting CVS buffer gives you a number of things that you need to
pay attention to:
- "Up-to-date" files need to be 'cvs rm'd' because they
don't
exist in the upstream-src/ These files may also need to be
removed from the Makefile (ELCS), so at this point, fix the
Makefile. Then "mark" these files in the CVS buffer by
pressing 'm' on each one and then press 'r' to 'cvs rm'
them. (type 'u' on these files to "unmark" them).
- "Unknown" files need to be 'cvs add'd' because they
don't
exist in the xemacs-pkg-src/ These files may also need to
be added to the Makefile (ELCS), so at this point, fix the
Makefile accordingly. Then "mark" thses files (same as
above), and type 'a' to 'cvs add' them. Unmark them as
above.
_*DON'T* commit anything at this point._
Now the CVS buffer should only have "Modified", "Removed", or
"Added"
files in it.
6) Make another backup of the xemacs-pkg-src/ in case things go
wrong in the next steps.
7) C-x d /path/to/xemacs-pkg-src/ RET
M-x compile RET make RET
(save the compilation buffer)
As you can see, I now do a test build. If it doesn't build at all,
investigate and fix. If the fix is something outside of the Makefile,
in other words, in one of the upstream .el files etc, then prepare a
patch to go upstream. But 9 times out of 10 it would probably be
something to do with the Makefile or similar.
Check to make sure that everything got built (there's no missing .elc
files), fix the Makefile if needed.
8) Test the other Makefile targets ('clean', 'distclean',
'bindist', 'install').
Make sure they all work correctly. Be careful to make sure that
'clean' and 'distclean' does *NOT* delete any .el files. This will
happen if you list any files in the Makefile ELCS as *.el instead of
*.elc. This is also one of the reasons for step 6) above. :-P
9) Remember that saved compilation buffer? Now scan through it
looking for "The following function(s) are not known to be
defined:" warnings.
Some of these can be ignored (eg 'overlay*' functions if the package
takes into account both Emacs and XEmacs and uses our extents, or
'timer*' functions if the package takes into account our 'itimer*'
functions). It's sometimes not an easy call, but you can always ask
if you're not sure.
Some of these undefined function warnings can be fixed by adding
things to the Makefile (REQUIRES).
10) Repeat steps 7, 8, and 9 if you've made changes along the
way.
11) Make sure that 'package-info.in' is correct and up to date,
especially 'provides'. I do it like this:
grep "(provide '" *.el | cut -d "'" -f 2 | cut -d
")" -f 1
That gives you what needs to be in 'provides' in package-info.in.
Update it as necessary.
12) Update 'AUTHOR_VERSION' in the Makefile.
13) Install the package on your system and test, test, test it.
Finally we get to the actual testing. Why isn't this done a lot
further up the list, say at step 1?
Because the package has to function correctly as an XEmacs package.
If you can't build an XEmacs package in the XEmacs packages source
tree out of what you're syncing there's not much point in going
further. That's why I always make sure it'll build first, then I
make sure the package does what it is supposed to do.
14) Test it some more, in every possible way you can think of.
15) Repeat step 14.
16) See step 15.
17) Prepare a patch to send in to xemacs-patches. This is made
real easy if you have Didier's excellent "patcher" (it's in
xemacs-devel), or you can, from your mail buffer, do:
C-u M-! cvs diff -uN xemacs-pkg-src/ RET
Remove the ChangeLog hunks and then:
C-u M-! cvs diff -U 0 xemacs-pkg-src/ChangeLog RET
18) Send in the patch.
19) cvs ci -m "Sync to upstream version X" xemacs-pkg-src/
I'm not 100% sure if that command line is correct because I always use
either patcher.el or PCL-CVS.
And you might want to wait before you commit to see if anyone objects
to the patch for any reason.
That should be about it, I think it pretty well covers everything.
Maybe something similar to this should go into a TeXinfo file
somewhere?
Any comments? Is anything blatantly wrong or did I leave anything
out? Ville, what do you think?
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
4:15 p.m.
New subject: Syncing packages to upstream one oh one. (was: Welcome to The XEmacs Development Team.)
On Sun, 2003-02-09 at 02:17, Steve Youngs wrote:
|--==> "VS" == Ville Skytt <Ville> writes:
VS> At this point, I think this would be the best way to proceed:
Yep, looks good. I generally do my syncing like this:
1) diff -urNb xemacs-pkg-src/ upstream-src/ > initial-patch.diff
I use that as a starting point and reference if I need it. I *don't*
send 'initial-patch.diff' to xemacs-patches, it's only for my own
personal use to aid in syncing.
This is pretty much where I start too. Additionally, I try to arrange
upstream-src/ so that the directory layout matches the XEmacs one before
doing the diff. And I don't use the -N switch there, I prefer to handle
new/removed files outside of the patch.
From this point on, my process is somewhat similar to Steve's, but
I
like to more work by hand, using the diff file generated above in
diff-mode, I like it.
For each hunk, I do a C-c C-t just for kicks and to get the source file
to scroll to the point where the hunk is supposed to apply, and to
verify that it actually does.
I usually start with syncing trivial and obvious changes, such as
whitespace, typo fixes etc. I split the diff hunks with C-c C-s where
necessary, and apply the hunks I'm comfortable with using C-c C-a. Be
aware that if you split the hunks using diff-mode, the resulting diff
won't necessarily be patch(1) compatible any more, but diff-mode will
work just fine.
Whenever a hunk has been applied, I kill it from the diff with M-k and
move on to the next one. Every now and then I save the diff as well as
files with applied hunks. This makes it possible to checkpoint a sync
and continue later.
After the trivial changes have been taken care of, there's the first
chance of committing the changes. This depends on how big the sync is,
it may ease reviewers work later when the "meat" from the patch is about
to be applied.
Then, I move on to processing new files (ie. ones that are in
upstream-src/ only). I copy them one by one to xemacs-pkg-src/, read
'em through and apply the changes from the diff that are required by the
new files. Usually, whenever a new file will be added, action is
required on Makefile and package-info.in too. Ditto for removed files.
With removed ones, more care is needed since we package extra files in
some packages (ie. ones that aren't present in the upstream pkg), eg.
psgml-html.el in the PSGML package.
Next, I iterate through the remaining diff, usually applying closely
related things in one pass, and studying the changes. Paying extra
attention to the "XEmacs change" notes is a good idea here. If my eyes
catch a dependency on a new package here, I add it to Makefile
(REQUIRES) "on the fly".
When I'm finished with the diff, or earlier from a "checkpoint", I start
test building the package, according to Steve's post (step 7 and the
ones after it). One good addition to this list is to build the package
"alone", eg:
cd packages
make distclean autoloads
cd xemacs-packages/pkg-under-sync
make install
This is a good (and probably the only easy) way to catch missing
indirect dependencies.
A couple of miscellaneous points:
When adding files, binary ones should be added with "cvs add -kb" and
files with upstream CVS keywords such as $Id, $Revision or $Log, with
"cvs add -ko" to prevent our CVS from clobbering the tags/files and from
generating unnecessary (though small) differences to the upstream
version.
This is a good thing to do, but forgetting about it doesn't necessarily
screw anything up; if there are problems, they can be solved with "cvs
admin -ko" or "cvs admin -kb" later. Problems failing to do this
usually manifest themselves in "cvs checkout" corrupting binary files.
The resulting CVS buffer gives you a number of things that you need
to
pay attention to:
- "Up-to-date" files need to be 'cvs rm'd' because they
don't
exist in the upstream-src/ These files may also need to be
removed from the Makefile (ELCS), so at this point, fix the
Makefile. Then "mark" these files in the CVS buffer by
pressing 'm' on each one and then press 'r' to 'cvs
rm'
them. (type 'u' on these files to "unmark" them).
I might be missing the context partially here because my process is
somewhat different, but I smell potential danger here. It is possible
that there are files that haven't had any changes between upstream
releases and we have an equivalent version. Giving the general advice
to 'cvs rm' those (ie. "Up-to-date" ones) gives me the creeps...
19) cvs ci -m "Sync to upstream version X"
xemacs-pkg-src/
I'm not 100% sure if that command line is correct because I always use
either patcher.el or PCL-CVS.
It seems to be correct.
That should be about it, I think it pretty well covers everything.
Maybe something similar to this should go into a TeXinfo file
somewhere?
Any comments? Is anything blatantly wrong or did I leave anything
out? Ville, what do you think?
Looks good to me, thanks! At the very least, providing archive links to
these messages somewhere should be done. It would be great if someone
could prepare a skeletal TeXinfo file based on this thread
(TeX-illiterate-Ville here) and prepare it for addition into the
general-docs package.
--
\/ille Skyttä
scop at xemacs.org
4:39 p.m.
New subject: Syncing packages to upstream one oh one. (was: Welcome to The XEmacs Development Team.)
On Sun, 2003-02-09 at 18:15, Ville Skyttä wrote:
Forgot to mention that sometimes, if there are a lot of whitespace
changes, it's better to send an "informational" non-whitespace diff for
review, ie. do a "cvs diff -wbBu".
--
\/ille Skyttä
scop at xemacs.org
5:21 p.m.
New subject: Syncing packages to upstream one oh one.
|--==> "VS" == Ville Skytt <Ville> writes:
VS> On Sun, 2003-02-09 at 02:17, Steve Youngs wrote:
>Yep, looks good. I generally do my syncing like this:
>
>1) diff -urNb xemacs-pkg-src/ upstream-src/ > initial-patch.diff
>
>I use that as a starting point and reference if I need it. I *don't*
>send 'initial-patch.diff' to xemacs-patches, it's only for my own
>personal use to aid in syncing.
VS> This is pretty much where I start too. Additionally, I try to arrange
VS> upstream-src/ so that the directory layout matches the XEmacs one before
VS> doing the diff.
Good point.
>From this point on, my process is somewhat similar to Steve's,
but I
VS> like to more work by hand, using the diff file generated above in
VS> diff-mode, I like it.
I'm not overly familiar with diff-mode (beyond the basics anyway).
Maybe I should get more acquainted with it.
VS> With removed ones, more care is needed since we package extra files in
VS> some packages (ie. ones that aren't present in the upstream pkg), eg.
VS> psgml-html.el in the PSGML package.
Yes, that is something you need to be aware of. Intimate knowledge of
the package you're synching helps here. :-)
VS> When I'm finished with the diff, or earlier from a "checkpoint", I
start
VS> test building the package, according to Steve's post (step 7 and the
VS> ones after it). One good addition to this list is to build the package
VS> "alone", eg:
VS> cd packages
VS> make distclean autoloads
VS> cd xemacs-packages/pkg-under-sync
VS> make install
VS> This is a good (and probably the only easy) way to catch missing
VS> indirect dependencies.
Yes. Another good point. I think I more or less implied this in my
previous post, but thanks very much for making it clearer, Ville.
>The resulting CVS buffer gives you a number of things that you
need to
>pay attention to:
>
>- "Up-to-date" files need to be 'cvs rm'd' because they
don't
>exist in the upstream-src/ These files may also need to be
>removed from the Makefile (ELCS), so at this point, fix the
>Makefile. Then "mark" these files in the CVS buffer by
>pressing 'm' on each one and then press 'r' to 'cvs rm'
>them. (type 'u' on these files to "unmark" them).
VS> I might be missing the context partially here because my process is
VS> somewhat different, but I smell potential danger here. It is possible
VS> that there are files that haven't had any changes between upstream
VS> releases and we have an equivalent version. Giving the general advice
VS> to 'cvs rm' those (ie. "Up-to-date" ones) gives me the
creeps...
I understand your concerns, but if you read my previous post again a
paragraph or so higher up you'll see how I do it. When I do the
cvs-update the only files in place are the upstream ones. So the
"Up-to-date" files are files that existed in the XEmacs package but
not in the upstream package.
And I'm comforted in the knowledge that it is (mostly) hard to shoot
yourself in the foot with CVS. You can always go back to a previous
version of any particular file.
>Any comments? Is anything blatantly wrong or did I leave
anything
>out? Ville, what do you think?
VS> Looks good to me, thanks! At the very least, providing archive
VS> links to these messages somewhere should be done.
Somewhere under "Developing XEmacs" on www.xemacs.org, and in Adrian's
~/.abbrev_defs for starters. :-P
VS> It would be great if someone could prepare a skeletal TeXinfo
VS> file based on this thread (TeX-illiterate-Ville here) and prepare
VS> it for addition into the general-docs package.
I could do it, but it would be a very long time before I could get to
it. Perhaps somebody else would like to run with this.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
7957
days inactive
7961
days old
4 comments
2 participants
participants (2)
-
Steve Youngs -
Ville Skyttä