On Mon, Dec 21, 1998 at 09:09:30PM -0600, Andrew Feinberg wrote:
> Hello!
> I'm a new maintainer, and I'd like to be able to keep the package I'll
> be doing on master or va. The problem is, I don't know how I would go about
> repackaging without breaking the install since the paths would b
Shaleh writes:
> [ -x /usr/bin/update-menus ] && update-menus
> The problem with this is that ash incorrectly reads (or read) the -x. It
> behaves like a -f and not the intended "if it exists and is executable".
> It responds true for ANY file in /usr/bin, or other directories. Seems
> to catch
On 22-Dec-98 [EMAIL PROTECTED] wrote:
> Marcelo E. Magallon writes:
>> #!/bin/sh -e
>
>> [ -x /usr/bin/update-menus ] && update-menus
>
The problem with this is that ash incorrectly reads (or read) the -x. It
behaves like a -f and not the intended "if it exists and is executable". It
responds
Hi John,
On Mon, Dec 21, 1998 at 10:48:59PM -0600, [EMAIL PROTECTED] wrote:
> A script consisting only of those two lines will return 1, and so it
> should. It will do so for bash or ash. It would do so for the Bourne
> shell.
Ok. This is the shortest script that exhibits this:
#! /bin/sh
I maintain several packages using PRCS[1] and I'd like not to have the
package.prj and .prcs_aux files (located in the top directory) showing
up in the diff, since they don't belong to the sources.
Is there anyway to tell dpkg-buildpackage to exclude some files from
the diff?
Sam
Footnotes:
On Mon, 21 Dec 1998, Andrew Feinberg wrote:
> Also, my package is on multiple platforms. If I'm building a package for
> i386, how would I build it for the others if I don't have access to
> those types of boxen?
This is a good question.
The answer is that there are already people in Debian dedi
Mark Brown wrote:
> Making mpich a multi-binary package is the obvious way but this ties
> the manual pages into being provided by the mpich package. Should some
> other people come along and provide even better manuals it could cause
> hassle later on.
No, it won't be hard to generate the manpag
Marcelo E. Magallon writes:
> #!/bin/sh -e
> [ -x /usr/bin/update-menus ] && update-menus
> I've got a bug report that says it is.
It isn't.
> Ash bails out with exit status 1 if update-menus doesn't exist.
A script consisting only of those two lines will return 1, and so it
should. It will d
Peter S Galbraith wrote:
> Obviously, my xplot_1.18.orig.tar.gz file won't correspond
> exactly to upstream sources (it'll be smaller!), but that's okay
> too right?
You have to weigh a space savings vs pistine source. Is 1.2 mb space savings
worth not using pristine source? I don't know.
--
see
On Mon, 21 Dec 1998, Marcelo E. Magallon wrote:
> #!/bin/sh -e
>
> [ -x /usr/bin/update-menus ] && update-menus
>
> I've got a bug report that says it is. Ash bails out with exit status
> 1 if update-menus doesn't exist.
Looks ok (tested on sun's /bin/sh, no bash). Is that the whole script?
#!/bin/sh -e
[ -x /usr/bin/update-menus ] && update-menus
I've got a bug report that says it is. Ash bails out with exit status
1 if update-menus doesn't exist.
Marcelo
Hello!
I'm a new maintainer, and I'd like to be able to keep the package I'll
be doing on master or va. The problem is, I don't know how I would go about
repackaging without breaking the install since the paths would be different if
I packaged from my ~dir. Does anyone know how I could d
My mpich package provides a fairly complete set of manual pages for the
MPI API, which are useful not only for mpich users but also for users of
other MPI implementations such as LAM. I'd like to provide them as a
seperate package but I'm not sure exactly how to go about this.
Making mpich a mult
13 matches
Mail list logo
