Yeah. It was the virus scanner. Thank you for your advice!
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Brian Dessent
Sent: Mittwoch, 5. März 2008 00:02
To: cygwin-apps@cygwin.com
Subject: Re: generic-build-script
Gergely Budai wrote:
> mv: can
Brian Dessent wrote:
Gergely Budai wrote:
mv: cannot move `p7zip-4.57' to `../p7zip-4.57-orig': Permission denied
FYI:
http://cygwin.com/ml/cygwin-apps/2007-06/msg00046.html
"[ITP] p7zip"
...with special support for NOT building the (GPL-incompatible) RAR
stuff. Never got enough votes, s
Gergely Budai wrote:
> mv: cannot move `p7zip-4.57' to `../p7zip-4.57-orig': Permission denied
This is probably caused by a handle remaining open for some short period
of time after tar has completed writing the files, such that mv starts
before it closes. On a normal system, I don't think this
I am using the generic-build-script as a template for my package scripts and
I have noticed a strange thing when running it.
When I make a './foo-vendor-release.sh first' run, I get randomly the
following error :
.
p7zip-4.57/man1/7zr.1
p7zip-4.57/README
p7zip-4.57/TODO
mv: cannot m
The latest generic-build-script fails in the spkg step:
-- tar: Cannot update compressed archives
Try `tar --help' or `tar --usage' for more information.
Ciao
Volker
at the two copies, though -- the
current code will pass all the regular files directly to /usr/bin/install,
and, AFAIK, /usr/bin/install does not replicate directory structure...
There *is* a small bug in the directory handling code which the patch
below fixes (I'll check it in shortly), but i
I'd like some feedback on changes I made to the gbs for
fortune-1.99.1-2.
--- gbs.sh 2006-01-15 17:46:43.875859200 -0800
+++ fortune-1.99.1-2.sh 2006-01-15 22:26:48.129188800 -0800
@@ -66,6 +66,8 @@
fi
export src_orig_pkg=${topdir}/${src_orig_pkg_name}
+export debian_patch=fortune-mod_1.9
command, the script
attempts to get the HEAD-version from cvs, if it hasn't in the last
24 hours. This HEAD-version is invoked with the `version' command
to get it's CVS-revision. If it was just downloaded, the HEAD revision
is stored in /usr/share/gbs as generic-build-script-H
Charles Wilson wrote:
I'd like to make a request: gbs is getting out of control with this
feature and that feature added. Some of these tasks are NEVER going to
be performed by anyone other than the primary maintainer: has anyone
actually used 'foo.sh list' or 'foo.sh depends'?
I use these t
ic editing of the g-b-s for my own packages.
Attached is 'gbsmunge.py', which reads a control file, and the
generic-build-script source, and outputs a build script munged according
to instructions in the control file.
For illustrative purposes, here is the control file for my n
Igor Pechtchanski wrote:
[...]
P.S. It'd be a different story if we were using an 'engine' with
external overrides, like mingwports or cgf's netrel(?) -- then mods to
the engine to provide new features would be distinct from the
package-specific overrides. But gbs ain't like that.
Wh
If I imported the "official" generic-build-script as
a "vendor branch", then I could more easily do a 'cvs merge -j
vendor-release-27' within a workspace on the 'gettext' branch...
That would have made this a lot easier. But now, it's just too muc
On Fri, 18 Nov 2005, Charles Wilson wrote:
> Christian Franke wrote:
> > the build-script of the smartmontools package creates the
> > "Cygwin/package-*.README" file from
> > "srcdir/CYGWIN-PATCHES/package.README.in" by replacing VER/REL with the
> > current version/release numbers.
> >
> > This m
Christian Franke wrote:
the build-script of the smartmontools package creates the
"Cygwin/package-*.README" file from
"srcdir/CYGWIN-PATCHES/package.README.in" by replacing VER/REL with the
current version/release numbers.
This might be useful for other packages to avoid extra editing of READ
l for other packages to avoid extra editing of README
on each minor release.
A patch for generic-build-script 1.43 is attached.
Christian
--- generic-build-script.orig Sat Nov 12 15:21:55 2005
+++ generic-build-scriptFri Nov 18 10:54:58 2005
@@ -220,9 +220,16 @@
mkdir -p ${
[snip]
>
> Gary,
>
> Do you use the g-b-s for mutt?
Yep. For the last two or three releases.
> If so, would you care to
> submit the changes that factor out config variables *you*
> needed? If possible, please leave the default, rather than
> mutt-specific, values in the patch, but I'd ra
On Tue, 21 Jun 2005, Gary R. Van Sickle wrote:
> [snip]
> > > It's perhaps worth mentioning that I don't maintain any per-package
> > > customizations to the g-b-s directly, but instead have written
> > > myself a Python script which modifies the basic g-b-s according to a
> > > per-package rules
[snip]
> > It's perhaps worth mentioning that I don't maintain any per-package
> > customizations to the g-b-s directly, but instead have
> written myself
> > a Python script which modifies the basic g-b-s according to a
> > per-package rules file.
> >
> > For example, here are my rules for neo
On Wed, 22 Jun 2005, Max Bowsher wrote:
Igor Pechtchanski wrote:
> On Tue, 21 Jun 2005, Gary R. Van Sickle wrote:
>
> > > If BASEPKG seems better for the upstream package name,
> >
> > What about just ${UPSTREAM_PACKAGE_NAME}?
>
> You know, the thought did cross my mind. But the above is just u
Igor Pechtchanski wrote:
On Tue, 21 Jun 2005, Gary R. Van Sickle wrote:
If BASEPKG seems better for the upstream package name,
What about just ${UPSTREAM_PACKAGE_NAME}?
You know, the thought did cross my mind. But the above is just unwieldy
enough to remove it from consideration.
OTOH, it
On Tue, 21 Jun 2005, Gary R. Van Sickle wrote:
> > If BASEPKG seems better for the upstream package name,
>
> What about just ${UPSTREAM_PACKAGE_NAME}?
You know, the thought did cross my mind. But the above is just unwieldy
enough to remove it from consideration.
OTOH, it would be nice if all o
; > > SHORTPKG
> > > FULLPKG
> > > ?
> >
> > I like the latter, FWIW. But we could go with ${PKG}-${VER} for now, and
> > factor it out into a variable later if it becomes a nuisance.
>
> As I considered the comment, I realized it was easier to explain i
> If BASEPKG seems better for the upstream package name,
What about just ${UPSTREAM_PACKAGE_NAME}?
--
Gary R. Van Sickle
with SHORTPKG.
2005-06-21 Max Bowsher <[EMAIL PROTECTED]>
* generic-build-script (SHORTPKG): New variable.
(install): Use ${SHORTPKG} instead of ${BASEPKG} when referring to the
Cygwin package with the release number omitted, rather than the
upstream base packag
On Tue, 21 Jun 2005, Max Bowsher wrote:
> Igor Pechtchanski wrote:
> > On Tue, 21 Jun 2005, Harold L Hunt II wrote:
> >
> > > Max Bowsher wrote:
> > > [...]
> > > > Of course, normally these are the same, but in my case they are not.
> > > > Therefore, the following patch changes all occurrences w
Igor Pechtchanski wrote:
On Tue, 21 Jun 2005, Harold L Hunt II wrote:
Max Bowsher wrote:
[...]
Of course, normally these are the same, but in my case they are not.
Therefore, the following patch changes all occurrences where ${BASEPKG} is
used in the second sense to ${PKG}-${VER}, so that ${BA
Igor Pechtchanski wrote:
On Tue, 21 Jun 2005, Max Bowsher wrote:
Two generic build script patches.
Number 1:
In doing the httpd->apache2 thing recently mentioned, I found that g-b-s
could use some tweaks to support this better. ${BASEPKG} is currently
used by the script in two differ
On Tue, 21 Jun 2005, Harold L Hunt II wrote:
> Max Bowsher wrote:
> [...]
> > Of course, normally these are the same, but in my case they are not.
> > Therefore, the following patch changes all occurrences where ${BASEPKG} is
> > used in the second sense to ${PKG}-${VER}, so that ${BASEPKG} may be
s/Since I've not/Since I've now/
Harold
Harold L Hunt II wrote:
Since I've not written three times more words that would be in such a
comment, I might as well give it a go:
Max Bowsher wrote:
[...]
Of course, normally these are the same, but in my case they are not.
Therefore, the following patch changes all occurrences where ${BASEPKG}
is used in the second sense to ${PKG}-${VER}, so that ${BASEPKG} may be
redefined in my case.
[...]
Max,
My two cents:
Stick
On Tue, 21 Jun 2005, Max Bowsher wrote:
> Two generic build script patches.
>
> Number 1:
> In doing the httpd->apache2 thing recently mentioned, I found that g-b-s
> could use some tweaks to support this better. ${BASEPKG} is currently
> used by the script in two diffe
Two generic build script patches.
Number 1:
In doing the httpd->apache2 thing recently mentioned, I found that g-b-s could use some tweaks to
support this better. ${BASEPKG} is currently used by the script in two different ways:
1): name-version of the base upstream package
2): name-version
>
> Well, I don't mind adding code that'll do both kinds of copies (using
> "install" in the flat case, and "tar" in the tree case), but the main
> question is how to distinguish between them? I.e., as you said, does
> "doc/*.html" mean a flat copy or a tree copy? Does "doc/*.html/" for tree
> c
On Fri, 15 Oct 2004, Gareth Pearce wrote:
> > Even simpler -- it works for wildcards aiming from a single target
> > directory to a single source directory, i.e., it won't magically flatten a
> > directory tree for you, you'll have to use "find" for that...
> >
> > If you need to copy directory st
>
> Even simpler -- it works for wildcards aiming from a single target
> directory to a single source directory, i.e., it won't magically flatten a
> directory tree for you, you'll have to use "find" for that...
>
> If you need to copy directory structures using the install_docs mechanism,
> I su
tree for you, you'll have to use "find" for that...
If you need to copy directory structures using the install_docs mechanism,
I suppose it could be done with something like the patch below -- give it
a shot. You will have to put a "/" after each directory that you want
copi
>
> On Wed, 13 Oct 2004, Charles Wilson wrote:
>
> > Igor Pechtchanski wrote:
> >
> > > You're right, it *is* broken. It was never intended to be used with
> > > subdirectories, so I never tested it. I'll try to come up with a way
> > > of accomodating subdirs shortly.
>
> In fact, it shouldn
On Wed, 13 Oct 2004, Charles Wilson wrote:
> Igor Pechtchanski wrote:
>
> > You're right, it *is* broken. It was never intended to be used with
> > subdirectories, so I never tested it. I'll try to come up with a way
> > of accomodating subdirs shortly.
In fact, it shouldn't've worked with wild
Igor wrote:
> On Mon, 11 Oct 2004, Hannu E K Nevalainen wrote:
>> Igor: I hacked around some, and ended up short of my intentions; in
>> hope it "helps" some I've *EDITED down* my changes to the attached
>> patch.
>>
>> Feel free to do with it whatever you like. (Non copyrighted
>> material, cgf B
[EMAIL PROTECTED]
ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED]
|,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski, Ph.D.
'---''(_/--' `-'\_) fL a.k.a Jagu
On Wed, 13 Oct 2004, Gareth Pearce wrote:
> While I was packaging cyrus-sasl I ran into an odd issue with the installed
> documentation. I attempted to add doc/*.html to the install_docs variable,
> this failed. Oddly doc/*.fig worked - but there was only one doc/*.fig file
> ChangeLog* also wor
On Wed, 13 Oct 2004, Schulman.Andrew wrote:
> >> Whatever happened to the idea of getting rid of all the extraneous
> >> &&\ crap in gbs? Was the idea rejected, or forgotten?
> >> --
> >> Chuck
> >
> > Neither. Someone actively producing new package versions (i.e., not
> > me) was supposed to te
While I was packaging cyrus-sasl I ran into an odd issue with the installed
documentation. I attempted to add doc/*.html to the install_docs variable,
this failed. Oddly doc/*.fig worked - but there was only one doc/*.fig file
ChangeLog* also worked, and there was only one ChangeLog file. It loo
>> Whatever happened to the idea of getting rid of all the extraneous
&&\
>> crap in gbs? Was the idea rejected, or forgotten?
>> --
>> Chuck
>
> Neither. Someone actively producing new package versions (i.e., not
me)
> was supposed to test it and make sure it works properly. This would
be
>
> > There is one problem IMO; the script (with the patch) won't allow
> > displaying help unless there is a matching
> > "generic-build.{tar,tar.bz,tar.gz}" (or some such, you get the
picture I
> > hope) file in the same dir.
I thought about this, but decided it wasn't important for end-users.
^^^
> > > this and make sure it always works properly, and if nobody else
^^^
> > > protests, I'll consider patching the generic-build-script.
> >
> >
> > Yes, I've never liked the silly looking '&&
onsider
patching the generic-build-script.
Yes, I've never liked the silly looking '&& \' syntax in the gbs. If
propagation of 'set +e' into functions is a problem, then just have each
function re-do it...
mkdirs() {(
set +e
cd ${topdir}
rm -fr ${objdir}
On Mon, 11 Oct 2004, Hannu E K Nevalainen wrote:
> you wrote:
> > Feel free to improve the particulars of my help text. The main thing
> > is that I think some help text is needed.
> >
> > Andrew.
>
> There is one problem IMO; the script (with the patch) won't allow
> displaying help unless there
On Thu, 30 Sep 2004, Igor Pechtchanski wrote:
> On Fri, 1 Oct 2004, Lapo Luchini wrote:
>
> > Dr. Volker Zell wrote:
> > >(cd ${instdir} && \
> > >find ${instdir} -name "*.exe" -o -name "*.dll" | xargs cygcheck | \
> > >sed -e '/\.exe/d' -e 's,\\,/,g' | sort -bu | xargs -n1 cygpath -u
> Here is a patch that adds some 'help' or 'usage' text to the
> generic build script. This seems to me to be a useful thing
> for someone who has downloaded and unpacked a package source
> archive; sees the package source, patch, and build script;
> and w
Here is a patch that adds some 'help' or 'usage' text to the generic
build script. This seems to me to be a useful thing for someone who has
downloaded and unpacked a package source archive; sees the package source,
patch, and build script; and wonders what to do next.
On Fri, 1 Oct 2004, Lapo Luchini wrote:
> Dr. Volker Zell wrote:
> >(cd ${instdir} && \
> >find ${instdir} -name "*.exe" -o -name "*.dll" | xargs cygcheck | \
> >sed -e '/\.exe/d' -e 's,\\,/,g' | sort -bu | xargs -n1 cygpath -u \
> > - | xargs cygcheck -f | sed 's%^% %' ; \
> > + |
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dr. Volker Zell wrote:
>(cd ${instdir} && \
>find ${instdir} -name "*.exe" -o -name "*.dll" | xargs cygcheck | \
>sed -e '/\.exe/d' -e 's,\\,/,g' | sort -bu | xargs -n1 cygpath -u \
> - | xargs cygcheck -f | sed 's%^% %' ; \
> + | xargs
Hi
2004-09-30 Dr. Volker Zell <[EMAIL PROTECTED]>
* generic-build-script: Make output of depend function unique
diff -u -p /usr/local/src/generic-build-script.orig /usr/local/src/generic-build-script
--- /usr/local/src/generic-build-script.orig2004-09-30 19:09:20.639184000
On Thu, 23 Sep 2004, Bas van Gompel wrote:
> Op Sun, 20 Jun 2004 10:38:57 -0400 (EDT) schreef Igor Pechtchanski:
> : On Sun, 20 Jun 2004, Bas van Gompel wrote:
> [...]
>
> : > ChangeLog entry:
> : >
> : > 2004-06-20 Bas van Gompel bavag.tmfweb.nl>
> : >
Op Sun, 20 Jun 2004 10:38:57 -0400 (EDT) schreef Igor Pechtchanski
in <[EMAIL PROTECTED]>:
: On Sun, 20 Jun 2004, Bas van Gompel wrote:
[...]
: > ChangeLog entry:
: >
: > 2004-06-20 Bas van Gompel <[EMAIL PROTECTED]>
: >
: > * templates/generic-build-script
On Fri, 13 Aug 2004, Gerrit P. Haase wrote:
> Hello Igor,
>
> On 12. August 2004, Igor wrote:
>
> > On Thu, 12 Aug 2004, Robb, Sam wrote:
>
> [...]
>
> >> - When compressing info files as part of an install, uses the
> >> -exec option of find rather than xargs.
> >>
> >> Packages that already
On Thu, Aug 12, 2004 at 11:41:03PM -0400, Robb, Sam wrote:
> > It was actually right there on the xargs man page... ;-) Ok, so
> > it's settled -- I'll change your patch to do that instead of the
> > -exec option.
>
> Just curious - is there a reason to prefer xargs vs. -exec? I know
> that xarg
Hello Igor,
On 12. August 2004, Igor wrote:
> On Thu, 12 Aug 2004, Robb, Sam wrote:
[...]
>> - When compressing info files as part of an install, uses the
>> -exec option of find rather than xargs.
>>
>> Packages that already compress info files on install will create
>> an info dir, but
> It was actually right there on the xargs man page... ;-) Ok, so it's
> settled -- I'll change your patch to do that instead of the
> -exec option.
Just curious - is there a reason to prefer xargs vs. -exec? I know
that xargs can be used to avoid shell command line length limits,
but are there
lly don't want to compress something if it's already been
compressed by the upstream build, and breaking upstream hard links may not
be a good idea.
> If I understnad things correctly, the warning is there to let you know
> that you're breaking a hard link; but I'm not s
> Good catch. I'd rather add the '-r' ('--no-run-if-empty') flag to the
> all of the xargs invocations, though.
Told you I wasn't familiar with xargs :-) I really need to spend some
time and get more comfortable with it.
> > - When compressing files using gzip as part of an install, adds
> >
he xargs invocations, though.
> - When compressing files using gzip as part of an install, adds
> the -f flag to the gzip arguments to force compression.
>
> -Samrobb
Why? Is it just to force compression of files that wouldn't benefit from
it? Frankly, I'm not clear o
le is found.
- When compressing files using gzip as part of an install, adds
the -f flag to the gzip arguments to force compression.
-Samrobb
--- generic-build-script.orig 2004-08-12 12:46:42.923790400 -0400
+++ generic-build-script2004-08-12 12:46:42.733516800 -0400
@@ -1,4 +1,4 @@
-#
On Thu, 15 Jul 2004, Harold L Hunt II wrote:
> There is the following in the gbs:
>
> if [ -z "$MY_CFLAGS" ]; then
>MY_CFLAGS="-O2"
> fi
> if [ -z "$MY_CFLAGS" ]; then
>MY_LDFLAGS=
> fi
>
> It appears that the second if should be testing '$MY_LDFLAGS', not
> '$MY_CFLAGS'.
>
> Harold
Thank
There is the following in the gbs:
if [ -z "$MY_CFLAGS" ]; then
MY_CFLAGS="-O2"
fi
if [ -z "$MY_CFLAGS" ]; then
MY_LDFLAGS=
fi
It appears that the second if should be testing '$MY_LDFLAGS', not
'$MY_CFLAGS'.
Harold
Op Sun, 20 Jun 2004 10:38:57 -0400 (EDT) schreef Igor Pechtchanski
in <[EMAIL PROTECTED]>:
: On Sun, 20 Jun 2004, Bas van Gompel wrote:
:
: > Op Sat, 19 Jun 2004 17:11:22 -0400 (EDT) schreef Igor Pechtchanski:
[submitting locally maintained packages?]
: > : Oh. Well, if nothing else, it's a val
atch" is not the best name]
> ["savepatch", ``acceptpatch'')
> :
> : As I said, these were suggestions. "acceptpatch" sounds fine to me.
> : Unless anyone objects, we can go with that.
>
> I'm attaching the patch.
>
> ChangeLog entry:
&
Op Sun, 20 Jun 2004 08:00:03 +0200 (MET DST)
schreef ik in <[EMAIL PROTECTED]>:
[...]
: Not really. Just keep a copy of the unedited gbs in topdir until you
: round off your changes and get ready to do a ``spkg''. At that time
: store the diff (or gbs-orig) into C-P. (Just remember to recreate t
Op Sat, 19 Jun 2004 15:24:06 -0400 (EDT) schreef Igor Pechtchanski
in <[EMAIL PROTECTED]>:
: On Sat, 19 Jun 2004, Bas van Gompel wrote:
[...]
: > * templates/generic-build-script: Allow multiple arguments.
: Committed, thanks.
SHTDI, KUTGW,
Buzz.
--
) | | ---/ ---/
: As I said, these were suggestions. "acceptpatch" sounds fine to me.
: Unless anyone objects, we can go with that.
I'm attaching the patch.
ChangeLog entry:
2004-06-20 Bas van Gompel <[EMAIL PROTECTED]>
* templates/generic-build-script (acceptpatch): New functi
se 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-PATC
h to check in, actually.
>
> Attached.
>
> ChangeLog entry:
>
> 2004-06-19 Bas van Gompel <[EMAIL PROTECTED]>
>
> * templates/generic-build-script: Allow multiple arguments.
Committed, thanks.
Igor
--
http://cs.nyu.edu/~pec
e 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 <
ntry:
2004-06-19 Bas van Gompel <[EMAIL PROTECTED]>
* templates/generic-build-script: Allow multiple arguments.
:As for the
: "ispatch" part, let's discuss the name and the possible functionality (you
: mentioned adding extra), and then it can be an add
Igor Pechtchanski schrieb:
On Sat, 19 Jun 2004, Bas van Gompel wrote:
: > Each of them does:
: >
: > *) Allow more than one argument at a time (e.g. do
: > ``./boffo-1.0.36-1.sh prep conf build'').
: >
: > *) An ``ispatch'' command, copying a fresh patch, to make the porting
: > process easier. (Wh
On Sat, 19 Jun 2004, Bas van Gompel wrote:
> Op Fri, 18 Jun 2004 09:04:42 -0400 (EDT) schreef Igor Pechtchanski:
> [...]
> : > + ( exit ${STATUS} ) || exit ${STATUS}
> : ^^
> : > + shift
> : > +done
> :
> : Do we really need a subshell here? Isn't an "if" test enough (and
> > : 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,
h a very
> : > impractical structure)?
> : >
> : > Isn't it more in style with method 2 to store a copy of the gbs,
> : > before you made any mods to it, in CYGWIN-PATCHES? you can then
> : > always (diff out any changes you made/merge in changes from t
Op Mon, 14 Jun 2004 23:58:25 -0400 schreef Robb, Sam
in <[EMAIL PROTECTED]>:
[Instructions for using the generic build script]
:Right now, it looks like it's something like:
:
:1) Get source tarball (ex, foo-0.1.tar.gz)
:2) Rename GBS as appropriate (ex, f
Op Fri, 18 Jun 2004 09:04:42 -0400 (EDT) schreef Igor Pechtchanski
in <[EMAIL PROTECTED]>:
[...]
: > + ( exit ${STATUS} ) || exit ${STATUS}
: ^^
: > + shift
: > +done
:
: Do we really need a subshell here? Isn't an "if" test enough (and more
: efficient)?
Some thoughts.
Op Fri, 18 Jun 2004 08:58:42 -0400 (EDT) schreef Igor Pechtchanski in
<[EMAIL PROTECTED]>:
: On Fri, 18 Jun 2004, Bas van Gompel wrote:
:
: > Op Tue, 15 Jun 2004 16:52:31 -0400 (EDT) schreef Igor Pechtchanski
: > :
:
: Cute, very cute...
Ehh... Thanks, I think.
[...package maintainers could tak
Bas,
Oh, and one more comment:
On Fri, 18 Jun 2004, Bas van Gompel wrote:
> [snip]
> @@ -339,6 +344,7 @@ case $1 in
> strip && pkg && spkg && finish ; \
> STATUS=$? ;;
>*) echo "Error: bad arguments" ; exit 1 ;;
> -esac
> -exit ${STATUS}
> -
> + esac
> + ( e
ygwin.com/cgi-bin/cvsweb.cgi/packaging/templates/generic-build-script?cvsroot=cygwin-apps&only_with_tag=HEAD>)
> : to their packages and let me (and this list, I guess) know what changes
> : needed to be made, we could try to extract common patterns and include
> : them into the C
At 05:26 18-6-04, I wrote:
: Following are two patches, one (inline) for review (ignoring
: changes in whitespace) and one (attached) for easy application
: (``patch
gbs-loop-ispatch.patch
Description: Binary data
Buzz.
--
) | | ---/ ---/ Yes, this | This message consists of true | I do not
leading to a
: > plan for a new standard cygwin package building system.
[...]
: I absolutely agree. If package maintainers could take some time to try to
: adapt the CVS HEAD of the GBS
:
(<http://cygwin.com/cgi-bin/cvsweb.cgi/packaging/templates/generic-build-script?cvsroot=cygwin-apps&
On Thu, 17 Jun 2004, Robb, Sam wrote:
> > Well, yes, I agree that if you really anticipate having to maintain
> > multiple packages from the outset, and want to keep more or less the same
> > build procedure for each of them (helps if they are related), you should
> > probably start already with s
> So, to answer that question, why not something like this:
>
> # --- BEGIN_DEFS ---
> if [ -f ${FULLPKG}.defs ]; then
> . ${FULLPKG}.defs
> fi
> # --- END_DEFS ---
>
> So, if my source package name is foo.tar.Z, then I can put the
[snip]
> following in my defs file:
>
> # Maintain
> Well, yes, I agree that if you really anticipate having to maintain
> multiple packages from the outset, and want to keep more or less the same
> build procedure for each of them (helps if they are related), you should
> probably start already with something more sophisticated than the gbs.
I do
On Wed, 16 Jun 2004, Charles Wilson wrote:
> Igor Pechtchanski wrote:
>
> > P.S. FWIW, another idea I had, akin to Max's python approach, was to
> > actually append a (wrapped) GBS patch to the GBS instead of changing the
> > script directly, and have the GBS detect that fact and apply the patch t
Igor Pechtchanski wrote:
P.S. FWIW, another idea I had, akin to Max's python approach, was to
actually append a (wrapped) GBS patch to the GBS instead of changing the
script directly, and have the GBS detect that fact and apply the patch to
itself, then running the resulting script (piping it to an
o say a little about their packaging methods, maybe even leading to a
> plan for a new standard cygwin package building system.
>
> Max.
I absolutely agree. If package maintainers could take some time to try to
adapt the CVS HEAD of the GBS
(<http://cygwin.com/cgi-bin/cvsweb.cgi/pac
> Basically, the GBS is supposed to be a template, which you
> adapt for each
> package. For a lot of packages it can be used as-is, as it
> will determine
> the tarball extraction method, the package name, etc
> automatically. But
> in some cases (non-standard archiving, different name for a
> > Are there any instructions for using the generic
> > build script, aside from what's documented in the
> > gdb itself? I'm looking at using the gbs for a couple
> > of packages, and I'm trying to understand how it was
> > intended to be used.
>
On Mon, 14 Jun 2004, Robb, Sam wrote:
> Igor et. al.,
>
> Are there any instructions for using the generic
> build script, aside from what's documented in the
> gdb itself? I'm looking at using the gbs for a couple
> of packages, and I'm trying to understand
"Robb, Sam" wrote:
> Are there any instructions for using the generic
> build script, aside from what's documented in the
> gdb itself? I'm looking at using the gbs for a couple
> of packages, and I'm trying to understand how it was
> intended to be used
Robb, Sam wrote:
>>> 9) Generate a patch (./gbs mkpatch)
>>> 10) Clean (./gbs mkpatch)
>>
>> should these both be mkpatch? ;)
>
> Hmm. Perhaps that's my problem :-)
>
> The question still remains: assuming that I'm entering
> the proper commands (instead of trying to clean using
> "mkpatch" :-)
> > 9) Generate a patch (./gbs mkpatch)
> > 10) Clean (./gbs mkpatch)
>
> should these both be mkpatch? ;)
Hmm. Perhaps that's my problem :-)
The question still remains: assuming that I'm entering
the proper commands (instead of trying to clean using
"mkpatch" :-), is this more or less the w
> 9) Generate a patch (./gbs mkpatch)
> 10) Clean (./gbs mkpatch)
should these both be mkpatch? ;)
J.
This e-mail has come from Experian International: winner of the UK's National Business
of the Year Award 2003.
==
In
Igor et. al.,
Are there any instructions for using the generic
build script, aside from what's documented in the
gdb itself? I'm looking at using the gbs for a couple
of packages, and I'm trying to understand how it was
intended to be used.
Right now, it looks like it's
1 - 100 of 179 matches
Mail list logo
