On Sat, May 12, 2001 at 11:12:34PM -0400, Jimmy Kaplowitz wrote:
> On Sat, May 12, 2001 at 10:10:30PM -0400, Brian Ristuccia wrote:
> >
> > Choice 3 is best. People who live in countries where the use of cryptography
> > is restricted are probably subject to being arbitrarily jailed or murdered
>
On Sat, 12 May 2001, Jimmy Kaplowitz wrote:
> On Sat, May 12, 2001 at 10:10:30PM -0400, Brian Ristuccia wrote:
> and not main, it's not a typo) to "non-US", and file a bug on ftp.debian.org
> for the removal of main/althea, am I correct? Also, since the version I would
Yes
> in main, anyone who t
>>"Jimmy" == Jimmy Kaplowitz <[EMAIL PROTECTED]> writes:
Jimmy> That would be easier. I did sort of want to keep a Makefile in
Jimmy> place that is called Makefile, so that a simple "make" command
Jimmy> still works, but I guess that could be taken care of by a
Jimmy> symlink. Thanks for the
On Sat, May 12, 2001 at 10:10:30PM -0400, Brian Ristuccia wrote:
>
> Choice 3 is best. People who live in countries where the use of cryptography
> is restricted are probably subject to being arbitrarily jailed or murdered
> by their state's government anyway. Going out of your way to provide
> cr
On Sat, May 12, 2001 at 09:52:48PM -0400, Jimmy Kaplowitz wrote:
> Thank you all very much for replying. I am torn between three avenues that I
> am
> considering taking.
>
> Choice 3: Just change the main althea package to include ssl support, and add
> to the package description and README.Debi
That would be easier. I did sort of want to keep a Makefile in place that is
called Makefile, so that a simple "make" command still works, but I guess that
could be taken care of by a symlink. Thanks for the suggestion.
- Jimmy Kaplowitz
[EMAIL PROTECTED]
On Sat, May 12, 2001 at 12:37:08PM -0500,
Thank you all very much for replying. I am torn between three avenues that I am
considering taking.
Choice 1: Keep althea in main and make a completely separate althea-ssl package
in non-US. This would allow me to provide a source package for althea that has
no Build-Dependency on libssl-dev, whic
On Sat, 12 May 2001, Jimmy Kaplowitz wrote:
> On Sat, May 12, 2001 at 10:10:30PM -0400, Brian Ristuccia wrote:
> and not main, it's not a typo) to "non-US", and file a bug on ftp.debian.org
> for the removal of main/althea, am I correct? Also, since the version I would
Yes
> in main, anyone who
On Sat, May 12, 2001 at 10:10:30PM -0400, Brian Ristuccia wrote:
>
> Choice 3 is best. People who live in countries where the use of cryptography
> is restricted are probably subject to being arbitrarily jailed or murdered
> by their state's government anyway. Going out of your way to provide
> c
On Sat, May 12, 2001 at 09:52:48PM -0400, Jimmy Kaplowitz wrote:
> Thank you all very much for replying. I am torn between three avenues that I am
> considering taking.
>
> Choice 3: Just change the main althea package to include ssl support, and add
> to the package description and README.Debian
That would be easier. I did sort of want to keep a Makefile in place that is
called Makefile, so that a simple "make" command still works, but I guess that
could be taken care of by a symlink. Thanks for the suggestion.
- Jimmy Kaplowitz
[EMAIL PROTECTED]
On Sat, May 12, 2001 at 12:37:08PM -0500
Thank you all very much for replying. I am torn between three avenues that I am
considering taking.
Choice 1: Keep althea in main and make a completely separate althea-ssl package
in non-US. This would allow me to provide a source package for althea that has
no Build-Dependency on libssl-dev, whi
Mikael Djurfeldt <[EMAIL PROTECTED]> writes:
> GOOPS will compile differently under libguile1.3-dev and
> libguile1.4-dev.
Hi. I told you I'd get back to you :> I just had no idea how long
it would take :<
> I'm therefore considering breaking up the GOOPS packages into
> libgoops1.3-0.9.0 and l
Mikael Djurfeldt <[EMAIL PROTECTED]> writes:
> GOOPS will compile differently under libguile1.3-dev and
> libguile1.4-dev.
Hi. I told you I'd get back to you :> I just had no idea how long
it would take :<
> I'm therefore considering breaking up the GOOPS packages into
> libgoops1.3-0.9.0 and
>>"Jimmy" == Jimmy Kaplowitz <[EMAIL PROTECTED]> writes:
Jimmy> Why is it not sufficient to do something like the following
Jimmy> pseudo-code in debian/rules:
[Delete hack with amke/cp/sed/make/cp back]
Would it not be simpler just to use
$(MAKE) -f Makefile.with.ssl
>>"Jimmy" == Jimmy Kaplowitz <[EMAIL PROTECTED]> writes:
Jimmy> Why is it not sufficient to do something like the following
Jimmy> pseudo-code in debian/rules:
[Delete hack with amke/cp/sed/make/cp back]
Would it not be simpler just to use
$(MAKE) -f Makefile.with.ss
I haven't looked at dh_make_perl. Back a long time ago I started
to work on a Debian-specific architecture file for ExtUtils, but
it was a bad time to be doing this (dh/debmaker were in flux and
there was no real perl policy yet.)
Whoever writes/maintains dh_make_perl may want to take a look
at
I haven't looked at dh_make_perl. Back a long time ago I started
to work on a Debian-specific architecture file for ExtUtils, but
it was a bad time to be doing this (dh/debmaker were in flux and
there was no real perl policy yet.)
Whoever writes/maintains dh_make_perl may want to take a look
a
18 matches
Mail list logo
