http://lists.debian.org/debian-mentors-9808/msg00015.html
Hello!
We are sorry, but we changed our old "monitorsolution.com", and
"heartforyou.com" links and replaced them by:
bestnetplace.com (which group all monitors activities/related links)
You actualy have a link to us (thanks again) on your
On Fri, May 04, 2001 at 08:50:22AM +0200, Support Team wrote:
> http://lists.debian.org/debian-mentors-9808/msg00015.html
>
> Hello!
> We are sorry, but we changed our old "monitorsolution.com", and
> "heartforyou.com" links and replaced them by:
> bestnetplace.com (which group all monitors activi
Joey Hess <[EMAIL PROTECTED]> writes:
> > Now it's just an annoyance. Only the binary target needs root access.
>
> Not quite. The clean target still should run as root unless you're building
> with fakeroot. For a variety of reasons, many people (and autobuilders
> too, I think) don't use fakero
On Fri, May 04, 2001 at 10:46:56AM +0200, Robert Bihlmeyer wrote:
> Us lazy people would like to save 9 letters on the clean call, and of
> course we're far too far in sloth as to
> alias dcln='fakeroot debian/rules clean'
I just "debuild clean". (From devscripts.)
--
Paul Martin <[EMAIL PROTE
I know a little about buildd, but I guess that it try to build a package
and it if fail someone take its logs and submit a bug report.
At the end of the build process I guess that the build environment is
totally cleaned and that survive only a build log.
Is it possible to have access to a snapsho
On Fri, May 04, 2001 at 10:46:56AM +0200, Robert Bihlmeyer wrote:
> Us lazy people would like to save 9 letters on the clean call, and of
> course we're far too far in sloth as to
> alias dcln='fakeroot debian/rules clean'
I always keep a 'fakeroot debian/rules ' in the shell history, so
it usua
Stefano Zacchiroli wrote:
>
> I know a little about buildd, but I guess that it try to build a package
> and it if fail someone take its logs and submit a bug report.
> At the end of the build process I guess that the build environment is
> totally cleaned and that survive only a build log.
Most
On Fri, May 04, 2001 at 10:36:31AM +0200, Stefano Zacchiroli wrote:
> I know a little about buildd, but I guess that it try to build a package
> and it if fail someone take its logs and submit a bug report.
> At the end of the build process I guess that the build environment is
> totally cleaned an
Hello,
as far as I got it, a package with a version containing a '-X' is a
native package.
I packaged a programm (of myself). It contains a debian-directory and
I can generate a native source-package out of the source, giving
ppplog_0.7.tar.gz and ppplog_0.7.dsc. If I change the version from 0.7
M G Berberich wrote:
> Hello,
>
> as far as I got it, a package with a version containing a '-X' is a
> native package.
>
> I packaged a programm (of myself). It contains a debian-directory and
> I can generate a native source-package out of the source, giving
> ppplog_0.7.tar.gz and ppplog_0.7
On Thu, 3 May 2001, Bradley Bell wrote:
> It looks like it is just making explicit the restrictions which already exist
> in law (whatever those might be), and is not part of the license per se.
If the license references a law that restricts the rights of certain users,
and this law results in a
Hi,
Branden Robinson writes:
>
>
> Sorry, I tend to ignore wankers who want everything sugar-coated.
Aah, the joys of electronic communication.
Anyway, I think the original problem should be taken to debian-mentors
because it doesn't really relate to the PowerPC architecture. The
situation i
I'm considering packaging BET, a 128-bit blowfish-encrypted talk daemon.
However, it relies on a non-DFSG complian library, even though the program
itself is GPL.
I'm presuming BET should therefore go into non-free, and I should also
package the library itself. Is this correct? If so, are there an
> I'm considering packaging BET, a 128-bit blowfish-encrypted talk daemon.
> However, it relies on a non-DFSG complian library, even though the program
> itself is GPL.
Then it belongs in contrib. Anything which is itself free but has non-free
dependencies should go in contrib.
Eric
Sorry, didn't clarify. I should package the library for non-free and the
bet for contrib, correct?
~Warren Stramiello
> Sorry, didn't clarify. I should package the library for non-free and the
> bet for contrib, correct?
Correct.
Eric
On Fri, 04 May 2001, Warren Stramiello wrote:
> Sorry, didn't clarify. I should package the library for non-free and the
> bet for contrib, correct?
Yes.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
Warren Stramiello wrote:
> I'm considering packaging BET, a 128-bit blowfish-encrypted talk daemon.
> However, it relies on a non-DFSG complian library, even though the program
> itself is GPL.
The license needs to have an exemption for the GPL-incompatible
library it uses.
Peter
Hi Peter!
You wrote:
> > I'm considering packaging BET, a 128-bit blowfish-encrypted talk daemon.
> > However, it relies on a non-DFSG complian library, even though the program
> > itself is GPL.
>
> The license needs to have an exemption for the GPL-incompatible
> library it uses.
Indeed. If t
Robert Bihlmeyer wrote:
> Could dh_clean be extended to trap not-allowed-to-remove errors and
> issue a helpful message similar to dh_testroot? Then dh_testroot could
> be removed from the clean target, and it would just work for the most
> common cases, and give good diagnostic for common mistakes
On Fri, May 04, 2001 at 11:20:00AM +0100, Paul Martin wrote:
> On Fri, May 04, 2001 at 10:46:56AM +0200, Robert Bihlmeyer wrote:
> > Us lazy people would like to save 9 letters on the clean call, and of
> > course we're far too far in sloth as to
> > alias dcln='fakeroot debian/rules clean'
>
>
On 4 May 2001, Jens Schmalzing wrote:
> The config script informs the user that a number of configuration
> files need to be present, that they won't be touched by Debian if they
> have been edited by the user, and that to make sure they will be
> created by Debian they should be deleted now.
Wha
On Fri, May 04, 2001 at 08:50:22AM +0200, Support Team wrote:
> http://lists.debian.org/debian-mentors-9808/msg00015.html
>
> Hello!
> We are sorry, but we changed our old "monitorsolution.com", and
> "heartforyou.com" links and replaced them by:
> bestnetplace.com (which group all monitors activ
Joey Hess <[EMAIL PROTECTED]> writes:
> > Now it's just an annoyance. Only the binary target needs root access.
>
> Not quite. The clean target still should run as root unless you're building
> with fakeroot. For a variety of reasons, many people (and autobuilders
> too, I think) don't use faker
On Fri, May 04, 2001 at 10:46:56AM +0200, Robert Bihlmeyer wrote:
> Us lazy people would like to save 9 letters on the clean call, and of
> course we're far too far in sloth as to
> alias dcln='fakeroot debian/rules clean'
I just "debuild clean". (From devscripts.)
--
Paul Martin <[EMAIL PROT
I know a little about buildd, but I guess that it try to build a package
and it if fail someone take its logs and submit a bug report.
At the end of the build process I guess that the build environment is
totally cleaned and that survive only a build log.
Is it possible to have access to a snapsh
On Fri, May 04, 2001 at 10:46:56AM +0200, Robert Bihlmeyer wrote:
> Us lazy people would like to save 9 letters on the clean call, and of
> course we're far too far in sloth as to
> alias dcln='fakeroot debian/rules clean'
I always keep a 'fakeroot debian/rules ' in the shell history, so
it usu
Stefano Zacchiroli wrote:
>
> I know a little about buildd, but I guess that it try to build a package
> and it if fail someone take its logs and submit a bug report.
> At the end of the build process I guess that the build environment is
> totally cleaned and that survive only a build log.
Most
On Fri, May 04, 2001 at 10:36:31AM +0200, Stefano Zacchiroli wrote:
> I know a little about buildd, but I guess that it try to build a package
> and it if fail someone take its logs and submit a bug report.
> At the end of the build process I guess that the build environment is
> totally cleaned a
Hello,
as far as I got it, a package with a version containing a '-X' is a
native package.
I packaged a programm (of myself). It contains a debian-directory and
I can generate a native source-package out of the source, giving
ppplog_0.7.tar.gz and ppplog_0.7.dsc. If I change the version from 0.7
M G Berberich wrote:
> Hello,
>
> as far as I got it, a package with a version containing a '-X' is a
> native package.
>
> I packaged a programm (of myself). It contains a debian-directory and
> I can generate a native source-package out of the source, giving
> ppplog_0.7.tar.gz and ppplog_0.
On Thu, 3 May 2001, Bradley Bell wrote:
> It looks like it is just making explicit the restrictions which already exist
> in law (whatever those might be), and is not part of the license per se.
If the license references a law that restricts the rights of certain users,
and this law results in a
Hi,
Branden Robinson writes:
>
>
> Sorry, I tend to ignore wankers who want everything sugar-coated.
Aah, the joys of electronic communication.
Anyway, I think the original problem should be taken to debian-mentors
because it doesn't really relate to the PowerPC architecture. The
situation
I'm considering packaging BET, a 128-bit blowfish-encrypted talk daemon.
However, it relies on a non-DFSG complian library, even though the program
itself is GPL.
I'm presuming BET should therefore go into non-free, and I should also
package the library itself. Is this correct? If so, are there a
> I'm considering packaging BET, a 128-bit blowfish-encrypted talk daemon.
> However, it relies on a non-DFSG complian library, even though the program
> itself is GPL.
Then it belongs in contrib. Anything which is itself free but has non-free
dependencies should go in contrib.
Eric
--
To U
Sorry, didn't clarify. I should package the library for non-free and the
bet for contrib, correct?
~Warren Stramiello
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> Sorry, didn't clarify. I should package the library for non-free and the
> bet for contrib, correct?
Correct.
Eric
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
On Fri, 04 May 2001, Warren Stramiello wrote:
> Sorry, didn't clarify. I should package the library for non-free and the
> bet for contrib, correct?
Yes.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
Warren Stramiello wrote:
> I'm considering packaging BET, a 128-bit blowfish-encrypted talk daemon.
> However, it relies on a non-DFSG complian library, even though the program
> itself is GPL.
The license needs to have an exemption for the GPL-incompatible
library it uses.
Peter
--
To UN
Hi Peter!
You wrote:
> > I'm considering packaging BET, a 128-bit blowfish-encrypted talk daemon.
> > However, it relies on a non-DFSG complian library, even though the program
> > itself is GPL.
>
> The license needs to have an exemption for the GPL-incompatible
> library it uses.
Indeed. If
Robert Bihlmeyer wrote:
> Could dh_clean be extended to trap not-allowed-to-remove errors and
> issue a helpful message similar to dh_testroot? Then dh_testroot could
> be removed from the clean target, and it would just work for the most
> common cases, and give good diagnostic for common mistake
On Fri, May 04, 2001 at 11:20:00AM +0100, Paul Martin wrote:
> On Fri, May 04, 2001 at 10:46:56AM +0200, Robert Bihlmeyer wrote:
> > Us lazy people would like to save 9 letters on the clean call, and of
> > course we're far too far in sloth as to
> > alias dcln='fakeroot debian/rules clean'
>
>
On 4 May 2001, Jens Schmalzing wrote:
> The config script informs the user that a number of configuration
> files need to be present, that they won't be touched by Debian if they
> have been edited by the user, and that to make sure they will be
> created by Debian they should be deleted now.
Wh
Hi,
I am currently packaging gfax. In the Debian Policy it is specified
that one, willing to divert an executable, should contact the original
executable's maintainer.
In my case the lpr provided by gfax is a wrapper to provide the lpr
-Pfax command line. Should I contact both the LPRng and BSD
44 matches
Mail list logo
