RE: generic-build-script

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

Re: generic-build-script

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

Re: generic-build-script

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

[Patch] g-b-s: New command: upgrade-self. (was: Re: generic-build-script extension to update version numbers in README)

Op Fri, 18 Nov 2005 23:20:25 -0500 schreef Charles Wilson in <437EA809.30204cwilson.fastmail.fm>: : Igor Pechtchanski wrote: [new gbs features] : Well, the problem is, logging is a decorator: it decorates the existing : functions. Unless you want a whole new build-with-logging() function :

Re: generic-build-script extension to update version numbers in README

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

Re: generic-build-script extension to update version numbers in README

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Franke wrote: > What would you think about an autoconf-like approach generating a > "package-VER.sh" script from some "package.sh.in" (yes, no version). > > Then fixes and new features will be added to only one generation tool > (autogbs ?-)

Re: generic-build-script extension to update version numbers in README

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

Re: generic-build-script extension to update version numbers in README

Igor Pechtchanski wrote: At the time I've thought long and hard about integrating more features. The original argument for including them was to allow the maintainers to release packages with minor modifications of the g-b-s (mostly to set parameters). And this worked for most *new* packages (t

Re: generic-build-script extension to update version numbers in README

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

Re: generic-build-script extension to update version numbers in README

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

RE: generic build script 'help' patch

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

RE: generic build script 'help' patch

> > 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.

RE: generic build script 'help' patch

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

RE: generic build script 'help' patch

> 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. As a guess, t

Re: Generic build script instructions

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> > : > > : > * templates/generic-build-s

Re: Generic build script instructions

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 (acceptpatch): New function t

Re: Generic build script instructions

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

Re: Generic build script instructions

On Sun, 20 Jun 2004, Bas van Gompel wrote: > Op Sat, 19 Jun 2004 17:11:22 -0400 (EDT) schreef Igor Pechtchanski: > : On Sat, 19 Jun 2004, Bas van Gompel wrote: > : > : > Op Fri, 18 Jun 2004 22:22:59 -0400 (EDT) schreef Igor Pechtchanski: > > [reason for not submitting packages?] > : > One, (s-lan

Re: Generic build script instructions

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

Re: Generic build script instructions

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. -- ) | | ---/ ---/ Yes, this | Thi

Re: Generic build script instructions

Op Sat, 19 Jun 2004 17:11:22 -0400 (EDT) schreef Igor Pechtchanski in <[EMAIL PROTECTED]>: : On Sat, 19 Jun 2004, Bas van Gompel wrote: : : > Op Fri, 18 Jun 2004 22:22:59 -0400 (EDT) schreef Igor Pechtchanski: ...Snipped some stuff that was going OT, enjoyable though it was... [reason for not su

Re: Generic build script instructions

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: > [] >

Re: Generic build script instructions

On Sat, 19 Jun 2004, Bas van Gompel wrote: > Op Fri, 18 Jun 2004 22:49:11 -0400 (EDT) schreef Igor Pechtchanski: > > [ask for two separate patches?] > > : I think I'd prefer the multiple parameters patch first, with its own > : ChangeLog. That part looks good enough to check in, actually. > > A

Re: Generic build script instructions

Op Fri, 18 Jun 2004 22:22:59 -0400 (EDT) schreef Igor Pechtchanski in <[EMAIL PROTECTED]>: : 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: [] : > : Cute, very cute... : > Ehh...

Re: Generic build script instructions

Op Fri, 18 Jun 2004 22:49:11 -0400 (EDT) schreef Igor Pechtchanski in <[EMAIL PROTECTED]>: [ask for two separate patches?] : I think I'd prefer the multiple parameters patch first, with its own : ChangeLog. That part looks good enough to check in, actually. Attached. ChangeLog entry: 2004-0

Re: Generic build script instructions

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

Re: Generic build script instructions

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

RE: Generic build script instructions

> > : 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,

Re: Generic build script instructions

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: > : > : > Op Tue, 15 Jun 2004 16:52:31 -0400 (EDT) schreef Igor Pechtchanski > : > : > : Cute, very cute... > Ehh... Thanks, I think. Ye

Re: Generic build script instructions

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, foo-0.1-1.sh) : (hereaft

Re: Generic build script instructions

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.

Re: Generic build script instructions

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

Re: Generic build script instructions

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

Re: Generic build script instructions

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... > : On Tue, 15 Jun 2004, Max Bowsher wrote: > [...] > : > This makes me wonder if it might be sensible for all package maintainers > : > to say a little about t

Re: Generic build script instructions

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

Re: Generic build script instructions

Op Tue, 15 Jun 2004 16:52:31 -0400 (EDT) schreef Igor Pechtchanski in <[EMAIL PROTECTED]>: : On Tue, 15 Jun 2004, Max Bowsher wrote: [...] : > This makes me wonder if it might be sensible for all package maintainers : > to say a little about their packaging methods, maybe even leading to a : > p

RE: Generic build script instructions

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

RE: Generic build script instructions

> 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

RE: Generic build script instructions

> 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

Re: Generic build script instructions

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

Re: Generic build script instructions

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

Re: Generic build script instructions

On Tue, 15 Jun 2004, Max Bowsher wrote: > 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 prop

RE: Generic build script instructions

> 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

RE: Generic build script instructions

> > 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. > > There are some instructions for using the g-b

Re: Generic build script instructions

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 how it was > intended to be used. Sa

Re: Generic build script instructions

"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. There are some instructions for using t

Re: Generic build script instructions

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" :-)

RE: Generic build script instructions

> > 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

RE: Generic build script instructions

> 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

Re: generic-build-script maintainership (WAS Re: non-widget child "DropSiteManager" error)

On Fri, Jan 23, 2004 at 08:52:42AM -0500, Igor Pechtchanski wrote: > I hope what I said below didn't come out as "I will take over > maintainership". Not really: I think the ``I don't have "a month worth of developers time". :-)'' was pretty clear that you didn't intend to take over maintainership

