On Sat, 19 Jun 2004, Bas van Gompel wrote: > Op Fri, 18 Jun 2004 22:22:59 -0400 (EDT) schreef Igor Pechtchanski: > : On Sat, 19 Jun 2004, Bas van Gompel wrote: > : > : > Op Fri, 18 Jun 2004 08:58:42 -0400 (EDT) schreef Igor Pechtchanski: > : > : On Fri, 18 Jun 2004, Bas van Gompel wrote: > [<pechtcha at see es dot and why you dot ee dee you>] > : > : Cute, very cute... > : > Ehh... Thanks, I think. > : > : Yeah, I just never saw this particular obfuscation before, is all. :-) > > I did it by hand. (I know, I should get a job.)
...hey, it was funny... :-) > [EMBI] > : > Excuse My Butting In. > : > : Ok, this one's on its way to the OLOCA. :-D > <g> FWIW, it just got there. > [package maintainers] > : > I keep some packages locally, following changes are in them... > : > : Then, as far as I'm concerned, you're a maintainer. Any particular reason > : for not submitting those packages, though? License issues, perhaps? > > One, (s-lang) is rather complex and I expect I could not really > support it. It also builds OOTB (sort of). (I'll consider votes an > incentive to start cleaning up my patches >:-> ). The other is just > waiting for the announced maintainer to publish his work. (core-utils) Oh. Well, if nothing else, it's a valuable experience for you... > [...] > : > The change in indentation makes the ``ispatch()'' call hard to spot, > : > hence the (botched) copy. > : > : Why not submit two separate patches, then? ;-) > > The change in indentation would still affect many lines which are not > functionally changed. (I would thus want to add a 3rd patch.) Umm, that's fine, you expect an indentation change when adding a while loop. I just didn't want to have another independent change sneak in there unnoticed. The multiple args patch has been committed, so the issue is moot. > [the purpose of "ispatch()"] > : > In other words: ``ispatch'' copies the patch generated by ``mkpatch'' > : > from .sinst to ${topdir}, so it can be used now, not just get included > : > by ``spkg''. > : > : I see. That's not quite the way I use the gbs (I never edit the patched > : directory, but keep the original edited version separately). > > ? I'm talking about when you first port the app, or when you are > changing to a new upstream version. > > : Perhaps > : "ispatch" is not the best name for it? > > Could be. You use it when you determine this _is_ the correct patch. > > : Looks like "savepatch" might be > : better... As I never intend to use this feature, the above is just a > : suggestion. > > I would expect that --``savepatch''-- to do st else (like store the > patch from ${topdir} someplace). But if you insist I'll change it to > that. I would prefer st different, though. (``acceptpatch'' maybe?) As I said, these were suggestions. "acceptpatch" sounds fine to me. Unless anyone objects, we can go with that. > : > : > : We could also try putting some more > : > : > : autodetection code into the GBS (e.g., get "make" to try both the "test" > : > : > : rule and the "check" rule -- the two most common names for running the > : > : > : testsuite -- and pick the one that exists). > : > : > > : > : > I saw a trick that might be usable for this somewhere... i'll get back > : > : > to you on it... > : > : > : > : I think we could use something like "make -n" and check the return code... > : > : But as I don't have the time to implement it properly now, I'll look at > : > : whatever methods people choose to provide in their patches. > : > > : > It was something using a ``make -f -'' IIRC... (l8r) > : > : Hmm, "make -f -" will actually not be useful, FWICS. We want to check > : whether the Makefile contains either a "test" or a "check" rule, whereas > : "make -f -" will bypass the Makefile altogether. But if I'm wrong, it > : won't be the first time. > > Found it. it uses ``-f Makefile -f -'' to get the value of > a Makefile-variable, and is of no use to us here. ``make -n'' > is probably the WTG. Okay, we'll see what can be done. > [snip] > : > [append a (wrapped) GBS patch to the GBS] > [store gbs, before mods to CYGWIN-PATCHES] > > : Oh. Well, again, I never store the build script into CYGWIN-PATCHES, but > : it doesn't mean that nobody else should... Everyone has his own methods. > > I'm not saying anybody _should_, just that it will make upgrading the > specific-build-script easier. > > : > Or maybe just store the diff? One could then recreate the original gbs > : > to merge against. > : > : That's more or less what I'm proposing. Take the (default) gbs, add a > : section to it that does something like > : > : (echo "--- generic-build-script > : +++ $0"; cat <<END-OF-PATCH > : @@ -1,100 +1,100 @@ > : - patch goes here > : + patch goes here > : END-OF-PATCH > : ) | patch && exec "$0" > : > : and let the maintainers put their patches between the "cat" and > : "END-OF-PATCH". At least, that's what I had in mind. Then the set of > : changes to the gbs can be easily extracted (and moved) to the new version. > > Let me get this straight. First you take a copy of gbs. you edit it. > You make a diff against the orig gbs. you paste that diff into yet > another copy of the gbs. you then run the last one, which will then > recreate the file you had before, by editing itself inplace? _Now_ I > *am* confused. Umm, on reviewing it in light of morning (it was late night when I wrote the above yesterday), it does look nonsensical. I probably meant something like (echo "--- generic-build-script +++ $0"; cat <<END-OF-PATCH @@ -1,100 +1,100 @@ - patch goes here + patch goes here END-OF-PATCH ) | patch -o tmp.$$.sh && exec tmp.$$.sh instead. This certainly makes more sense... > : Hope this clears up the confusion, > > I think storing the diff in CYGWIN-PATCHES (and having it automatically > be included in foo-x.y-z.patch) is cleanest/clearest. This, IMO, creates a chicken-and-egg problem, as the patched directory won't be available until the script is run... Also, foo-x.y-z.patch usually stores the diff between the original source and the Cygwin package source, and the original won't have contained the unpatched gbs... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_ [EMAIL PROTECTED] ZZZzz /,`.-'`' -. ;-;;,_ [EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D. '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! "I have since come to realize that being between your mentor and his route to the bathroom is a major career booster." -- Patrick Naughton