Miloslav Trmač wrote:
> The exceptions were granted to avoid the impact of fixing this on
> developers, and more importantly on users (the /usr/lib/systemd paths
> for units are in various documentation, and even worse the paths to
> binaries in /usr/lib/systemd are embedded in users' copies of uni
Matthew Garrett wrote:
> Unit files need to be in /, so moving them would either require creating
> a /share for distributions that haven't merged /usr or putting up with
> inconsistent naming between distributions. Consistency is a virtue and
> the chances of getting anyone else to accept /share a
On Fri, Dec 21, 2012 at 02:17:39PM -0500, Bill Nottingham wrote:
> Lennart Poettering (mzerq...@0pointer.de) said:
> > it is simply wrong to place internal binaries in %{_libdir}. internal
> > binaries should not be subject to multlib'ed dirs, the same way as
> > binaries in bin/ are not...
>
> I
Once upon a time, Bill Nottingham said:
> In any case, I agree - my proposal was that packages that use
> non-multilibbed helper binaries should be free to put them in *one of*
> $prefix/lib or $prefix/libexec, as long as they remain consistent.
As a sys admin (and an OCD one at that), I'd prefer
On Fri, Dec 21, 2012 at 10:33:27AM -0800, Adam Williamson wrote:
> On Fri, 2012-12-21 at 12:30 -0500, Matthew Miller wrote:
> > On Thu, Dec 20, 2012 at 09:16:00PM -0800, Adam Williamson wrote:
> > > I've never seen any distro take any notice of this standard whatsoever.
> >
> > Well, if you don't
Lennart Poettering (mzerq...@0pointer.de) said:
> it is simply wrong to place internal binaries in %{_libdir}. internal
> binaries should not be subject to multlib'ed dirs, the same way as
> binaries in bin/ are not...
I would note I have seen cases where helper binaries actually needed to be
arc
On Fri, 2012-12-21 at 15:17 +0100, Ralf Corsepius wrote:
> > The "GNU standard" is kinda flawed and nobody uses that as 1:1.
> Utter nonsense.
>
> > I mean,
> > /usr/etc? /usr/var?? /us/com???
> "Defaults" == they need to be adapted to a specific distro's requirements.
>
> > It's probably more i
On Fri, Dec 21, 2012 at 04:47:58PM +, Matthew Garrett wrote:
> On Fri, Dec 21, 2012 at 12:42:14AM -0800, Toshio Kuratomi wrote:
>
> > However, you also miss my point. Adam's message was saying that the
> > guidelines forced people to use libexecdir and then went on to point out the
> > drawba
On Fri, 2012-12-21 at 12:30 -0500, Matthew Miller wrote:
> On Thu, Dec 20, 2012 at 09:16:00PM -0800, Adam Williamson wrote:
> > I've never seen any distro take any notice of this standard whatsoever.
>
> Well, if you don't count Red Hat Linux, Fedora, and Red Hat Enterprise
> Linux
I should p
On 20 December 2012 22:16, Adam Williamson wrote:
> On Fri, 2012-12-21 at 06:09 +0100, Ralf Corsepius wrote:
>> On 12/21/2012 05:54 AM, Matthew Garrett wrote:
>> > On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote:
>> >
>> >> I disagree. systemd simply hasn't taken libexecdir into acc
On Fri, Dec 21, 2012 at 04:59:59PM +, Daniel P. Berrange wrote:
> The libvirt_lxc binary does appear in the XML
> /usr/libexec/libvirt_lxc. The libvirt_lxc binary is the
> host-side helper, akin to /bin/qemu-system-x86_64
> in QEMU/KVM world. We put it under /usr/libexec though because it i
On Fri, Dec 21, 2012 at 04:55:09PM +, Matthew Garrett wrote:
> On Fri, Dec 21, 2012 at 04:37:59PM +, Richard W.M. Jones wrote:
> > On Fri, Dec 21, 2012 at 04:22:47PM +, Matthew Garrett wrote:
> > > On Fri, Dec 21, 2012 at 10:49:19AM -0500, Don Dutile wrote:
> > > > fyi: libexec has been
On Thu, Dec 20, 2012 at 09:16:00PM -0800, Adam Williamson wrote:
> I've never seen any distro take any notice of this standard whatsoever.
Well, if you don't count Red Hat Linux, Fedora, and Red Hat Enterprise
Linux
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁
--
devel mailing list
On Fri, Dec 21, 2012 at 05:13:17PM +, Matthew Garrett wrote:
> On Fri, Dec 21, 2012 at 05:09:00PM +, Richard W.M. Jones wrote:
> > On Fri, Dec 21, 2012 at 04:55:09PM +, Matthew Garrett wrote:
> > > Is the path user visible in any way?
> >
> > If used, /usr/libexec/qemu-bridge-helper is
On Fri, Dec 21, 2012 at 05:09:00PM +, Richard W.M. Jones wrote:
> On Fri, Dec 21, 2012 at 04:55:09PM +, Matthew Garrett wrote:
> > Is the path user visible in any way?
>
> If used, /usr/libexec/qemu-bridge-helper is encoded directly in the
> libvirt XML. So is libvirt_lxc. (So is /usr/li
On Fri, Dec 21, 2012 at 04:55:09PM +, Matthew Garrett wrote:
> On Fri, Dec 21, 2012 at 04:37:59PM +, Richard W.M. Jones wrote:
> > On Fri, Dec 21, 2012 at 04:22:47PM +, Matthew Garrett wrote:
> > > On Fri, Dec 21, 2012 at 10:49:19AM -0500, Don Dutile wrote:
> > > > fyi: libexec has been
On Fri, Dec 21, 2012 at 04:37:59PM +, Richard W.M. Jones wrote:
> On Fri, Dec 21, 2012 at 04:22:47PM +, Matthew Garrett wrote:
> > On Fri, Dec 21, 2012 at 10:49:19AM -0500, Don Dutile wrote:
> > > fyi: libexec has been critical to virtualization for quite some time...
>
> I think Don is re
On Fri, Dec 21, 2012 at 12:42:14AM -0800, Toshio Kuratomi wrote:
> However, you also miss my point. Adam's message was saying that the
> guidelines forced people to use libexecdir and then went on to point out the
> drawbacks of forcing specifically libexecdir on upstreams that didn't have
> tha
On Fri, Dec 21, 2012 at 04:22:47PM +, Matthew Garrett wrote:
> On Fri, Dec 21, 2012 at 10:49:19AM -0500, Don Dutile wrote:
> > On 12/20/2012 11:54 PM, Matthew Garrett wrote:
> > >libexec doesn't exist in any published version of the FHS, and even the
> > >draft of 3.0 makes it clear that it's o
On Fri, Dec 21, 2012 at 10:49:19AM -0500, Don Dutile wrote:
> On 12/20/2012 11:54 PM, Matthew Garrett wrote:
> >libexec doesn't exist in any published version of the FHS, and even the
> >draft of 3.0 makes it clear that it's optional. Our use of libexec is
> >non-standard, not systemd's use of lib.
On 12/20/2012 11:54 PM, Matthew Garrett wrote:
On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote:
I disagree. systemd simply hasn't taken libexecdir into account in
its design and now is trying to propagate their oversight/mistake as
"standard" instead of making their works complia
On 12/21/2012 02:24 PM, Lennart Poettering wrote:
On Fri, 21.12.12 05:38, Ralf Corsepius (rc040...@freenet.de) wrote:
On 12/21/2012 12:27 AM, Matthew Garrett wrote:
On Thu, Dec 20, 2012 at 10:30:37PM +, Richard W.M. Jones wrote:
Thanks, but I think the bit I'm mising is why can't systemd
Interesting previous discussions about /usr/libexec:
http://lists.debian.org/debian-devel/2005/05/thrd2.html#00401
http://www.redhat.com/archives/rhl-devel-list/2005-May/thread.html#00240
FreeBSD has /usr/libexec[1], and it's part of historical Unix,
although I cannot find when it was first int
On Thu, 20.12.12 23:24, Toshio Kuratomi (a.bad...@gmail.com) wrote:
> > 2) we have to pressure upstream projects to needlessly complicate their
> > code and buildsystem with stuff like $libexecdir variables in their
> > autofoo, which resolve to /usr/libexec on Fedora/RHEL but just /usr/lib
> > or
Lennart Poettering writes:
>> > IMHO, libexecdir is not part of this at all... we already have:
>> >
>> > "If upstream's build scripts support the use of %{_libexecdir} then
>> > that is the most appropriate place to configure it (eg. passing
>> > --libexecdir=%{libexecdir}/%{name} to autotools
On Fri, 21.12.12 07:01, Ralf Corsepius (rc040...@freenet.de) wrote:
> On 12/21/2012 06:16 AM, Adam Williamson wrote:
> >On Fri, 2012-12-21 at 06:09 +0100, Ralf Corsepius wrote:
> >>On 12/21/2012 05:54 AM, Matthew Garrett wrote:
> >>>On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote:
>
On Fri, 21.12.12 05:38, Ralf Corsepius (rc040...@freenet.de) wrote:
> On 12/21/2012 12:27 AM, Matthew Garrett wrote:
> >On Thu, Dec 20, 2012 at 10:30:37PM +, Richard W.M. Jones wrote:
> >
> >>Thanks, but I think the bit I'm mising is why can't systemd use
> >>libexec? (Apart from their declar
On Thu, 20.12.12 18:48, Toshio Kuratomi (a.bad...@gmail.com) wrote:
> > Ahem. Isn't your own first sentence suggesting that *your* way is the
> > one and only right way? I don't see how you can attack Lennart for
> > having a firm belief about what's the 'right way' when you also seem to
> > have
On Fri, 21.12.12 05:06, Matthew Garrett (mj...@srcf.ucam.org) wrote:
> On Thu, Dec 20, 2012 at 08:57:58PM -0700, Kevin Fenzi wrote:
> > IMHO, libexecdir is not part of this at all... we already have:
> >
> > "If upstream's build scripts support the use of %{_libexecdir} then
> > that is the most
On 12/21/2012 09:42 AM, Toshio Kuratomi wrote:
On Fri, Dec 21, 2012 at 07:45:45AM +, Matthew Garrett wrote:
On Thu, Dec 20, 2012 at 11:24:09PM -0800, Toshio Kuratomi wrote:
However, you also miss my point. Adam's message was saying that the
guidelines forced people to use libexecdir and
On Thu, Dec 20, 2012 at 11:39:53PM -0800, Adam Williamson wrote:
> I do apologize for somewhat derailing things towards the libexecdir
> discussion, though, as I missed the point about the real question here
> being between /lib/foo and $libdir/foo . The libexecdir thing is kind of
> a tangent and
On Fri, Dec 21, 2012 at 07:45:45AM +, Matthew Garrett wrote:
> On Thu, Dec 20, 2012 at 11:24:09PM -0800, Toshio Kuratomi wrote:
>
> > 2) the systemd exceptions allows placing files in %{_prefix}/lib rather
> > than %{_libdir} (the exceptions allow both putting the helper apps in there
> > whic
On 12/21/2012 09:24 AM, Florian Weimer wrote:
On 12/21/2012 12:27 AM, Matthew Garrett wrote:
On Thu, Dec 20, 2012 at 10:30:37PM +, Richard W.M. Jones wrote:
Thanks, but I think the bit I'm mising is why can't systemd use
libexec? (Apart from their declaration that libexec is wrong or not
On 12/21/2012 12:27 AM, Matthew Garrett wrote:
On Thu, Dec 20, 2012 at 10:30:37PM +, Richard W.M. Jones wrote:
Thanks, but I think the bit I'm mising is why can't systemd use
libexec? (Apart from their declaration that libexec is wrong or not
the de-facto standard they themselves made up,
On Thu, Dec 20, 2012 at 11:24:09PM -0800, Toshio Kuratomi wrote:
> 2) the systemd exceptions allows placing files in %{_prefix}/lib rather
> than %{_libdir} (the exceptions allow both putting the helper apps in there
> which would generally be okay with just a multilib exception and the unit
> fil
On Thu, 2012-12-20 at 23:24 -0800, Toshio Kuratomi wrote:
> Since neither of these things are required by the packaging
> guidelines, I believe the premise of your argument is deeply flawed.
> 1) As i've said before, there is no packaging guideline requirement
> that maintainers restrict helper
-Toshio
On Dec 20, 2012 7:05 PM, "Adam Williamson" wrote:
>
> On Thu, 2012-12-20 at 18:54 -0800, Adam Williamson wrote:
>
> > A systemd-specific exception works for systemd, fine, but it doesn't
> > really seem to address the root problem.
>
> To further elaborate: the 'root problem', it seems to
On Fri, Dec 21, 2012 at 07:16:12AM +0100, Ralf Corsepius wrote:
> On 12/21/2012 06:36 AM, Matthew Garrett wrote:
> >So?
>
> Next the FHS, it is one of the fundamental "standards", which define
> the basis of all packaging works on Linux/GNU and thus also the FPG.
No, it defines the GNU project's
On 12/21/2012 06:36 AM, Matthew Garrett wrote:
On Fri, Dec 21, 2012 at 06:09:10AM +0100, Ralf Corsepius wrote:
On 12/21/2012 05:54 AM, Matthew Garrett wrote:
On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote:
I disagree. systemd simply hasn't taken libexecdir into account in
its
On 12/21/2012 06:16 AM, Adam Williamson wrote:
On Fri, 2012-12-21 at 06:09 +0100, Ralf Corsepius wrote:
On 12/21/2012 05:54 AM, Matthew Garrett wrote:
On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote:
I disagree. systemd simply hasn't taken libexecdir into account in
its design
On Fri, Dec 21, 2012 at 06:09:10AM +0100, Ralf Corsepius wrote:
> On 12/21/2012 05:54 AM, Matthew Garrett wrote:
> >On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote:
> >
> >>I disagree. systemd simply hasn't taken libexecdir into account in
> >>its design and now is trying to propagat
On Fri, 2012-12-21 at 06:09 +0100, Ralf Corsepius wrote:
> On 12/21/2012 05:54 AM, Matthew Garrett wrote:
> > On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote:
> >
> >> I disagree. systemd simply hasn't taken libexecdir into account in
> >> its design and now is trying to propagate th
On 12/21/2012 05:54 AM, Matthew Garrett wrote:
On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote:
I disagree. systemd simply hasn't taken libexecdir into account in
its design and now is trying to propagate their oversight/mistake as
"standard" instead of making their works complia
On Thu, Dec 20, 2012 at 08:57:58PM -0700, Kevin Fenzi wrote:
> IMHO, libexecdir is not part of this at all... we already have:
>
> "If upstream's build scripts support the use of %{_libexecdir} then
> that is the most appropriate place to configure it (eg. passing
> --libexecdir=%{libexecdir}/%{n
On 12/21/2012 01:15 AM, Matthew Miller wrote:
On Thu, Dec 20, 2012 at 04:05:36PM -0800, Toshio Kuratomi wrote:
As I said in the meeting, libexec is somewhat of a red herring here. The
packaging guidelines already allow substituting subdirs of %_libdir for
%_libexecdir. What's in question is be
On Fri, Dec 21, 2012 at 05:38:17AM +0100, Ralf Corsepius wrote:
> I disagree. systemd simply hasn't taken libexecdir into account in
> its design and now is trying to propagate their oversight/mistake as
> "standard" instead of making their works compliant with _our_
> distro's demands.
libexec d
On 12/21/2012 12:27 AM, Matthew Garrett wrote:
On Thu, Dec 20, 2012 at 10:30:37PM +, Richard W.M. Jones wrote:
Thanks, but I think the bit I'm mising is why can't systemd use
libexec? (Apart from their declaration that libexec is wrong or not
the de-facto standard they themselves made up,
On Thu, 2012-12-20 at 23:01 -0500, Paul Wouters wrote:
> On Thu, 20 Dec 2012, Adam Williamson wrote:
>
> > All this for the rather questionable benefit of having a specifically
> > defined place for helper-scripts-not-meant-to-be-executed-directly,
> > which gains us...what, exactly, over just put
On Thu, 20 Dec 2012, Adam Williamson wrote:
All this for the rather questionable benefit of having a specifically
defined place for helper-scripts-not-meant-to-be-executed-directly,
which gains us...what, exactly, over just putting them
in /usr/lib/(appname) or /usr/share/(appname) or whatever?
On Thu, 20 Dec 2012 19:10:45 -0800
Adam Williamson wrote:
> Hm, I missed the point that the exception is for lib/foo vs.
> %libdir/foo (arched vs. non-arched). That makes it a more complex
> three-way argument. But I think the point about libexecdir being
> pointless still stands.
IMHO, libexecd
On Fri, 2012-12-21 at 04:22 +0100, Miloslav Trmač wrote:
> On Fri, Dec 21, 2012 at 4:05 AM, Adam Williamson wrote:
> > On Thu, 2012-12-20 at 18:54 -0800, Adam Williamson wrote:
> >
> >> A systemd-specific exception works for systemd, fine, but it doesn't
> >> really seem to address the root proble
On Fri, Dec 21, 2012 at 4:05 AM, Adam Williamson wrote:
> On Thu, 2012-12-20 at 18:54 -0800, Adam Williamson wrote:
>
>> A systemd-specific exception works for systemd, fine, but it doesn't
>> really seem to address the root problem.
>
> To further elaborate: the 'root problem', it seems to me, is
On Thu, Dec 20, 2012 at 07:05:20PM -0800, Adam Williamson wrote:
> > A systemd-specific exception works for systemd, fine, but it doesn't
> > really seem to address the root problem.
> To further elaborate: the 'root problem', it seems to me, is that this
> 'Fedoraism' as Lennart calls it results i
On Thu, Dec 20, 2012 at 06:54:24PM -0800, Adam Williamson wrote:
> It seemed perfectly clear from context that what Lennart was arguing is
> that the guidelines should be changed and we should stop using
> this /usr/libexec directory which no-one outside of RH-derived distros
> has adopted, and whi
On Thu, 2012-12-20 at 19:05 -0800, Adam Williamson wrote:
> On Thu, 2012-12-20 at 18:54 -0800, Adam Williamson wrote:
>
> > A systemd-specific exception works for systemd, fine, but it doesn't
> > really seem to address the root problem.
>
> To further elaborate: the 'root problem', it seems to m
On Thu, 2012-12-20 at 18:54 -0800, Adam Williamson wrote:
> A systemd-specific exception works for systemd, fine, but it doesn't
> really seem to address the root problem.
To further elaborate: the 'root problem', it seems to me, is that this
'Fedoraism' as Lennart calls it results in one of two
On Thu, 2012-12-20 at 18:48 -0800, Toshio Kuratomi wrote:
> On Thu, Dec 20, 2012 at 06:07:58PM -0800, Adam Williamson wrote:
> > On Thu, 2012-12-20 at 17:50 -0800, Toshio Kuratomi wrote:
> >
> > > > Just making systemd the exception sounds like chickening out from the
> > > > real solution which i
On Thu, Dec 20, 2012 at 06:07:58PM -0800, Adam Williamson wrote:
> On Thu, 2012-12-20 at 17:50 -0800, Toshio Kuratomi wrote:
>
> > > Just making systemd the exception sounds like chickening out from the
> > > real solution which is to end this Fedoraism.
> > >
> > Well really it's us not wanting
On Fri, Dec 21, 2012 at 1:06 AM, Lennart Poettering
wrote:
> declare
> that lib/ is the place for package-specific stuff and
> share/ the place that is shared between packages.
If this is supposed to be within current FHS (and not a proposal to
abandon it), the above is a gross misunderstanding o
On Thu, 2012-12-20 at 17:50 -0800, Toshio Kuratomi wrote:
> > Just making systemd the exception sounds like chickening out from the
> > real solution which is to end this Fedoraism.
> >
> Well really it's us not wanting to fight to make you do the right thing any
> longer. If you want us to take
On Fri, Dec 21, 2012 at 01:06:13AM +0100, Lennart Poettering wrote:
> On Thu, 20.12.12 12:02, Toshio Kuratomi (a.bad...@gmail.com) wrote:
>
> >
> > FPC will write into the Guidelines (probably where libexec is mentioned
> > since that's where the note about being able to use %{_libdir} as an
> >
On Thu, Dec 20, 2012 at 04:05:36PM -0800, Toshio Kuratomi wrote:
> On Dec 20, 2012 3:16 PM, "Richard W.M. Jones" wrote:
> > Thanks, but I think the bit I'm mising is why can't systemd use
> > libexec? (Apart from their declaration that libexec is wrong or not
> > the de-facto standard they themse
On Thu, Dec 20, 2012 at 04:05:36PM -0800, Toshio Kuratomi wrote:
> As I said in the meeting, libexec is somewhat of a red herring here. The
> packaging guidelines already allow substituting subdirs of %_libdir for
> %_libexecdir. What's in question is being able to use /usr/lib for arch
> specifi
On Thu, 20.12.12 12:02, Toshio Kuratomi (a.bad...@gmail.com) wrote:
> On Thu, Dec 20, 2012 at 02:28:48PM +, Richard W.M. Jones wrote:
> > On Thu, Dec 20, 2012 at 01:54:57AM +, Matthew Garrett wrote:
> > > On Wed, Dec 19, 2012 at 11:56:36PM +0100, Kevin Kofler wrote:
> > >
> > > > Yuck! I
On Dec 20, 2012 3:16 PM, "Richard W.M. Jones" wrote:
>
> On Thu, Dec 20, 2012 at 12:02:22PM -0800, Toshio Kuratomi wrote:
> > The effect of this is:
> >
> > FPC will write into the Guidelines (probably where libexec is mentioned
> > since that's where the note about being able to use %{_libdir} as
On Thu, Dec 20, 2012 at 10:30:37PM +, Richard W.M. Jones wrote:
> Thanks, but I think the bit I'm mising is why can't systemd use
> libexec? (Apart from their declaration that libexec is wrong or not
> the de-facto standard they themselves made up, which is not a reason).
Because libexec doe
On Thu, Dec 20, 2012 at 12:02:22PM -0800, Toshio Kuratomi wrote:
> The effect of this is:
>
> FPC will write into the Guidelines (probably where libexec is mentioned
> since that's where the note about being able to use %{_libdir} as an
> alternative to %{_libexecdir} is ) that the systemd helper
On Thu, Dec 20, 2012 at 02:28:48PM +, Richard W.M. Jones wrote:
> On Thu, Dec 20, 2012 at 01:54:57AM +, Matthew Garrett wrote:
> > On Wed, Dec 19, 2012 at 11:56:36PM +0100, Kevin Kofler wrote:
> >
> > > Yuck! I really don't see why we should be granting this type of
> > > exceptions.
> >
Le Jeu 20 décembre 2012 02:54, Matthew Garrett a écrit :
> On Wed, Dec 19, 2012 at 11:56:36PM +0100, Kevin Kofler wrote:
>
>> Yuck! I really don't see why we should be granting this type of
>> exceptions.
>> libexec and share exist for a reason. Helper binaries need to be in
>> libexec,
>> unit fi
On Wed, Dec 19, 2012 at 11:56 PM, Kevin Kofler wrote:
> Tomas Mraz wrote:
>> * AGREED: 1. systemd is granted an exception to put helper
>> applications in /usr/lib/systemd (t8m, 19:03:17)
>> * AGREED: 2. the systemd unit files of all the packages are granted an
>> exception to be unde
On Thu, Dec 20, 2012 at 01:54:57AM +, Matthew Garrett wrote:
> On Wed, Dec 19, 2012 at 11:56:36PM +0100, Kevin Kofler wrote:
>
> > Yuck! I really don't see why we should be granting this type of exceptions.
> > libexec and share exist for a reason. Helper binaries need to be in
> > libexec,
On Wed, Dec 19, 2012 at 11:56:36PM +0100, Kevin Kofler wrote:
> Yuck! I really don't see why we should be granting this type of exceptions.
> libexec and share exist for a reason. Helper binaries need to be in libexec,
> unit files in share, I think allowing systemd to dump everything (and in
>
Tomas Mraz wrote:
> * AGREED: 1. systemd is granted an exception to put helper
> applications in /usr/lib/systemd (t8m, 19:03:17)
> * AGREED: 2. the systemd unit files of all the packages are granted an
> exception to be under /usr/lib/systemd (t8m, 19:03:33)
Yuck! I really don't see
73 matches
Mail list logo
