Turbo/others,
I'm packaging Nagios. It builds tree packages from one source:
'nagios-text', 'nagios-pgsql' and 'nagios-mysql'. The differences
is quite obvious: Compile the source three times, each time with
different ./configure options.
configure: configure-stamp
configure-stamp:
On Tue, Sep 17, 2002 at 11:53:34PM +0200, Oliver Kurth wrote:
Sorry, the question is:
Is it okay to do an NMU with a new upstream version?
Depending on the answer to that question, two more arise:
- did I wait long enough for the maintainer to take action himself?
- and is anyone willing
Manoj And you can set up your module postinst to install the module
Manoj in any directory you want -- /lib/modules/2.4/foo, for example,
Manoj and copy files at will.
Ian But what is the point of having them in a package, then?
Manoj Heh. I have 2.4.17 installed, and I install module_foo.
Ian Zimmerman [EMAIL PROTECTED] writes:
Manoj And you can set up your module postinst to install the module
Manoj in any directory you want -- /lib/modules/2.4/foo, for example,
Manoj and copy files at will.
There is no need to copy them. See below.
Ian But what is the point of having them
On Thursday 19 Sep 2002 2:06 pm, Francesco P. Lovergine wrote:
Sorry, but a NMU (but for QA uploads) is generally an 'in extremis'
choice to correct bugs, or to be done when the maintainer appears
inactive (or possibly MIA). Changing upstream version is not
a good thing, 'cause it can
I have a package that really needs to have a configurable location of it's
configuration files. This would be possible by putting them in $sysconfdir,
but for some reason I am yet to come close to understanding, $sysconfdir is
set to $prefix/etc which is not a good place to put config files
On Thu, Sep 19, 2002 at 03:31:57PM +0200, Tore Anderson wrote:
Ian Zimmerman [EMAIL PROTECTED] writes:
Manoj And you can set up your module postinst to install the module
Manoj in any directory you want -- /lib/modules/2.4/foo, for example,
Manoj and copy files at will.
There is no
Hi Cyrille
Am Thu, Sep 19, 2002 at 08:45:43PM +0200 hat Cyrille Chepelov getippert:
It looks like you can now start uploading kcachegrind, as soon as you feel your
package is ready.
OK, thanks.
There is one remaining question: kcachegrind depends on KDE3 to
be built. KDE3 is not in unstable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 19 September 2002 21:35, Philipp Frauenfelder wrote:
There is one remaining question: kcachegrind depends on KDE3 to
be built. KDE3 is not in unstable yet, but I found the necessary
Debian packages in the archive of KDE itself.
Sven LUTHER [EMAIL PROTECTED] writes:
On Thu, Sep 19, 2002 at 03:31:57PM +0200, Tore Anderson wrote:
I think policy should reccomend third-party modules to be installed
in the the directory common for all kernels with the same minor
release.
How do you handle the case when the module
Will Newton [EMAIL PROTECTED] writes:
I have a package that really needs to have a configurable location of it's
configuration files. This would be possible by putting them in $sysconfdir,
but for some reason I am yet to come close to understanding, $sysconfdir is
set to $prefix/etc which
On Thursday 19 Sep 2002 11:00 pm, Roger Leigh wrote:
The average user shouldn't be running configure with a prefix of /
or /usr, and so the default is what they want. /etc and /usr are
owned by dpkg, so nothing should be installed manually there.
Running ./configure without arguments will
* Oliver Kurth
| But he seems to be MIA. I reported the bug 16 days ago, told him about my
| package 9 days ago. I never got a response. The bug itself is even older.
MIA is a lot longer than 9 or 16 days..
--
Tollef Fog Heen,''`.
UNIX
* Will Newton
| clisp now depends on a library that was once distributed inside the tarball,
| libsigsegv, which I have now packaged separately. This package needs to be
| uploaded first I would imagine.
I'll look into this, comments follow in a separate mail.
--
Tollef Fog Heen
On Fri, 20 Sep 2002 00:08:16 +0100
Will Newton [EMAIL PROTECTED] wrote:
The average user shouldn't be running configure with a prefix of /
or /usr, and so the default is what they want. /etc and /usr are
owned by dpkg, so nothing should be installed manually there.
Running ./configure
Tore == Tore Anderson [EMAIL PROTECTED] writes:
Manoj I now install 2.4.18. Now, either the module search path is
Manoj changed, or boom! no more module foo with new kernel.
Tore Again, you are mistaken. Only parts of the
I'd like to adopt the mysql-navigator package so I'm looking for a
sponsor. I've packaged the latest upstream source and cleaned up the
package a bit. In particular, I've fixed the 2 RC bugs.
If anyone's interested, the packages can be found here:
deb http://bignachos.com/~nelson/debian/ ./
Turbo/others,
I'm packaging Nagios. It builds tree packages from one source:
'nagios-text', 'nagios-pgsql' and 'nagios-mysql'. The differences
is quite obvious: Compile the source three times, each time with
different ./configure options.
configure: configure-stamp
configure-stamp:
On Tue, Sep 17, 2002 at 11:53:34PM +0200, Oliver Kurth wrote:
Sorry, the question is:
Is it okay to do an NMU with a new upstream version?
Depending on the answer to that question, two more arise:
- did I wait long enough for the maintainer to take action himself?
- and is anyone willing
Manoj And you can set up your module postinst to install the module
Manoj in any directory you want -- /lib/modules/2.4/foo, for example,
Manoj and copy files at will.
Ian But what is the point of having them in a package, then?
Manoj Heh. I have 2.4.17 installed, and I install module_foo.
On Thu, Sep 19, 2002 at 03:06:51PM +0200, Francesco P. Lovergine wrote:
On Tue, Sep 17, 2002 at 11:53:34PM +0200, Oliver Kurth wrote:
Sorry, the question is:
Is it okay to do an NMU with a new upstream version?
Depending on the answer to that question, two more arise:
- did I wait
Ian Zimmerman [EMAIL PROTECTED] writes:
Manoj And you can set up your module postinst to install the module
Manoj in any directory you want -- /lib/modules/2.4/foo, for example,
Manoj and copy files at will.
There is no need to copy them. See below.
Ian But what is the point of having them
On Thursday 19 Sep 2002 2:06 pm, Francesco P. Lovergine wrote:
Sorry, but a NMU (but for QA uploads) is generally an 'in extremis'
choice to correct bugs, or to be done when the maintainer appears
inactive (or possibly MIA). Changing upstream version is not
a good thing, 'cause it can
On Thu, Sep 19, 2002 at 03:31:57PM +0200, Tore Anderson wrote:
Ian Zimmerman [EMAIL PROTECTED] writes:
Manoj And you can set up your module postinst to install the module
Manoj in any directory you want -- /lib/modules/2.4/foo, for example,
Manoj and copy files at will.
There is no
Hi Cyrille
Am Thu, Sep 19, 2002 at 08:45:43PM +0200 hat Cyrille Chepelov getippert:
It looks like you can now start uploading kcachegrind, as soon as you feel
your
package is ready.
OK, thanks.
There is one remaining question: kcachegrind depends on KDE3 to
be built. KDE3 is not in unstable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 19 September 2002 21:35, Philipp Frauenfelder wrote:
There is one remaining question: kcachegrind depends on KDE3 to
be built. KDE3 is not in unstable yet, but I found the necessary
Debian packages in the archive of KDE itself.
I am the maintainer of clisp who is currently in the NM queue. I have a new
version of the package, including a new upstream version. It has some
important portability fixes and also reduces the package size substantially.
Unfortunately my sponsor seems to be unresponsive at the moment, so I
Sven LUTHER [EMAIL PROTECTED] writes:
On Thu, Sep 19, 2002 at 03:31:57PM +0200, Tore Anderson wrote:
I think policy should reccomend third-party modules to be installed
in the the directory common for all kernels with the same minor
release.
How do you handle the case when the module
Will Newton [EMAIL PROTECTED] writes:
I have a package that really needs to have a configurable location of it's
configuration files. This would be possible by putting them in $sysconfdir,
but for some reason I am yet to come close to understanding, $sysconfdir is
set to $prefix/etc which
On Thursday 19 Sep 2002 11:00 pm, Roger Leigh wrote:
The average user shouldn't be running configure with a prefix of /
or /usr, and so the default is what they want. /etc and /usr are
owned by dpkg, so nothing should be installed manually there.
Running ./configure without arguments will
* Oliver Kurth
| But he seems to be MIA. I reported the bug 16 days ago, told him about my
| package 9 days ago. I never got a response. The bug itself is even older.
MIA is a lot longer than 9 or 16 days..
--
Tollef Fog Heen,''`.
UNIX
* Will Newton
| clisp now depends on a library that was once distributed inside the tarball,
| libsigsegv, which I have now packaged separately. This package needs to be
| uploaded first I would imagine.
I'll look into this, comments follow in a separate mail.
--
Tollef Fog Heen
On Fri, 20 Sep 2002 00:08:16 +0100
Will Newton [EMAIL PROTECTED] wrote:
The average user shouldn't be running configure with a prefix of /
or /usr, and so the default is what they want. /etc and /usr are
owned by dpkg, so nothing should be installed manually there.
Running ./configure
33 matches
Mail list logo
