Hi,
On Thu, Aug 19, 2021 at 2:57 AM Luca Boccassi wrote:
>
> updating Lintian would be the best outcome.
The corresponding bug in Lintian [1] will be resolved by changing the
expected prefix for service files to /usr/lib once a backport of
debhelper is available in bullseye, as described here.
On Fri, 2021-08-20 at 19:15 +0100, Simon McVittie wrote:
> On Fri, 20 Aug 2021 at 19:01:00 +0100, Luca Boccassi wrote:
> > I can confirm that if you build in split-usr mode then the generators
> > are looked for only in /lib:
> >
> > https://github.com/systemd/systemd/blob/v247/meson.build#L156
>
On Fri, 20 Aug 2021 at 19:01:00 +0100, Luca Boccassi wrote:
> I can confirm that if you build in split-usr mode then the generators
> are looked for only in /lib:
>
> https://github.com/systemd/systemd/blob/v247/meson.build#L156
>
> (the systemgeneratordir meson variable is set from
On Fri, 2021-08-20 at 18:30 +0100, Simon McVittie wrote:
> Control: retitle 992554 debhelper: moves systemd system generators to a
> location not searched by systemd
> Control: reassign 992554 debhelper 13.4
> Control: affects 992554 + tor ostree
>
> On Fri, 20 Aug 2021 at 16:20:04 +, Peter
Control: retitle 992554 debhelper: moves systemd system generators to a
location not searched by systemd
Control: reassign 992554 debhelper 13.4
Control: affects 992554 + tor ostree
On Fri, 20 Aug 2021 at 16:20:04 +, Peter Palfrader wrote:
> It seems that generators in /usr/lib/systemd are
On Thu, 19 Aug 2021, Luca Boccassi wrote:
> > Installing those files in /usr/lib/systemd/system is fine.
>
>
>
> This is indeed the right thing to do moving forward, so updating
> Lintian would be the best outcome. Thanks!
It seems that generators in /usr/lib/systemd are being ignored. This
Am 19.08.21 um 16:28 schrieb Theodore Ts'o:
OK, thanks for confirming this. What really worried me was this text
in lintian:
N: Systemd in Debian searches for unit files in /lib/systemd/system/ and
N: /etc/systemd/system. Notably, it does *not* look in
N: /usr/lib/systemd/system/ for
On Thu, Aug 19, 2021 at 11:46:21AM +0200, Michael Biebl wrote:
> Am 19.08.21 um 08:27 schrieb Michael Biebl:
> > I'll check later today, if i-s-h (init-system-helpers) does properly
> > handle this new path. If so, I'd say the bug should be reassigned to
> > lintian and we should start
Am 19.08.21 um 08:27 schrieb Michael Biebl:
I'll check later today, if i-s-h (init-system-helpers) does properly
handle this new path. If so, I'd say the bug should be reassigned to
lintian and we should start transitioning the files to
/usr/lib/systemd/system.
I now remember updating i-s-h
On Thu, 2021-08-19 at 08:27 +0200, Michael Biebl wrote:
> Am 19.08.2021 um 06:18 schrieb Theodore Ts'o:
> > There appears to be a rather major regression in debhelper 1.13.4 and
> > 1.13.4nmu1, which is forcing unit files to go in
> > /usr/lib/systemd/system, instead of /lib/systemd/systemd (where
Am 19.08.2021 um 06:18 schrieb Theodore Ts'o:
There appears to be a rather major regression in debhelper 1.13.4 and
1.13.4nmu1, which is forcing unit files to go in
/usr/lib/systemd/system, instead of /lib/systemd/systemd (where sytemd
will actually pay attention to them).
Installing those
On Thu, Aug 19, 2021 at 12:18:51AM -0400, Theodore Ts'o wrote:
> There appears to be a rather major regression in debhelper 1.13.4 and
> 1.13.4nmu1, which is forcing unit files to go in
> /usr/lib/systemd/system, instead of /lib/systemd/systemd (where sytemd
> will actually pay attention to them).
There appears to be a rather major regression in debhelper 1.13.4 and
1.13.4nmu1, which is forcing unit files to go in
/usr/lib/systemd/system, instead of /lib/systemd/systemd (where sytemd
will actually pay attention to them).
On systems with ursmerge, things should still work, thanks to the
13 matches
Mail list logo
