Hello,
I have tried to search the archives of this mailing list for "CODENAME"
but that searched the entire freedesktop.org site...
Anyway, at the danger that this has been discussed before, I'd like to
make this
Proposal:
Add CODENAME as an officially described field to /etc/os-release.
Hi Fi,
https://bugzilla.redhat.com/show_bug.cgi?id=1274958#c5
Is it expected that this will be resolved here/upstream,
or is it specificum for Fedora/downstream?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
Use the existing fields as in
NAME=
VERSION=
ID=
VERSION_ID=
PRETTY_NAME=
VARIANT=
VARIANT_ID=
Adding additional codename field serves no purpose or value which the
previous fields do not already cover.
___
systemd-devel mailing list
Unknown [2016-01-13 14:23 +0100]:
> You shouldn't ask yourself where can i find the codename, but rather
> what do I want to do with it?
> - display it to the user or otherwise describe it in human readable
> text? use PRETTY_NAME if the distribution isn't obvious, or VERSION if
> it is.
> -
Johann,
The description for /etc/os-release makes only this (quite informal)
statement about the release code name:
VERSION: A string identifying the operating system version,
excluding any OS name information, possibly including a release code
name, and suitable for presentation to the
On wo, 2016-01-13 at 13:04 +0100, Andreas Maier wrote:
> Johann,
> The description for /etc/os-release makes only this (quite informal)
> statement about the release code name:
>
> VERSION: A string identifying the operating system version,
> excluding any OS name information, possibly
Hello,
Is is possible to set a variable in the [Unit]
section of a service?
For example in rpc-gssd.service there is
ConditionPathExists=/etc/krb5.keytab
but for some installation the krb5.keytab
is in a different place. The rpc.gssd daemon
can be told this by setting a command line
Am 13.01.2016 um 16:51 schrieb Steve Dickson:
Is is possible to set a variable in the [Unit]
section of a service?
For example in rpc-gssd.service there is
ConditionPathExists=/etc/krb5.keytab
but for some installation the krb5.keytab
is in a different place. The rpc.gssd daemon
can be
On Wed, 13.01.16 11:53, Andreas Maier (andreas.r.ma...@gmx.de) wrote:
> Hello,
> I have tried to search the archives of this mailing list for "CODENAME" but
> that searched the entire freedesktop.org site...
>
> Anyway, at the danger that this has been discussed before, I'd like to make
> this
>
hi all,
i'm having following situation on a centos 7.2 system (systemd-219-19.el7)
there is a sysvinit service called netconsole that is not listed as a
unit or unitfile, but the unitfile was generated and systemctl seems to
be able to handle the unit.
the only odd issue is that this service is
Am 13.01.2016 um 17:26 schrieb Stijn De Weirdt:
i'm having following situation on a centos 7.2 system (systemd-219-19.el7)
there is a sysvinit service called netconsole that is not listed as a
unit or unitfile, but the unitfile was generated and systemctl seems to
be able to handle the unit
13.01.2016 19:26, Stijn De Weirdt пишет:
> hi all,
>
> i'm having following situation on a centos 7.2 system (systemd-219-19.el7)
>
> there is a sysvinit service called netconsole that is not listed as a
> unit or unitfile, but the unitfile was generated and systemctl seems to
> be able to
>> i'm having following situation on a centos 7.2 system
>> (systemd-219-19.el7)
>>
>> there is a sysvinit service called netconsole that is not listed as a
>> unit or unitfile, but the unitfile was generated and systemctl seems to
>> be able to handle the unit
>
> becaus enobody created a
13 matches
Mail list logo
