Marc Haber wrote:
> On Sun, 17 Aug 2014 23:14:33 -0500, Josh Triplett
> wrote:
> >Why a requirement to not improve upstream? Ideally, the Debian patches
> >for a piece of software should trend to zero over time, as fixes make
> >their way upstream.
>
> Imagine an upstream author having the coop
Marc Haber (2014-08-18):
> And others removed. Or do you actually claims that the systemd
> migration didn't actually break things? Not all of them, but a
> noticeable number.
(I don't think Russ claimed anything along those lines, no.)
Anyway: things get broken, bugs get reported, bugs get fixe
On Mon, 18 Aug 2014 09:31:37 -0700, Russ Allbery
wrote:
>could we tone down the assumption that people with
>differing preferences want to break everything you do? It's just a few
>additional options.
And others removed. Or do you actually claims that the systemd
migration didn't actually break
On Mon, Aug 18, 2014 at 09:31:37AM -0700, Russ Allbery wrote:
> More generally (and this part is not pointed at Thomas), I realize it's
> become de rigueur in any thread about systemd to reply to "hm, you could
> consider getting a dog" with "WHY DO YOU WANT TO KILL MY KITTENS?!?!?",
> but seriousl
On Sun, 17 Aug 2014, Marc Haber wrote:
> Please. The attitute of requiring Debian maintainers to modify
> upstream software instead of having simple two-line extension to an
> init script is really unfriendly. Why do only systemd friends keep
> recommending this?
Using my sysvinit hat, I've always
Thomas Goirand writes:
> On 08/18/2014 01:36 AM, Russ Allbery wrote:
>> The upstream source *can* be changed and improved for everyone.
> Truth, but not always practical. If I was going to fix all the defects
> of software I package, I don't think I'd have enough time to sleep even
> one hour pe
On 08/18/2014 01:36 AM, Russ Allbery wrote:
> The upstream source *can* be changed and improved for everyone.
Truth, but not always practical. If I was going to fix all the defects
of software I package, I don't think I'd have enough time to sleep even
one hour per night.
Thomas Goirand (zigo)
On Sun, Aug 17, 2014 at 01:13:36PM +0200, Marc Haber wrote:
> On Sun, 17 Aug 2014 01:40:27 -0700, Josh Triplett
> wrote:
> >Ludovico Cavedon wrote:
> >> I am writing a systemd service file for a daemon (ntopng) and I would
> >> like to know what you think is the best way to load some
> >> configur
On Sun, 17 Aug 2014 23:14:33 -0500, Josh Triplett
wrote:
>Why a requirement to not improve upstream? Ideally, the Debian patches
>for a piece of software should trend to zero over time, as fixes make
>their way upstream.
Imagine an upstream author having the cooperation level of the systemd
team
On Sun, Aug 17, 2014 at 09:24:33PM -0700, Ludovico Cavedon wrote:
> On Sun, Aug 17, 2014 at 9:14 PM, Josh Triplett wrote:
> > On Sun, Aug 17, 2014 at 08:48:40PM -0700, Ludovico Cavedon wrote:
> >> On Sun, Aug 17, 2014 at 1:40 AM, Josh Triplett
> >> wrote:
> >> > 3) Teach ntopng to understand /et
On Sun, Aug 17, 2014 at 9:14 PM, Josh Triplett wrote:
> On Sun, Aug 17, 2014 at 08:48:40PM -0700, Ludovico Cavedon wrote:
>> On Sun, Aug 17, 2014 at 1:40 AM, Josh Triplett wrote:
>> > 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the
>> > settings there.
>>
>> yes, that woul
On Sun, Aug 17, 2014 at 08:48:40PM -0700, Ludovico Cavedon wrote:
> On Sun, Aug 17, 2014 at 1:40 AM, Josh Triplett wrote:
> > 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the
> > settings there.
>
> yes, that would be an option. I forgot to add the requirement "without
> pa
On Sun, Aug 17, 2014 at 4:20 AM, Marc Haber
wrote:
> On Sun, 17 Aug 2014 12:17:21 +0200, Michael Biebl
> wrote:
>>I also happen to notice, that you use a ENABLED=1 flag.
>>It would be a good idea to deprecate that as well and remove that.
>>
>>We have better mechanisms nowadays to enable/disable
Josh,
On Sun, Aug 17, 2014 at 1:40 AM, Josh Triplett wrote:
> 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the
> settings there.
yes, that would be an option. I forgot to add the requirement "without
patching upstream code" :)
> 4) Teach ntopng to automatically detect the
On Sun, Aug 17, 2014 at 01:44:15PM +0200, Marco d'Itri wrote:
> On Aug 17, Marc Haber wrote:
> > Please. The attitute of requiring Debian maintainers to modify
> > upstream software instead of having simple two-line extension to an
> > init script is really unfriendly. Why do only systemd friends
On Sun, 17 Aug 2014 10:36:22 -0700, Russ Allbery
wrote:
>It's good to be aware of the option to improve the upstream source so that
>packaging it is easier and so that it works better for everyone with less
>configuration.
I find packaging easier when I work around a limitation in the
upstream so
Marc Haber writes:
> Josh Triplett wrote:
>> 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the
>> settings there.
>> 4) Teach ntopng to automatically detect the available network devices
>> on the system (including new ones that show up dynamically) and
>> automatically ha
Marco wrote:
>On Aug 17, Marc Haber wrote:
>
>> Please. The attitute of requiring Debian maintainers to modify
>> upstream software instead of having simple two-line extension to an
>> init script is really unfriendly. Why do only systemd friends keep
>> recommending this?
>Maybe because the other
On Sun, 17 Aug 2014 13:14:27 +0100, Simon McVittie
>if ! [ -e /etc/foo.conf ]
>then
>echo -n "(not starting, you need to create /etc/foo.conf)"
>return 0
>fi
if ! grep '^important-option' foo.conf;
looks like a rather common idiom.
Greetings
Marc
--
---
On Sun, 17 Aug 2014 13:48:44 +0200, m...@linux.it (Marco d'Itri) wrote:
>On Aug 17, Marc Haber wrote:
>> Does Debian no longer care about easy updates, or have we accepted
>> that updating to jessie will be a nightmare anyway and recommend
>> reinstallation instead?
>Yes, I hate users and I want t
On 17/08/14 12:48, Marco d'Itri wrote:
> On Aug 17, Marc Haber wrote:
>> It is not
>> always possible to come with a working default configuration or to
>> build one in postinst.
>
> If unconfigured software really cannot fail cleanly then the package can
> install it without enabling the service
Hi,
>> 3) Teach ntopng to understand /etc/ntopng.conf natively and migrate the
>> settings there.
>> 4) Teach ntopng to automatically detect the available network devices on
>> the system (including new ones that show up dynamically) and
>> automatically handle all of them unless configured to do
Marc Haber writes:
> Quite a number of packages also refrain from starting the daemon on an
> unconfigured newly installed package until the user has configured it.
> I guess that this needs to be replaced "by native mechanisms (i.e.
> implemented as a patch to the upstream software)" as well? It
On Aug 17, Marc Haber wrote:
> Please. The attitute of requiring Debian maintainers to modify
> upstream software instead of having simple two-line extension to an
> init script is really unfriendly. Why do only systemd friends keep
> recommending this?
Maybe because the others do not care enough
On Aug 17, Marc Haber wrote:
> Does Debian no longer care about easy updates, or have we accepted
> that updating to jessie will be a nightmare anyway and recommend
> reinstallation instead?
Yes, I hate users and I want them to suffer.
> Quite a number of packages also refrain from starting the
On Aug 17, Ludovico Cavedon wrote:
> 2) instead of doing Exec=ntopng, Exec a script that does the mangling
> and then execs ntopng.
If you cannot improve the software enough then this is the best choice.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Sun, 17 Aug 2014 12:17:21 +0200, Michael Biebl
wrote:
>I also happen to notice, that you use a ENABLED=1 flag.
>It would be a good idea to deprecate that as well and remove that.
>
>We have better mechanisms nowadays to enable/disable SysV init scripts
>(and systemd service files).
In my packa
On 17/08/14 10:38, Thomas Goirand wrote:
> I had the same problem as you describe above, even a bit more
> complicated because, in what we did, /etc/default/ sometimes
> doesn't exist (it's not mandatory in what we did).
EnvironmentFile takes precedence over Environment, and EnvironmentFile
starti
On Sun, 17 Aug 2014 12:05:13 +0200, Michael Biebl
wrote:
>But yeah, such wrapper scripts should be avoided if possible and native
>mechanisms used.
Having read quite of system docs in the last weeks to find a way to
key /etc/crypttab keyscript functionality back, I have found that
"using the nati
On Sun, 17 Aug 2014 01:40:27 -0700, Josh Triplett
wrote:
>Ludovico Cavedon wrote:
>> I am writing a systemd service file for a daemon (ntopng) and I would
>> like to know what you think is the best way to load some
>> configuration.
>>
>> The ntopng daemon takes multiple interfaces in the format
Am 17.08.2014 05:51, schrieb Ludovico Cavedon:
> Hi,
>
> I am writing a systemd service file for a daemon (ntopng) and I would
> like to know what you think is the best way to load some
> configuration.
>
> The ntopng daemon takes multiple interfaces in the format of multiple
> -i command-line op
Am 17.08.2014 11:38, schrieb Thomas Goirand:
> How about teaching systemd that script is sometimes necessary? It's
> annoying to write a wrapper, because then, it does a fork to start the
> daemon, so the PID changes. Has this been reported upstream? If yes,
> what's upstream opinion about it?
I
On 08/17/2014 11:51 AM, Ludovico Cavedon wrote:
> Hi,
>
> I am writing a systemd service file for a daemon (ntopng) and I would
> like to know what you think is the best way to load some
> configuration.
>
> The ntopng daemon takes multiple interfaces in the format of multiple
> -i command-line o
Ludovico Cavedon wrote:
> I am writing a systemd service file for a daemon (ntopng) and I would
> like to know what you think is the best way to load some
> configuration.
>
> The ntopng daemon takes multiple interfaces in the format of multiple
> -i command-line options. For example.
> ntopng -i
Hi,
I am writing a systemd service file for a daemon (ntopng) and I would
like to know what you think is the best way to load some
configuration.
The ntopng daemon takes multiple interfaces in the format of multiple
-i command-line options. For example.
ntopng -i eth0 -i wlan0
Currently the inte
35 matches
Mail list logo
