Bug#837807: remove workaround for Bug#834524 (init-system-helpers: does not own /etc/rc?.d) from piuparts

2016-09-14 Thread Holger Levsen 
package: piuparts

On Mon, Sep 12, 2016 at 07:51:11AM +, Debian Bug Tracking System wrote:
> Source: init-system-helpers
> Version: 1.43
>  init-system-helpers (1.43) unstable; urgency=medium
>  .
>[ Felipe Sateler ]
>* Add /etc/rc?.d to the dirs shipped by init-system-helpers.
>  (Closes: #834524)

so the piuparts workaround should be removed again…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#834524: init-system-helpers: does not own /etc/rc?.d

2016-08-19 Thread anarcat 
On Wed, Aug 17, 2016 at 12:08:05AM +0200, Michael Biebl wrote:
> Am 16.08.2016 um 19:12 schrieb Ferenc Wágner:
> > Package: init-system-helpers
> > Version: 1.25
> > Severity: normal
> > 
> > Hi,
> > 
> > Recently both my daemon packages started to exhibit this piuparts error:
> > 
> > ERROR: FAIL: Package purging left files on system:
> >   /etc/rc2.d/not owned
> >   /etc/rc3.d/not owned
> >   /etc/rc4.d/not owned
> >   /etc/rc5.d/not owned
> > 
> > I think this is the result of sysv-rc losing its Essential flag, which means
> > it isn't present in minimal chroots (like those used by piuparts) anymore.
> > On the other hand, init-system-helpers imported update-rc.d in version 1.25,
> > and I think /etc/rc?.d is created by update-rc.d (but never removed).  All
> > this results in piuparts failures in recently tested daemon packages.
> > 
> > If the above analysis is correct, please fix this.
> 
> Fix what exactly?

I am not sure what the fix is either, but it breaks Piuparts (#834766)
for a *lot* of packages:

https://piuparts.debian.org/sid/unowned_files_after_purge_error.html

arguably, not all those matches are due to this specific bug, but at
this point, any package that ships a daemon with dh_installinit (and
that's a lot of packages!) are now yielding piuparts errors all over the
place (e.g. postfix, openssh-server, apache2 all now fail piuparts).

This bug is marked as "pending", with a patch. Would that fix piuparts?
If so, I would highly recommend uploading the new version ASAP to keep
people like me from looking all over the place to figure out what broke
in their packages.

If not, it would be great to have some way forward. Punting the issue in
Piuparts' backyard may work, but I think it would be nice to get rid of
those old directories on systems that do not have init.d files
anymore...

Thanks!

A.


signature.asc
Description: Digital signature

Bug#834524: init-system-helpers: does not own /etc/rc?.d

2016-08-19 Thread Josh Triplett 
On Fri, Aug 19, 2016 at 05:27:57PM -0300, Felipe Sateler wrote:
> On 19 August 2016 at 17:23, Josh Triplett  wrote:
> > On Fri, Aug 19, 2016 at 04:51:12PM -0300, Felipe Sateler wrote:
> >> On 19 August 2016 at 15:24, Josh Triplett  wrote:
> >> > On Wed, 17 Aug 2016 12:34:59 -0300 Felipe Sateler  
> >> > wrote:
> >> >> On 17 August 2016 at 03:45, Ferenc Wágner  wrote:
> >> >> > Michael Biebl  writes:
> >> >> >
> >> >> >> Am 16.08.2016 um 19:12 schrieb Ferenc Wágner:
> >> >> >>
> >> >> >>> Recently both my daemon packages started to exhibit this piuparts 
> >> >> >>> error:
> >> >> >>>
> >> >> >>> ERROR: FAIL: Package purging left files on system:
> >> >> >>>   /etc/rc2.d/ not owned
> >> >> >>>   /etc/rc3.d/ not owned
> >> >> >>>   /etc/rc4.d/ not owned
> >> >> >>>   /etc/rc5.d/ not owned
> >> >> >>>
> >> >> >>> I think this is the result of sysv-rc losing its Essential flag, 
> >> >> >>> which means
> >> >> >>> it isn't present in minimal chroots (like those used by piuparts) 
> >> >> >>> anymore.
> >> >> >>> On the other hand, init-system-helpers imported update-rc.d in 
> >> >> >>> version 1.25,
> >> >> >>> and I think /etc/rc?.d is created by update-rc.d (but never 
> >> >> >>> removed).  All
> >> >> >>> this results in piuparts failures in recently tested daemon 
> >> >> >>> packages.
> >> >> >>>
> >> >> >>> If the above analysis is correct, please fix this.
> >> >> >>
> >> >> >> Fix what exactly?
> >> >> >
> >> >> > The piuparts errors.  By taking ownership of the /etc/rc?.d symlink
> >> >> > directories.  (Removing them if they become empty is another option, 
> >> >> > but
> >> >> > does not sound a very good idea.)  Previously they were owned by
> >> >> > sysv-rc, which also provided update-rc.d, which used these 
> >> >> > directories.
> >> >> > When update-rc.d moved into init-system-helpers, /etc/rc?.d should've
> >> >> > followed along, but was forgotten, I guess.
> >> >>
> >> >> Indeed. init-system-helpers even already did this for
> >> >> /etc/systemd/system. I have added the rc?.d directories to the list.
> >> >>
> >> >> https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=62e093e7949a25479cbc78d01903f76f49629059
> >> >
> >> > This will cause the directories to continue to exist even when empty.
> >>
> >> Yes.
> >>
> >> >
> >> > Ideally, these directories could become empty and disappear eventually,
> >> > on a system not running sysvinit.  What would it take for that to
> >> > happen?
> >>
> >> A lot more than reverting that commit :)
> >>
> >> On my system I see:
> >>
> >> % dpkg -S /etc/init.d/*
> >> avahi-daemon: /etc/init.d/avahi-daemon
> >> binfmt-support: /etc/init.d/binfmt-support
> >> cron: /etc/init.d/cron
> >> dbus: /etc/init.d/dbus
> >> util-linux: /etc/init.d/hwclock.sh
> >> procps: /etc/init.d/procps
> >> rsync: /etc/init.d/rsync
> >> openssh-server: /etc/init.d/ssh
> >> sudo: /etc/init.d/sudo
> >> udev: /etc/init.d/udev
> >> unattended-upgrades: /etc/init.d/unattended-upgrades
> >> x11-common: /etc/init.d/x11-common
> >>
> >> util-linux is essential, udev is pretty much required on
> >> non-containers. Procps and cron are Priority important.
> >>
> >> As long as we support non-systemd init, all of those need to ship init
> >> scripts. And as long as they do, there will be /etc/rc?.d directories.
> >
> > Not necessarily.  /etc/init.d will need to exist; /etc/rc?.d doesn't,
> > unless an init system making use of rc?.d links is installed.
> 
> Systemd is an init systemd that makes use of rc?.d links, as it uses
> that information to determine if a service without native unit is
> enabled.

That seems potentially fixable, by making the "disable" mechanism create
a foo.service -> /dev/null link.  (Or, more easily, by providing a
native unit.)

(I'm not arguing that this should happen *soon*, but I look forward to
moving in that direction.)

> >  (As a
> > random possibility, installing sysvinit or similar could trigger the
> > generation of rc?.d scripts, avoiding the need to generate them at
> > install time.  That would be a lot easier if update-rc.d ran via a
> > trigger, which seems a lot more plausible now that it no longer accepts
> > any kind of priority options and all such information must live in the
> > script.)
> 
> Unfortunately, invoke-rc.d relies on the enablement links as well.
> Thus update-rc.d must happen before invoke-rc.d. Converting
> invoke-rc.d to triggers is not as trivial, as not all scripts have to
> be started on package installation/upgrade, and restart-on-upgrade
> behavior differs.

That seems like something we should eventually migrate to something like
systemd-preset files, which would also make it much more convenient for
admins to set policies like whether to start services on installation or
not.  In addition, that would eliminate a huge number of maintainer
scripts in favor of declarative

Bug#834524: init-system-helpers: does not own /etc/rc?.d

2016-08-19 Thread Felipe Sateler 
On 19 August 2016 at 17:23, Josh Triplett  wrote:
> On Fri, Aug 19, 2016 at 04:51:12PM -0300, Felipe Sateler wrote:
>> On 19 August 2016 at 15:24, Josh Triplett  wrote:
>> > On Wed, 17 Aug 2016 12:34:59 -0300 Felipe Sateler  
>> > wrote:
>> >> On 17 August 2016 at 03:45, Ferenc Wágner  wrote:
>> >> > Michael Biebl  writes:
>> >> >
>> >> >> Am 16.08.2016 um 19:12 schrieb Ferenc Wágner:
>> >> >>
>> >> >>> Recently both my daemon packages started to exhibit this piuparts 
>> >> >>> error:
>> >> >>>
>> >> >>> ERROR: FAIL: Package purging left files on system:
>> >> >>>   /etc/rc2.d/ not owned
>> >> >>>   /etc/rc3.d/ not owned
>> >> >>>   /etc/rc4.d/ not owned
>> >> >>>   /etc/rc5.d/ not owned
>> >> >>>
>> >> >>> I think this is the result of sysv-rc losing its Essential flag, 
>> >> >>> which means
>> >> >>> it isn't present in minimal chroots (like those used by piuparts) 
>> >> >>> anymore.
>> >> >>> On the other hand, init-system-helpers imported update-rc.d in 
>> >> >>> version 1.25,
>> >> >>> and I think /etc/rc?.d is created by update-rc.d (but never removed). 
>> >> >>>  All
>> >> >>> this results in piuparts failures in recently tested daemon packages.
>> >> >>>
>> >> >>> If the above analysis is correct, please fix this.
>> >> >>
>> >> >> Fix what exactly?
>> >> >
>> >> > The piuparts errors.  By taking ownership of the /etc/rc?.d symlink
>> >> > directories.  (Removing them if they become empty is another option, but
>> >> > does not sound a very good idea.)  Previously they were owned by
>> >> > sysv-rc, which also provided update-rc.d, which used these directories.
>> >> > When update-rc.d moved into init-system-helpers, /etc/rc?.d should've
>> >> > followed along, but was forgotten, I guess.
>> >>
>> >> Indeed. init-system-helpers even already did this for
>> >> /etc/systemd/system. I have added the rc?.d directories to the list.
>> >>
>> >> https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=62e093e7949a25479cbc78d01903f76f49629059
>> >
>> > This will cause the directories to continue to exist even when empty.
>>
>> Yes.
>>
>> >
>> > Ideally, these directories could become empty and disappear eventually,
>> > on a system not running sysvinit.  What would it take for that to
>> > happen?
>>
>> A lot more than reverting that commit :)
>>
>> On my system I see:
>>
>> % dpkg -S /etc/init.d/*
>> avahi-daemon: /etc/init.d/avahi-daemon
>> binfmt-support: /etc/init.d/binfmt-support
>> cron: /etc/init.d/cron
>> dbus: /etc/init.d/dbus
>> util-linux: /etc/init.d/hwclock.sh
>> procps: /etc/init.d/procps
>> rsync: /etc/init.d/rsync
>> openssh-server: /etc/init.d/ssh
>> sudo: /etc/init.d/sudo
>> udev: /etc/init.d/udev
>> unattended-upgrades: /etc/init.d/unattended-upgrades
>> x11-common: /etc/init.d/x11-common
>>
>> util-linux is essential, udev is pretty much required on
>> non-containers. Procps and cron are Priority important.
>>
>> As long as we support non-systemd init, all of those need to ship init
>> scripts. And as long as they do, there will be /etc/rc?.d directories.
>
> Not necessarily.  /etc/init.d will need to exist; /etc/rc?.d doesn't,
> unless an init system making use of rc?.d links is installed.

Systemd is an init systemd that makes use of rc?.d links, as it uses
that information to determine if a service without native unit is
enabled.

>  (As a
> random possibility, installing sysvinit or similar could trigger the
> generation of rc?.d scripts, avoiding the need to generate them at
> install time.  That would be a lot easier if update-rc.d ran via a
> trigger, which seems a lot more plausible now that it no longer accepts
> any kind of priority options and all such information must live in the
> script.)

Unfortunately, invoke-rc.d relies on the enablement links as well.
Thus update-rc.d must happen before invoke-rc.d. Converting
invoke-rc.d to triggers is not as trivial, as not all scripts have to
be started on package installation/upgrade, and restart-on-upgrade
behavior differs.


-- 

Saludos,
Felipe Sateler

Bug#834524: init-system-helpers: does not own /etc/rc?.d

2016-08-19 Thread Josh Triplett 
On Fri, Aug 19, 2016 at 04:51:12PM -0300, Felipe Sateler wrote:
> On 19 August 2016 at 15:24, Josh Triplett  wrote:
> > On Wed, 17 Aug 2016 12:34:59 -0300 Felipe Sateler  
> > wrote:
> >> On 17 August 2016 at 03:45, Ferenc Wágner  wrote:
> >> > Michael Biebl  writes:
> >> >
> >> >> Am 16.08.2016 um 19:12 schrieb Ferenc Wágner:
> >> >>
> >> >>> Recently both my daemon packages started to exhibit this piuparts 
> >> >>> error:
> >> >>>
> >> >>> ERROR: FAIL: Package purging left files on system:
> >> >>>   /etc/rc2.d/ not owned
> >> >>>   /etc/rc3.d/ not owned
> >> >>>   /etc/rc4.d/ not owned
> >> >>>   /etc/rc5.d/ not owned
> >> >>>
> >> >>> I think this is the result of sysv-rc losing its Essential flag, which 
> >> >>> means
> >> >>> it isn't present in minimal chroots (like those used by piuparts) 
> >> >>> anymore.
> >> >>> On the other hand, init-system-helpers imported update-rc.d in version 
> >> >>> 1.25,
> >> >>> and I think /etc/rc?.d is created by update-rc.d (but never removed).  
> >> >>> All
> >> >>> this results in piuparts failures in recently tested daemon packages.
> >> >>>
> >> >>> If the above analysis is correct, please fix this.
> >> >>
> >> >> Fix what exactly?
> >> >
> >> > The piuparts errors.  By taking ownership of the /etc/rc?.d symlink
> >> > directories.  (Removing them if they become empty is another option, but
> >> > does not sound a very good idea.)  Previously they were owned by
> >> > sysv-rc, which also provided update-rc.d, which used these directories.
> >> > When update-rc.d moved into init-system-helpers, /etc/rc?.d should've
> >> > followed along, but was forgotten, I guess.
> >>
> >> Indeed. init-system-helpers even already did this for
> >> /etc/systemd/system. I have added the rc?.d directories to the list.
> >>
> >> https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=62e093e7949a25479cbc78d01903f76f49629059
> >
> > This will cause the directories to continue to exist even when empty.
> 
> Yes.
> 
> >
> > Ideally, these directories could become empty and disappear eventually,
> > on a system not running sysvinit.  What would it take for that to
> > happen?
> 
> A lot more than reverting that commit :)
> 
> On my system I see:
> 
> % dpkg -S /etc/init.d/*
> avahi-daemon: /etc/init.d/avahi-daemon
> binfmt-support: /etc/init.d/binfmt-support
> cron: /etc/init.d/cron
> dbus: /etc/init.d/dbus
> util-linux: /etc/init.d/hwclock.sh
> procps: /etc/init.d/procps
> rsync: /etc/init.d/rsync
> openssh-server: /etc/init.d/ssh
> sudo: /etc/init.d/sudo
> udev: /etc/init.d/udev
> unattended-upgrades: /etc/init.d/unattended-upgrades
> x11-common: /etc/init.d/x11-common
> 
> util-linux is essential, udev is pretty much required on
> non-containers. Procps and cron are Priority important.
> 
> As long as we support non-systemd init, all of those need to ship init
> scripts. And as long as they do, there will be /etc/rc?.d directories.

Not necessarily.  /etc/init.d will need to exist; /etc/rc?.d doesn't,
unless an init system making use of rc?.d links is installed.  (As a
random possibility, installing sysvinit or similar could trigger the
generation of rc?.d scripts, avoiding the need to generate them at
install time.  That would be a lot easier if update-rc.d ran via a
trigger, which seems a lot more plausible now that it no longer accepts
any kind of priority options and all such information must live in the
script.)

Bug#834524: init-system-helpers: does not own /etc/rc?.d

2016-08-19 Thread Felipe Sateler 
On 19 August 2016 at 15:24, Josh Triplett  wrote:
> On Wed, 17 Aug 2016 12:34:59 -0300 Felipe Sateler  wrote:
>> On 17 August 2016 at 03:45, Ferenc Wágner  wrote:
>> > Michael Biebl  writes:
>> >
>> >> Am 16.08.2016 um 19:12 schrieb Ferenc Wágner:
>> >>
>> >>> Recently both my daemon packages started to exhibit this piuparts error:
>> >>>
>> >>> ERROR: FAIL: Package purging left files on system:
>> >>>   /etc/rc2.d/ not owned
>> >>>   /etc/rc3.d/ not owned
>> >>>   /etc/rc4.d/ not owned
>> >>>   /etc/rc5.d/ not owned
>> >>>
>> >>> I think this is the result of sysv-rc losing its Essential flag, which 
>> >>> means
>> >>> it isn't present in minimal chroots (like those used by piuparts) 
>> >>> anymore.
>> >>> On the other hand, init-system-helpers imported update-rc.d in version 
>> >>> 1.25,
>> >>> and I think /etc/rc?.d is created by update-rc.d (but never removed).  
>> >>> All
>> >>> this results in piuparts failures in recently tested daemon packages.
>> >>>
>> >>> If the above analysis is correct, please fix this.
>> >>
>> >> Fix what exactly?
>> >
>> > The piuparts errors.  By taking ownership of the /etc/rc?.d symlink
>> > directories.  (Removing them if they become empty is another option, but
>> > does not sound a very good idea.)  Previously they were owned by
>> > sysv-rc, which also provided update-rc.d, which used these directories.
>> > When update-rc.d moved into init-system-helpers, /etc/rc?.d should've
>> > followed along, but was forgotten, I guess.
>>
>> Indeed. init-system-helpers even already did this for
>> /etc/systemd/system. I have added the rc?.d directories to the list.
>>
>> https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=62e093e7949a25479cbc78d01903f76f49629059
>
> This will cause the directories to continue to exist even when empty.

Yes.

>
> Ideally, these directories could become empty and disappear eventually,
> on a system not running sysvinit.  What would it take for that to
> happen?

A lot more than reverting that commit :)

On my system I see:

% dpkg -S /etc/init.d/*
avahi-daemon: /etc/init.d/avahi-daemon
binfmt-support: /etc/init.d/binfmt-support
cron: /etc/init.d/cron
dbus: /etc/init.d/dbus
util-linux: /etc/init.d/hwclock.sh
procps: /etc/init.d/procps
rsync: /etc/init.d/rsync
openssh-server: /etc/init.d/ssh
sudo: /etc/init.d/sudo
udev: /etc/init.d/udev
unattended-upgrades: /etc/init.d/unattended-upgrades
x11-common: /etc/init.d/x11-common

util-linux is essential, udev is pretty much required on
non-containers. Procps and cron are Priority important.

As long as we support non-systemd init, all of those need to ship init
scripts. And as long as they do, there will be /etc/rc?.d directories.

-- 

Saludos,
Felipe Sateler

Bug#834524: init-system-helpers: does not own /etc/rc?.d

2016-08-19 Thread Josh Triplett 
On Wed, 17 Aug 2016 12:34:59 -0300 Felipe Sateler  wrote:
> On 17 August 2016 at 03:45, Ferenc Wágner  wrote:
> > Michael Biebl  writes:
> >
> >> Am 16.08.2016 um 19:12 schrieb Ferenc Wágner:
> >>
> >>> Recently both my daemon packages started to exhibit this piuparts error:
> >>>
> >>> ERROR: FAIL: Package purging left files on system:
> >>>   /etc/rc2.d/ not owned
> >>>   /etc/rc3.d/ not owned
> >>>   /etc/rc4.d/ not owned
> >>>   /etc/rc5.d/ not owned
> >>>
> >>> I think this is the result of sysv-rc losing its Essential flag, which 
> >>> means
> >>> it isn't present in minimal chroots (like those used by piuparts) anymore.
> >>> On the other hand, init-system-helpers imported update-rc.d in version 
> >>> 1.25,
> >>> and I think /etc/rc?.d is created by update-rc.d (but never removed).  All
> >>> this results in piuparts failures in recently tested daemon packages.
> >>>
> >>> If the above analysis is correct, please fix this.
> >>
> >> Fix what exactly?
> >
> > The piuparts errors.  By taking ownership of the /etc/rc?.d symlink
> > directories.  (Removing them if they become empty is another option, but
> > does not sound a very good idea.)  Previously they were owned by
> > sysv-rc, which also provided update-rc.d, which used these directories.
> > When update-rc.d moved into init-system-helpers, /etc/rc?.d should've
> > followed along, but was forgotten, I guess.
> 
> Indeed. init-system-helpers even already did this for
> /etc/systemd/system. I have added the rc?.d directories to the list.
> 
> https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=62e093e7949a25479cbc78d01903f76f49629059

This will cause the directories to continue to exist even when empty.

Ideally, these directories could become empty and disappear eventually,
on a system not running sysvinit.  What would it take for that to
happen?

Bug#834524: init-system-helpers: does not own /etc/rc?.d

2016-08-17 Thread Felipe Sateler 
On 17 August 2016 at 03:45, Ferenc Wágner  wrote:
> Michael Biebl  writes:
>
>> Am 16.08.2016 um 19:12 schrieb Ferenc Wágner:
>>
>>> Recently both my daemon packages started to exhibit this piuparts error:
>>>
>>> ERROR: FAIL: Package purging left files on system:
>>>   /etc/rc2.d/ not owned
>>>   /etc/rc3.d/ not owned
>>>   /etc/rc4.d/ not owned
>>>   /etc/rc5.d/ not owned
>>>
>>> I think this is the result of sysv-rc losing its Essential flag, which means
>>> it isn't present in minimal chroots (like those used by piuparts) anymore.
>>> On the other hand, init-system-helpers imported update-rc.d in version 1.25,
>>> and I think /etc/rc?.d is created by update-rc.d (but never removed).  All
>>> this results in piuparts failures in recently tested daemon packages.
>>>
>>> If the above analysis is correct, please fix this.
>>
>> Fix what exactly?
>
> The piuparts errors.  By taking ownership of the /etc/rc?.d symlink
> directories.  (Removing them if they become empty is another option, but
> does not sound a very good idea.)  Previously they were owned by
> sysv-rc, which also provided update-rc.d, which used these directories.
> When update-rc.d moved into init-system-helpers, /etc/rc?.d should've
> followed along, but was forgotten, I guess.

Indeed. init-system-helpers even already did this for
/etc/systemd/system. I have added the rc?.d directories to the list.

https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=62e093e7949a25479cbc78d01903f76f49629059

-- 

Saludos,
Felipe Sateler

Bug#834524: init-system-helpers: does not own /etc/rc?.d

2016-08-17 Thread Ferenc Wágner 
Michael Biebl  writes:

> Am 16.08.2016 um 19:12 schrieb Ferenc Wágner:
> 
>> Recently both my daemon packages started to exhibit this piuparts error:
>> 
>> ERROR: FAIL: Package purging left files on system:
>>   /etc/rc2.d/ not owned
>>   /etc/rc3.d/ not owned
>>   /etc/rc4.d/ not owned
>>   /etc/rc5.d/ not owned
>> 
>> I think this is the result of sysv-rc losing its Essential flag, which means
>> it isn't present in minimal chroots (like those used by piuparts) anymore.
>> On the other hand, init-system-helpers imported update-rc.d in version 1.25,
>> and I think /etc/rc?.d is created by update-rc.d (but never removed).  All
>> this results in piuparts failures in recently tested daemon packages.
>> 
>> If the above analysis is correct, please fix this.
>
> Fix what exactly?

The piuparts errors.  By taking ownership of the /etc/rc?.d symlink
directories.  (Removing them if they become empty is another option, but
does not sound a very good idea.)  Previously they were owned by
sysv-rc, which also provided update-rc.d, which used these directories.
When update-rc.d moved into init-system-helpers, /etc/rc?.d should've
followed along, but was forgotten, I guess.
-- 
Thanks,
Feri

Bug#834524: init-system-helpers: does not own /etc/rc?.d

2016-08-16 Thread Michael Biebl 
Am 16.08.2016 um 19:12 schrieb Ferenc Wágner:
> Package: init-system-helpers
> Version: 1.25
> Severity: normal
> 
> Hi,
> 
> Recently both my daemon packages started to exhibit this piuparts error:
> 
> ERROR: FAIL: Package purging left files on system:
>   /etc/rc2.d/  not owned
>   /etc/rc3.d/  not owned
>   /etc/rc4.d/  not owned
>   /etc/rc5.d/  not owned
> 
> I think this is the result of sysv-rc losing its Essential flag, which means
> it isn't present in minimal chroots (like those used by piuparts) anymore.
> On the other hand, init-system-helpers imported update-rc.d in version 1.25,
> and I think /etc/rc?.d is created by update-rc.d (but never removed).  All
> this results in piuparts failures in recently tested daemon packages.
> 
> If the above analysis is correct, please fix this.

Fix what exactly?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#834524: init-system-helpers: does not own /etc/rc?.d

2016-08-16 Thread Ferenc Wágner 
Package: init-system-helpers
Version: 1.25
Severity: normal

Hi,

Recently both my daemon packages started to exhibit this piuparts error:

ERROR: FAIL: Package purging left files on system:
  /etc/rc2.d/not owned
  /etc/rc3.d/not owned
  /etc/rc4.d/not owned
  /etc/rc5.d/not owned

I think this is the result of sysv-rc losing its Essential flag, which means
it isn't present in minimal chroots (like those used by piuparts) anymore.
On the other hand, init-system-helpers imported update-rc.d in version 1.25,
and I think /etc/rc?.d is created by update-rc.d (but never removed).  All
this results in piuparts failures in recently tested daemon packages.

If the above analysis is correct, please fix this.
If it is not, please reassign to the correct package.
-- 
Thanks,
Feri.