Bug#901136: can't remove if install fails

[KAction]

[2018-06-14 00:32] Wouter Verhelst 
> Hi,

Hi!

> On Wed, Jun 13, 2018 at 03:21:11AM +0300, kact...@gnu.org wrote:
> > I never worked with NSS, but how did it happen, that useradd {in postinst}
> > created user in a way, that userdel {in prerm} could not find?
> 
> That's not what happened.
> 
> The sreview user already existed before the sreview-common package was
> installed, but it did not exist in /etc/passwd; instead, it existed in a
> different location, configured through an NSS module.

Am I correct, some time ago it was created by previous version of maintainer 
script,
when I did not use dh-sysuser?

> The easiest way for you to test this is probably to install libnss-db,
> change the value of ETC in /etc/default/libnss-db to some other
> directory and cull the DBS value so it contains just passwd, then create
> a file called "passwd" in the directory that you pointed ETC to, run
> "make -C /var/lib/misc", and add "db" to /etc/nsswitch.conf on the
> "passwd" line.
> 
> Meanwhile, I'm going to have to implement it properly and remove
> dh_sysuser from my build-depends. Ah well.

So sad. Maybe you could suggest what should I use instead of 'useradd/userdel'
in sysuser-helper to make dh-sysuser also work with NSS?

Bug#901136: can't remove if install fails

[KAction]

control: tag -1 +help

> Control: reassign -1 sysuser-helper,sreview-common
> Control: retitle -1 sysuser-helper fails in terrible ways if users exist 
> through NSS modules that are not libnss-unix

> On Sat, Jun 09, 2018 at 09:53:53AM +, Peter Palfrader wrote:
> > Package: sreview-common
> > Version: 0.3.0-1~bpo.1
> > Severity: grave
> > User: debian-ad...@lists.debian.org
> > Usertags: needed-by-DSA-Team
> > 
> > 
> > sreview-common failed to configure.
> > 
> > | Setting up sreview-common (0.3.0-1~bpo.1) ...
> > | usermod: user 'sreview' does not exist in /etc/passwd
[...]

Bad, bad. Oblivious workaround would be create user manually, but let us
dig into the root of problem.

I never worked with NSS, but how did it happen, that useradd {in postinst}
created user in a way, that userdel {in prerm} could not find?

Bug#900393: runit 2.1.2-14 breaks git-daemon-run

[KAction]

--21882_ĵaŭ_Maj_31_13_32_22_MSK_2018
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


[2018-05-29 23:53] Jonathan Nieder 
> part   text/plain 646
> Package: runit
> Version: 2.1.2-14
> Severity: serious
> Justification: breaks upgrades
> =

> The changelog to runit 2.1.2-14 explains:
> =

>* Do not install `update-service' script.
> =

> but it doesn't give any more context than that.  This breaks the
> git-daemon-run package, as noticed e.g. by piuparts:
> =

>   https://piuparts.debian.org/sid/fail/git-daemon-run_1:2.17.1-1.log
> =

> Moreover, debian/runit.NEWS doesn't say anything about the change.
> https://codesearch.debian.net/search?q=3Dupdate-service=3D1 finds
> some other callers. =


Yes, my fault -- I forgot to check codesearch. Sorry, I will revert it.

> Where can I read more about how to handle this, and can you roll back
> the change for now to unblock updates?

In this change I wanted to phase out `update-service` script, but was
not so careful about it. `update-service' functionality is better served
by dh-runit and coreutils instead:

 * installing all required symbolic links and, maybe, enabling service
   by default, is handled by `dh-runit'
 * --add: ln -sf /etc/sv/$name /etc/service
 * --remove: unlink /etc/service/$name (`rm -f' is fine too)
 * --list: ls -1 /etc/service
 * --check: sv status $name

--21882_ĵaŭ_Maj_31_13_32_22_MSK_2018
Content-Type: application/pgp-signature

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEhnHVzDbtdH7ktKj4SBLY3qgmEeYFAlsPzzYACgkQSBLY3qgm
EeZKGQ//UH/8NtAYsZo06M2QglY/3Sl1vJZxsk6KKAcHZ3QIqDLl9OvCVyhL2y9W
lvIRdF218nPIvP2IYQnno0NIAuEMarYkbt7gCHIMUhkrbNkqJH2AYa2vQfmn6sUH
ucjsahtswNbKsydvYWhi98OkwUAa3fVosuuYTBKKkDkjT+flJJhBSnfOJIeEJhDI
5upK1kd+UtAKalarXDdEWOHTaZWpk8MdQN0S/NcyaPjT0kNu/WyJHpD1YiWeBS8v
oxdGEm0wzffOhPvnO0kxVk5w5g/i6RuH12Y7q3zuiEx1vhi4XSQ1MT+4zvZAT9H6
GZiM9YdHJGNVlbrftl+yrO1TvW6xcaWH8nvJ5EneXby+b/rOwxJwP/r23P/uCtHJ
ye797ZIr6OMPboLga0sqQBfnd0FVhFKJeggJy1cIDAOdKduKPTJ7hqqeJKhkCHEr
FDDW5e+UY9O+oE0XRNLbmboiCXtgZfXlEMBx0MlAm3HbZay9YlBat42J6p3q8omx
O+9AAomEf5hcBMMF3TT0rRnsoMuNEXTqjKFouRwvm9yzDZSszqcBy6L53mpPdrZM
OKPo8LH7RSOgViz9pFwolyTpS2JHut+2B68nbjXk9E1xtz+VFznQ60LxGmQG8xSL
r+Wp58PhHKrwMUy4xE9l5OINcQhg0s9oVV3KkK/D2Q5LddsiAc4=
=RoM3
-END PGP SIGNATURE-

--21882_ĵaŭ_Maj_31_13_32_22_MSK_2018--

Bug#895811: inotify-tools: do not enable sanitizers in production

[KAction]

[2018-04-16 11:25] James Cowgill 
> part 1.1.1 text/plain1507
> Source: inotify-tools
> Version: 3.14-4
> Severity: grave
> 
> Hi,
> 
> In inotify-tools 3.14-4, all the qa sanitizers were enabled in
> DEB_BUILD_MAINT_OPTIONS. This should not be done in production.
> 
> * The man page for dpkg-buildflags explicitly states these options
> should not be used in production builds and are for debugging only.
> [...]

My fault, definitely. Somehow I missed that warning in manpage.  Will
fix.