On Wed, Feb 13, 2013 at 7:00 AM, Colin Guthrie gm...@colin.guthr.ie wrote:
'Twas brillig, and Lennart Poettering at 13/02/13 00:21 did gyre and
gimble:
On Mon, 11.02.13 16:34, Auke Kok (auke-jan.h@intel.com) wrote:
Contrary to it's own packaging guidelines, these symlinks are created
'Twas brillig, and Lennart Poettering at 13/02/13 00:21 did gyre and gimble:
On Mon, 11.02.13 16:34, Auke Kok (auke-jan.h@intel.com) wrote:
Contrary to it's own packaging guidelines, these symlinks are created
in /etc/. While technically not a problem, this makes it harder
for folks
On Wed, Feb 13, 2013 at 03:00:46PM +, Colin Guthrie wrote:
'Twas brillig, and Lennart Poettering at 13/02/13 00:21 did gyre and gimble:
On Mon, 11.02.13 16:34, Auke Kok (auke-jan.h@intel.com) wrote:
Contrary to it's own packaging guidelines, these symlinks are created
in /etc/.
On Wed, Feb 13, 2013 at 7:16 AM, Richard Maw
richard@codethink.co.uk wrote:
On Wed, Feb 13, 2013 at 03:00:46PM +, Colin Guthrie wrote:
'Twas brillig, and Lennart Poettering at 13/02/13 00:21 did gyre and gimble:
On Mon, 11.02.13 16:34, Auke Kok (auke-jan.h@intel.com) wrote:
Hi,
If I am not mistaken, moving getty@tty1.service and remote-fs.target to
$systemunitdir will cause them to be shown as disabled on systemctl
status .unit even though they are enabled. These unit files have
[Install] sections and when there is [Install] section on them, systemd
will look for a
'Twas brillig, and Umut Tezduyar at 12/02/13 12:00 did gyre and gimble:
If I am not mistaken, moving getty@tty1.service and remote-fs.target
to $systemunitdir will cause them to be shown as disabled on
systemctl status .unit even though they are enabled. These unit files
have [Install]
On Tue, Feb 12, 2013 at 1:12 PM, Colin Guthrie gm...@colin.guthr.ie wrote:
'Twas brillig, and Umut Tezduyar at 12/02/13 12:00 did gyre and gimble:
If I am not mistaken, moving getty@tty1.service and remote-fs.target
to $systemunitdir will cause them to be shown as disabled on
systemctl status
On Mon, 11.02.13 16:34, Auke Kok (auke-jan.h@intel.com) wrote:
Contrary to it's own packaging guidelines, these symlinks are created
in /etc/. While technically not a problem, this makes it harder
for folks installing from git that want to override these settings
(either masking or
On Tue, Feb 12, 2013 at 4:21 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Mon, 11.02.13 16:34, Auke Kok (auke-jan.h@intel.com) wrote:
Contrary to it's own packaging guidelines, these symlinks are created
in /etc/. While technically not a problem, this makes it harder
for folks
On Tue, 12.02.13 16:25, Kok, Auke-jan H (auke-jan.h@intel.com) wrote:
On Tue, Feb 12, 2013 at 4:21 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Mon, 11.02.13 16:34, Auke Kok (auke-jan.h@intel.com) wrote:
Contrary to it's own packaging guidelines, these symlinks are
Am 13.02.2013 01:21, schrieb Lennart Poettering:
On Mon, 11.02.13 16:34, Auke Kok (auke-jan.h@intel.com) wrote:
Contrary to it's own packaging guidelines, these symlinks are created
in /etc/. While technically not a problem, this makes it harder
for folks installing from git that want
Contrary to it's own packaging guidelines, these symlinks are created
in /etc/. While technically not a problem, this makes it harder
for folks installing from git that want to override these settings
(either masking or otherwise).
Moving the links to $(systemunitdir) resolves.
---
Makefile.am |
12 matches
Mail list logo