Re: generic-build-script maintainership (WAS Re: non-widget child "DropSiteManager" error)

Ronald, I hope what I said below didn't come out as "I will take over maintainership". I may be able to commit a few patches (since I have access already), but I doubt I'll have much time for extensive testing or reviewing of others' patches. It would make me much more comfortable if someone els

Re: generic-build-script maintainership (WAS Re: non-widget child "DropSiteManager" error)

My previous response notwithstanding, if you (Igor) do intend to take over maintainership of the generic build script, please feel free to go ahead and do it - I'll spend the time on something else (I've received a request to ITP libsegv, which currently fails two of four testsuite tests, and will

Re: generic-build-script maintainership (WAS Re: non-widget child "DropSiteManager" error)

On Wed, Jan 21, 2004 at 02:58:01PM -0500, Igor Pechtchanski wrote: > On Wed, 21 Jan 2004, Christopher Faylor wrote: > > > On Wed, Jan 21, 2004 at 02:43:00PM -0500, Igor Pechtchanski wrote: > > >Does count as > > >(temporarily) passing the baton?

RE: generic-build-script maintainership

One thing I'd love to see in the generic-build-script, is: set -e instead of all the horrible && \ stuff. This would make it easier to indent, reformat, add comments and greatly reduce the noise level. "set -e" works just fine in both ash and bash. It can also be turned off and on in functions if

Re: generic-build-script maintainership (WAS Re: non-widget child "DropSiteManager" error)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles Wilson wrote: | Off the top of my head, there were patches submitted for some bugfixes | (like the aformentioned sed stuff), functionality extensions (package | listings, gpg signing, etc), and more that I can't recall right now. Here is my subm

Re: generic-build-script maintainership (WAS Re: non-widget child "DropSiteManager" error)

Christopher Faylor wrote: On Wed, Jan 21, 2004 at 02:43:00PM -0500, Igor Pechtchanski wrote: Does count as (temporarily) passing the baton? Yes. What are you waiting for? :-) Igor -- go forth with my blessing. :-) Off the top of my head, the

RE: generic-build-script maintainership (WAS Re: non-widget child "DropSiteManager" error)

Igor Pechtchanski Sent: January 21, 2004 13:58 To: [EMAIL PROTECTED] Subject: Re: generic-build-script maintainership (WAS Re: non-widget child "DropSiteManager" error) On Wed, 21 Jan 2004, Christopher Faylor wrote: > On Wed, Jan 21, 2004 at 02:43:00PM -0500, Igor Pechtchanski w

Re: generic-build-script maintainership (WAS Re: non-widget child "DropSiteManager" error)

On Wed, 21 Jan 2004, Christopher Faylor wrote: > On Wed, Jan 21, 2004 at 02:43:00PM -0500, Igor Pechtchanski wrote: > >Does count as > >(temporarily) passing the baton? > > Yes. What are you waiting for? :-) > > cgf I don't have "a month worth

Re: generic-build-script maintainership (WAS Re: non-widget child "DropSiteManager" error)

On Wed, Jan 21, 2004 at 02:43:00PM -0500, Igor Pechtchanski wrote: >Does count as >(temporarily) passing the baton? Yes. What are you waiting for? :-) cgf