> 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
> > 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
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" :-)
"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
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
> > 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
> 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
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
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
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
> 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
> 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
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
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
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
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
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
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
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 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
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
> > : 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,
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
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
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
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...
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
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:
> []
>
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
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
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
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
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
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
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
35 matches
Mail list logo
