Bug#926854: sysv-rc: remove check for .legacy-bootordering
[2020-05-29 16:17] Thorsten Glaser > Hi Dmitry, Hi, > >With legacy bootordering gone in 2012, it is safe to remove check for > >/etc/init.d/.legacy-bootordering from /etc/init.d/rc script. > > I disagree here: touching this file was a good way (and needed in some > cases I don’t remember any more) for getting back reliable boot, and I > have this file in my standard instructions for setting up a Debian sy‐ > stem… on systems even as recent as buster booting worked with it. > > So please bring it back by reverting commit 340c02c2d3ef1d9cad35129e2. > I’ll commit that to sysvinit’s packaging repo unless objection is rai‐ > sed within a week. I can't bring anything back. I gave up all Debian-related credentials. > Dmitry, sorry to disturb but, if I may ask, what, other than “we don’t > enable legacy-bootordering any more and require insserv” motivated the > commit? Nothing else. > It’s still useful to avoid parallel boot… (/proc/cmdline can’t > be controlled in all environments and removing the .depend.* files… is > probably not right either). From purity poing of view, I would disagree: if you have very special situation that you can't configure bootloader to set /proc/cmdline /and/ need sequencial boot, then peeking on implementation detail and removing /etc/.depend.* is fine answer. On other hand, from practicality point of view, we are talking about mere 3 lines, and if they can keep somebody's old-and-tried setup working, then it worth it.
Bug#919181: status of ITP: laminar
[2020-02-27 11:40] meskio > Dmitry, I see the issue on vue-router.js has being solved since some months. > But > no movement has being happening in this ITP. Are you still interested on > packaging it? Do you need some help? Or someone to take it over? > > I have updated your package to the latest laminar release (0.8): > https://salsa.debian.org/meskio-guest/laminar/ If you (or somebody else) wish, go ahead, take over it. I no longer work on Debian. PS. Developer reference should also have instruction that on quit developer should change all ITP to RFP.
Bug#924269: chiark-really: providing bin:sudo
control: submitter -1 kact...@disroot.org
[2020-02-13 11:30] Ian Jackson
> Control: tags -1 confirmed help
>
> Hi. I hope you appreciate me writing to your non-Debian address with
> this. You may wish to update the bug submitter.
Thanks. Just did it.
> Dmitry Bogatov writes ("Bug#924269: chiark-really: providing bin:sudo"):
> > No, since problem is with debian packages relationships. And, by the
> > way, /sbin/really does not set PATH. Note, that I do not propose
> > complicating bin:chiark-really, I propose separate binary package with
> > tiny wrapper.
>
> I was going through chiark-utils bugs and noticed I hadn't replied to
> this. Sorry.
>
> Your suggestion makes sense and I would accept patches. Preferably as
> a git branch - you can find the git history with `dgit clone' - but
> any other format would be welcome.
>
> Since I wouldn't use this feature myself I don't currently intend to
> implement it myself.
Since I no longer use Debian, neither do I. Feel free to close bug.
Bug#929884: dnsmasq: please provide runscript file
[ I no longer using Debian, added new runit maintainer into CC. ] [2020-02-12 22:28] Simon Kelley > A query: the runscript/run file in the patch ignores > /etc/default/dnsmasq. If that deliberate, or an oversight? Runscript is using #!/lib/runit/invoke-run as interpreter, which sources /etc/default/dnsmasq automatically.
Bug#947646: O: gdbm -- GNU dbm database routines (development files)
Source: wnpp
Severity: important
Hereby I orphan package gdbm:
GNU dbm ('gdbm') is a library of database functions that use extendible
hashing and works similarly to the standard UNIX 'dbm' functions.
.
The basic use of 'gdbm' is to store key/data pairs in a data file, thus
providing a persistent version of the 'dictionary' Abstract Data Type
('hash' to perl programmers).
.
Note, that to build old programs, that use legacy 'dbm' interface,
you have to install libgdbm-compat-dev binary package.
pgpSeYAjnnBX4.pgp
Description: PGP signature
Bug#947647: O: ucspi-unix -- UNIX-domain socket client-server command-line tools
Source: wnpp Severity: normal Hereby I orphan package ucspi-unix: unixclient and unixserver are command-line tools for building UNIX domain client-server applications. unixclient connects to a UNIX domain socket and runs a program of your choice. unixserver creates a UNIX domain socket, waits for incoming connections and, for each connection, runs a program of your choice. . unixclient and unixserver conform to UCSPI, the UNIX Client-Server Program Interface, using UNIX domain sockets. UCSPI tools are available for several different networks. . See http://cr.yp.to/proto/ucspi.txt for more information on UCSPI. network::service, role::program network::service, role::program pgp5ZZzUqrkvf.pgp Description: PGP signature
Bug#947645: O: mini-httpd-run -- Small HTTP server (Runit integration)
Source: wnpp Severity: normal Hereby I orphan package mini-httpd-run: mini-httpd implements all basic features of a HTTPD, including: GET,HEAD,POST methods, common MIME types, basic authentication, virtual hosting, CGI, directory listing, trailing-slash redirection, standard logging, custom error pages etc. It also can be configured to do SSL and IPv6. . This package contains scripts to run mini-httpd under Runit supervision system. pgpZ0ftNKOy0f.pgp Description: PGP signature
Bug#947642: O: debrequest -- tool to generate RFS and ITP requests mails
Source: wnpp Severity: normal Hereby I orphan package debrequest: Debrequest command line program collects machine-readable information from files in debian/ directory of source package and use is to generate RFS or ITP request. . Request formatted will be output on stdout and is well-formed RFC822 message, suitable for piping to `/sbin/sendmail'. pgpe73VBcSp6D.pgp Description: PGP signature
Bug#947641: O: cdist -- Usable Configuration Management System
Source: wnpp Severity: normal Hereby I orphan package cdist: cdist is a usable configuration management system. It adheres to the KISS principle and is being used in small up to enterprise grade environments. It has the following noteworthy features: . * shell scripting configuration language * access to all control structures (if, case, for, while) * idempotent target properties * zero-dependencies: target system need only /bin/sh and ssh * push-based distribution * highly-scalable . cdist is an alternative to other configuration management systems like cfengine, bcfg2, chef and puppet. cdist is a usable configuration management system. It adheres to the KISS principle and is being used in small up to enterprise grade environments. It has the following noteworthy features: . * shell scripting configuration language * access to all control structures (if, case, for, while) * idempotent target properties * zero-dependencies: target system need only /bin/sh and ssh * push-based distribution * highly-scalable . cdist is an alternative to other configuration management systems like cfengine, bcfg2, chef and puppet. pgpmIXKmVfNw9.pgp Description: PGP signature
Bug#947637: O: runit -- system-wide service supervision
Source: wnpp Severity: normal Hereby I orphan package runit: runit is a collection of tools to provide system-wide service supervision and to manage services. Contrary to sysv init, it not only cares about starting and stopping services, but also supervises the service daemons while they are running. Amongst other things, it provides a reliable interface to send signals to service daemons without the need for pid-files, and a log facility with automatic log file rotation and disk space limits. . runit service supervision can run under sysv init or replace the init system completely. Complete init replacement provided by 'runit-init' package. scope::utility /etc/runit/1 d0ccefe92a53d3b18752eb54d4e4defe /etc/runit/2 8783a10eaf38d959d8a422c401f5b64b /etc/runit/3 e82065ff79b686ec132623fa5f207617 /etc/runit/runsvdir/single/sulogin/run 8971956d3d9d6501897b0d520d458dc0 runit is a collection of tools to provide system-wide service supervision and to manage services. Contrary to sysv init, it not only cares about starting and stopping services, but also supervises the service daemons while they are running. Amongst other things, it provides a reliable interface to send signals to service daemons without the need for pid-files, and a log facility with automatic log file rotation and disk space limits. . runit service supervision can run under sysv init or replace the init system completely. Complete init replacement provided by 'runit-init' package. scope::utility pgpeZkST1mlaO.pgp Description: PGP signature
Bug#947643: O: ceni -- Curses interface to /etc/network/interfaces
Source: wnpp Severity: normal Hereby I orphan package ceni: A Curses user interface for configuring network interfaces with ifupdown. Ceni can manage basic network interface ifupdown configuration stanzas for ethernet and wireless devices. pgpCR0ceDu0xc.pgp Description: PGP signature
Bug#947639: O: dh-runit -- debhelper add-on to handle runit runscripts
Source: wnpp Severity: normal Hereby I orphan package dh-runit: dh-runit provides a debhelper sequence addon named 'runit' and the dh_runit command. . The dh_runit command installs runscripts and adds the appropriate code to the postinst, prerm and postrm maint scripts to properly enable/disable runscripts. dh-runit provides a debhelper sequence addon named 'runit' and the dh_runit command. . The dh_runit command installs runscripts and adds the appropriate code to the postinst, prerm and postrm maint scripts to properly enable/disable runscripts. pgpfC_OBfrqRj.pgp Description: PGP signature
Bug#947636: O: fbless -- terminal fiction book reader
Source: wnpp Severity: normal Hereby I orphan package fbless: Fbreader is ncurses fiction book (.fb2) reader with following features: . * customizable color themes * last viewed point saving * autoscroll mode * support for archived books * basic links support Fbreader is ncurses fiction book (.fb2) reader with following features: . * customizable color themes * last viewed point saving * autoscroll mode * support for archived books * basic links support pgp7U1peu_K4O.pgp Description: PGP signature
Bug#947644: O: node-ansi-up -- convert text containing ANSI color escape codes into HTML
Source: wnpp Severity: normal Hereby I orphan package node-ansi-up: This library provide function that takes a stream of text and transforms it into proper HTML with colors. It does this by buffering the data and performing multiple passes over the stream. Each time it consumes data, it may or may not emit HTML. This HTML will always be proper HTML. . Node.js is an event-based server-side JavaScript engine. pgpX2Q_kqGOwN.pgp Description: PGP signature
Bug#947635: O: ucspi-tcp -- command-line tools for building TCP client-server applications
Source: wnpp Severity: normal Hereby I orphan package ucspi-tcp: tcpserver waits for incoming connections and, for each connection, runs a program of your choice. Your program receives environment variables showing the local and remote host names, IP addresses, and port numbers. . tcpserver offers a concurrency limit to protect you from running out of processes and memory. When you are handling 40 (by default) simultaneous connections, tcpserver smoothly defers acceptance of new connections. . tcpserver also provides TCP access control features, similar to tcp-wrappers/tcpd's hosts.allow but much faster. Its access control rules are compiled into a hashed format with cdb, so it can easily deal with thousands of different hosts. . This package includes a recordio tool that monitors all the input and output of a server. . tcpclient makes a TCP connection and runs a program of your choice. It sets up the same environment variables as tcpserver. . This package includes several sample clients built on top of tcpclient: who@, date@, finger@, http@, tcpcat, and mconnect. . tcpserver and tcpclient conform to UCSPI, the UNIX Client-Server Program Interface, using the TCP protocol. UCSPI tools are available for several different networks. network::server, protocol::tcp, role::program tcpserver waits for incoming connections and, for each connection, runs a program of your choice. Your program receives environment variables showing the local and remote host names, IP addresses, and port numbers. . tcpserver offers a concurrency limit to protect you from running out of processes and memory. When you are handling 40 (by default) simultaneous connections, tcpserver smoothly defers acceptance of new connections. . tcpserver also provides TCP access control features, similar to tcp-wrappers/tcpd's hosts.allow but much faster. Its access control rules are compiled into a hashed format with cdb, so it can easily deal with thousands of different hosts. . This package includes a recordio tool that monitors all the input and output of a server. . tcpclient makes a TCP connection and runs a program of your choice. It sets up the same environment variables as tcpserver. . This package includes several sample clients built on top of tcpclient: who@, date@, finger@, http@, tcpcat, and mconnect. . tcpserver and tcpclient conform to UCSPI, the UNIX Client-Server Program Interface, using the TCP protocol. UCSPI tools are available for several different networks. network::server, protocol::tcp, role::program pgpl_bm5N2Lev.pgp Description: PGP signature
Bug#947640: O: fgetty -- very small, efficient, console-only getty and login
Source: wnpp Severity: normal Hereby I orphan package fgetty: fgetty is a small, efficient, console-only getty for Linux. It is derived from mingetty but hacked until it would link against diet libc to produce the smallest memory footprint possible for a simple yet complete getty. . fgetty includes a login program that supports the checkpassword authentication interface, and also a checkpassword program that uses the standard C library interface to passwd and shadow. use::login fgetty is a small, efficient, console-only getty for Linux. It is derived from mingetty but hacked until it would link against diet libc to produce the smallest memory footprint possible for a simple yet complete getty. . fgetty includes a login program that supports the checkpassword authentication interface, and also a checkpassword program that uses the standard C library interface to passwd and shadow. use::login pgpFSCBu6fjvC.pgp Description: PGP signature
Bug#947638: O: simple-revision-control -- single-file and single-user revision control system
Source: wnpp Severity: normal Hereby I orphan package simple-revision-control: This package provides a powerful modern user interface for an RCS (and to some extend, SCCS) backend. It will be familiar to users with modern Subversion, Git, Hg experience, as well as a reasonable introduction to this toolset to novices. . SRC is designed to provide its strength for single-file, single-user version tracking. When it is overkill to make a whole directory and multi-file repository store (under, for example, Git or Hg), src can provide tracking for individual files instead. Examples of such might be your ~/bin scripts, /etc files, personal notes, résumés, and any such file that would be awkward to contain in a wholly separate directory just for version control. pgpbaFmG85AP1.pgp Description: PGP signature
Bug#947634: O: complexity -- tool for analyzing the complexity of C program functions
Source: wnpp Severity: normal Hereby I orphan package complexity: Complexity measurement tool help to: . * locate suspicious areas in unfamiliar code * get an idea of how much effort may be required to understand that code * get an idea of the effort required to test a code base * provide a reminder to yourself. You may see what you've written as obvious, but others may not. . Comparing with existing tool McCabe, this program improves scoring of following language constructs: . * code length * switch statement * logic conditions Complexity measurement tool help to: . * locate suspicious areas in unfamiliar code * get an idea of how much effort may be required to understand that code * get an idea of the effort required to test a code base * provide a reminder to yourself. You may see what you've written as obvious, but others may not. . Comparing with existing tool McCabe, this program improves scoring of following language constructs: . * code length * switch statement * logic conditions pgpBqyd2rJdks.pgp Description: PGP signature
Bug#947633: O: eoconv -- convert text files between various Esperanto encodings
Source: wnpp Severity: normal Hereby I orphan package eoconv: Esperanto is written in an alphabet of 28 letters. However, only 22 of these letters can be found in the standard ASCII character set. The remaining six -- `c', `g', `h', `j', and `s' with circumflex, and `u' with breve -- are not available in ASCII. Various encoding systems have been developed to represent Esperanto text in printed and typed text. eoconv program converts between them. pgpMP2u2eCt5s.pgp Description: PGP signature
Bug#947631: O: dh-sysuser -- debhelper addon to handle creation of system users
Source: wnpp Severity: normal Hereby I orphan package dh-sysuser: dh-sysuser provides a debhelper sequence addon named 'sysuser' and command 'dh_sysuser', which provide declarating way to ensure, that required users are present after package installation and correctly handled after package removal. dh-sysuser provides a debhelper sequence addon named 'sysuser' and command 'dh_sysuser', which provide declarating way to ensure, that required users are present after package installation and correctly handled after package removal. dh-sysuser provides a debhelper sequence addon named 'sysuser' and command 'dh_sysuser', which provide declarating way to ensure, that required users are present after package installation and correctly handled after package removal. pgpwsAkPhOqLj.pgp Description: PGP signature
Bug#947632: O: inotify-tools -- command-line programs providing a simple interface to inotify
Source: wnpp Severity: normal Hereby I orphan package inotify-tools: inotify-tools is a set of command-line programs for Linux providing a simple interface to inotify. These programs can be used to monitor and act upon filesystem events. inotify-tools consists of two utilities: . inotifywait simply blocks for inotify events, making it appropriate for use in shell scripts. . inotifywatch collects filesystem usage statistics and outputs counts of each inotify event. role::program, scope::utility, works-with::file inotify-tools is a set of command-line programs for Linux providing a simple interface to inotify. These programs can be used to monitor and act upon filesystem events. inotify-tools consists of two utilities: . inotifywait simply blocks for inotify events, making it appropriate for use in shell scripts. . inotifywatch collects filesystem usage statistics and outputs counts of each inotify event. role::program, scope::utility, works-with::file pgpottKDLAEKN.pgp Description: PGP signature
Bug#947629: O: bcron -- Bruce cron system
Source: wnpp Severity: normal Hereby I orphan package bcron: Bruce cron system is designed with secure operations in mind. To do this, the system is divided into several separate programs, each responsible for a separate task, with strictly controlled communications between them. . The user interface is a drop-in replacement for similar systems, such as vixie-cron, but the internals differ greatly. pgpnLA6TT5e9Z.pgp Description: PGP signature
Bug#947625: O: mmh -- set of electronic mail handling programs
Source: wnpp Severity: normal Hereby I orphan package mmh: This is the mmh mail user agent (reader/sender), a command-line based mail reader that is powerful and extensible. mmh is an excellent choice for people who receive and process a lot of mail. . Unlike most mail user agents, mmh is not a single program, rather it is a set of programs that are run from the shell. This allows the user to utilize the full power of the Unix shell in coordination with mmh. . Mmh is a modified version of the electronic mail handling system nmh. Nmh (new MH) itself was originally based on the package MH-6.8.3, and was intended to be a (mostly) compatible drop-in replacement for MH. In contrast, mmh is not intended to be a drop-in replacement for nmh, rather mmh breaks compatibility to nmh in order to modernize and simplify it. pgpHBjSAimZPD.pgp Description: PGP signature
Bug#947627: O: dvtm -- Tiling window management for the console
Source: wnpp Severity: normal Hereby I orphan package dvtm: dvtm (dynamic virtual terminal manager) brings dwm and its concept of tiling window management to the console. As a console window manager it tries to make it easy to work with multiple console based programs. pgpnJqmegauBk.pgp Description: PGP signature
Bug#947628: O: bglibs -- BG Libraries Collection
Source: wnpp Severity: normal Hereby I orphan package bglibs This package contains a collection of libraries written by Bruce Guenter and put in use in various packages. . The library collection is mandatory to build most of software packages available at http://untroubled.org. . This package contains the shared libraries. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients. pgpUZbDKyKKlW.pgp Description: PGP signature
Bug#947624: O: tup -- fast build system
Source: wnpp Severity: normal Hereby I orphan package tup: Tup is a file-based build system for Linux, OSX, and Windows. It takes as input a list of file changes and a directed acyclic graph (DAG). It then processes the DAG to execute the appropriate commands required to update dependent files. Updates are performed with very little overhead since tup implements powerful build algorithms to avoid doing unnecessary work. This means you can stay focused on your project rather than on your build system. pgpIbCFoDLbyD.pgp Description: PGP signature
Bug#947626: O: alternative-libc-build-helpers -- helper to build Debian package with diet libc
Source: wnpp Severity: normal Hereby I orphan package alternative-libc-build-helpers: This package provide makefile snippet, that abstract away several issues, related to building package with diet libc. . * diet libc is not supported on every Debian architecture * code to check for build profiles is repetive pgpeHlD2Dh8MU.pgp Description: PGP signature
Bug#946197: Let's switch to OpenRC?
control: tags -1 +wontfix [2019-12-05 10:32] Thomas Goirand > Source: sysvinit > Severity: normal > > Dear sysvinit maintainers, > > OpenRC is actively maintained upstream, and is a full replacement of sysv-rc, > including many improvements. > > Currently, packages are stuck with long, non-declarative sysv-rc scripts, and > cannot switch to superior runscripts, interpreted by /sbin/openrc-run, which > enable declarative-only scripts. > > So, my proposal is to get rid of sysv-rc provided by sysvinit, in the favor of > OpenRC, so that developers can start replacing their init scripts by superior > runscripts. Personally, I like openrc more that sysv-rc, but as was already pointed, sysv-rc already here and works, while pushing support for another init system into ~1300 packages is hard. And if current General Resolution will favor systemd-only vision of Debian future, then it will become plainly impossible. Tagging as wontfix. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#945820: sysvinit_2.96-2_amd64.changes REJECTED
[2019-11-29 09:49] Aurelien Jarno > On 2019-11-28 22:04, Debian FTP Masters wrote: > > sysvinit-core_2.96-2_amd64.deb: has 2 file(s) with a timestamp too far in > > the past: > > usr/share/doc/sysvinit-core/copyright (Thu Jan 1 00:00:01 1970) > > usr/share/doc/sysvinit-c > ore/changelog.Debian.gz (Thu Jan 1 00:00:01 1970) I do not understand what happened. I did source-only upload, so I believe .deb files are generated by buildd, not me. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#945464: /lib/init/init-d-script: stop action: missing --oknodo in s-s-d invocation
control: tags -1 +confirmed [2019-11-25 12:06] Jan Braun > Dear Maintainer, > > The /lib/init/init-d-script errorneously returns failure when asked to > stop a non-running service: > [...] > > And indeed, one call to start-stop-daemon in /lib/init/init-d-script is > missing the --oknodo flag. Namely, the first call in the stop action: > [...] > Adding --oknodo in line 76 (line 2 in the quote) should fix this bug. Thank you very much for your detailed analysis. I included --oknodo flag as you suggested. Unless there is objections in upcoming few days, I will upload it. > Additionally, I'd like to point out that the calculation of the return > code in this function seems fishy to me: it will always be the return > code of the first s-s-d invocation, unless the second invocation returns > 2 (which aiui means "a process survived SIGKILL" in this context). > Wouldn't taking the maximum (or sum) of the two return codes be more > sensible? Sum is definitely not apporiate, since there is standard that specifies meanings of error codes of init.d script[^1]. But you raise valid point, and it is not clear to me why exit code 2 is handled specially. Also, returning 2 should mean "invalid or excess argument(s)", which is not the case. Should't we return exit code 1 in all cases when s-s-d fails? Collegues, opinions? Maybe anybody remember why it was done this way? [^1]: https://fedoraproject.org/wiki/EPEL:SysVInitScripts?rd=Packaging:SysVInitScript -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#943397: runit: Add a finish-default
[2019-11-13 14:35] Lorenzo Puliti > >Are you sure about "wrong sh syntax" part? > > You are right, this is very inaccurate. Just for the records, I've > made some tests : > [...] > > * invoke-run exits before executing run's file code --> exit -1 Can you please elaborate on this case? How could runsv(1) know whether "run" file was read or not? > From 36efd3382ed5908d1f53e8ba38193aab4e38e157 Mon Sep 17 00:00:00 2001 > From: Lorenzo Puliti > Date: Mon, 4 Nov 2019 19:48:37 +0100 > Subject: [PATCH 1/2] Add finish-default > > Add a finish-default file to be sourced from finish scripts > > Closes: #943397 Good. Thanks. Please, removed trailing newline and I think you want to set executable bit. > From f1cb3095e88293e715d320cc36bbbd333b8531f5 Mon Sep 17 00:00:00 2001 > From: Lorenzo Puliti > Date: Tue, 5 Nov 2019 23:49:58 +0100 > Subject: [PATCH 2/2] Update invoke-run manpage for finish-default > > Update invoke-run manpage to account for finish-default file and > special error codes. > [...] > +can be found in the run file, looking for lines like > +.PP > +.IP "" 6 > +.EX > +sv start dep1 && sv check dep1 || exit 170 I think I already pointed that dependencies could be started with code like this (or in any other form), so specifying exact pattern may be misleading. # some code that sets $@ sv start "$@" Not sure how to better put it. What about something like following: [...] to know dependencies of service look for "sv start" in "run" script. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#939733: lsb-release: lsb_release does not show point release on Debian 10.1
[2019-11-10 02:31] Santiago Vila
> > I am losing context. We have at least following three files (oh, why all
> > this madness?):
> >
> > * /usr/lib/os-release
> > * /etc/os-release
> > * /etc/debian_version
> >
> > So, in case of conflicts, what should override what?
>
> Please note that /usr/lib/os-release and /etc/os-release are the same file.
Thank you for your patience.
> AFAIK, lsb-release is already ignoring /etc/debian_version in buster,
> which is the reason we have this problem.
Not exactly. We have following code, where get_os_release() reads
"/usr/lib/os-release", and guess_debian_release() uses several other
files, including "/etc/debian_version".
lsbinfo = get_os_release()
# OS is only used inside guess_debian_release anyway
for key in ('ID', 'RELEASE', 'CODENAME', 'DESCRIPTION',):
if key not in lsbinfo:
distinfo = guess_debian_release()
distinfo.update(lsbinfo)
return distinfo
else:
return lsbinfo
So /etc/os-release overrides /etc/debian_version. Probably, we could
drop guess_debian_release() code though, since base-files are essential.
> b) As it has been suggested by you, fixing the problem in base-files
> by including the minor version in /etc/os-release "somewhere".
>
> I am ok with doing the change in base-files, because I believe it's
> the best option in the long term.
>
> I also believe that it would suffice to change VERSION_ID, but I need
> confirmation for that.
> [..]
>
> So: Is this ok for you?
Yes, that is fine. As I just checked, `lsb_release -d` (as is in
Archives) will happily output anything I put into VERSION_ID variable of
/etc/os_release.
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Bug#939733: lsb-release: lsb_release does not show point release on Debian 10.1
control: tags -1 +help [2019-11-08 13:42] Santiago Vila > Hi. > > I've asked the Release Managers about this here: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944351 > > If they say yes, I'll modify base-files accordingly (for Debian 10.2). > > If they say no, please be ready to fix the bug in lsb-release as soon > as you can, by making an upload to proposed-updates (there is a point > release around the corner). I am losing context. We have at least following three files (oh, why all this madness?): * /usr/lib/os-release * /etc/os-release * /etc/debian_version So, in case of conflicts, what should override what? BTW, help via NMU/Team upload is welcome. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#944224: Keep "dmesg" logging after boot.
control: tags -1 +wontfix [2019-11-06 10:12] "Gong S." > Package: initscripts > Version: 2.96-1 > Severity: wishlist > Currently, the "bootlogd" script only records the "dmesg" messages > during boot, and exits afterwards. You meant "bootlogs", I think. > However, most system issues happen after boot. > So when such issue happens, nothing is logged, so it is hard to find the > cause. > I think that it is wise to keep `dmesg` running after booting. > To be precise, change line 35 of "/etc/init.d/bootlogs" > from "dmesg -s 524288 > /var/log/dmesg" > to "nohup dmesg -Hwx > /var/log/dmesg". As was already pointed, -s makes sure that whole kernel ring buffer is dumped, and -H will be backward-incompatible change. Also, just starting process with `nohup foo &' is not proper way to start long-running process. If you want long-running process to keep saving kernel logs, you'd have to create init.d script, with "start" and "stop" commands. But wait, why to we need it? You probably already have syslog daemon running, and many of them know how to to save kernel logs too. At least socklog and rsyslog do. If you do not use syslog daemon, you can put command you propose into /etc/boot.d or directly into /etc/init.d/bootlogs (it is conffile!) Sorry, I do not see general value in your proposal. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#943397: runit: Add a finish-default
[2019-11-06 13:45] Lorenzo Puliti
> Package: runit
> Version: 2.1.2-35
> Followup-For: Bug #943397
>
> I'm attaching two patches for review;
> one thing that I'm still not sure about is the exit code range. $1 in
> the finish file can be run's exit code or the daemon's exit code. I'm
> using the wierd range 160-170 but is still possible that the exit code
> is overlapped with the one of some daemons, for example see smartd(8)
> 'EXIT STATUS' section. Do you have a better range to suggest?
I do not have better plan. And since you already used these values in
patches, let us stick to them.
> +NAME=$(pwd | cut -f4 -d"/")
Maybe NAME=${PWD##*/}? Also, `set -e`, please.
> +trap 'if [ "$VERBOSE" = 1 ]; then echo "runsv: $NAME stopped"; fi' EXIT
I'd say this is simplier:
if [ "${VERBOSE:-0}" != 0 ] ; then
trap "echo runsv: $NAME stopped" EXIT
fi
> +case $1 in
> + -1)
> + echo "runsv: ERROR $1 in $NAME: unexpected error or wrong sh
> syntax"
> + # no need to sv d service here, runsv will stop trying after
> the first attempt to start
> + ;;
Are you sure about "wrong sh syntax" part? As far as I know, shell exit
with $? = 2 in case of wrong syntax, and "runsv" has no means to
distinguish it from plain "exit 2". Also, runsv(1) mentions "didn't exit
correctly", which I believe means signal.
> + 161)
Please, follow same style as in invoke-run. Unmatched brackets drive
editors crazy.
> +++ b/debian/runit.install
> @@ -23,3 +23,4 @@ debian/contrib/runlevel /lib/runit
> debian/sulogin/run /etc/runit/runsvdir/single/sulogin
> debian/contrib/lib/async-timeout/lib/runit
> debian/contrib/lib/run_sysv_scripts /lib/runit
> +debian/contrib/lib/finish-default /lib/runit
!sort, please.
> part 3 text/plain3239
> From 642ffb914b6e7d67c723f7e620f3b9a404d7572e Mon Sep 17 00:00:00 2001
> From: Lorenzo Puliti
> Date: Tue, 5 Nov 2019 23:49:58 +0100
> Subject: [PATCH 2/2] Update invoke-run manpage for finish-default
>
> Update invoke-run manpage to account for finish-default file and
> special error codes.
> [...]
> +.IP "" 2
> +.B runsv: foo binary not installed
> +.PP
> +.IP "" 4
> +this happens when the
> +.I foo
> +binary has been removed, but not purged.
s/binary/package, containing binary/ or something like this. Binaries
(e.g ELF executable files) can't be removed-not-purged, binary packages
are.
> +.B runsv: ERROR -1 in foo: unexpected error or wrong sh syntax
> +.PP
> +.IP "" 4
> +this message comes from the finish file, but the exit code comes from
> +.BR runsv (8)
> +and is documented in its manpage.
Ditto on "wrong sh syntax"
> +.B runsv: ERROR 161 in foo: disabled by local settings
> +.PP
> +.IP "" 4
> +Some service specific setting prevent
> +.I foo
> +from starting; it's likely something in
> +.BI /etc/default/foo
Is it really ERROR? Maybe change it to "NOTE" or something like this?
By the way (and I agree), Policy deprecated following pattern:
$ grep DISABLED /etc/default/foo
DISABLED=1
> +.PP
> +.IP "" 2
> +.B runsv: ERROR 162 in foo: configtest or early setup failed
> +.PP
> +.IP "" 4
> +A configuration file of
> +.I foo
> +is malformed and the configtest failed;
> +.I foo
> +log may contain additional info from the test itself.
> +Otherwise
I think "alternatively" is more correct word. Take with grain of salt, I
am not native speaker.
> the runscript has failed to do some setup that is essential to the
> +.I foo
> +service.
> +.PP
> +.IP "" 2
> +.B runsv: ERROR 170 in foo: a runtime hard dependency is missing
> +.PP
> +.IP "" 4
> +A dependency failed the check and can't be bring up; a list of dependencies
> of
> +.I foo
> +can be extracted with the following command
> +.PP
> +.IP "" 6
> +.EX
> +grep 'exit 170' /etc/sv/foo/run | cut -d ' ' -f3
I'd not recommend this because of following:
if full_moon ; then
set -- dep1 dep2
else
set -- dep3 dep4
fi
sv up "$@" || exit 170
> +.SH FINISH FILE AND FINISH-DEFAULT
> +Since version 2.1.2-36 the Debian runit package ships a
> +.BI /lib/runit/finish-default
> +file that contains code that can be shared across different services.
> +This file can be sourced inside the regular finish file of a service,
> +like the following example
Wonderful.
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Bug#943998: O_TMPFILE not available on macOS
[2019-11-02 20:03] Clint Adams
> > FTBFS on macOS systems, because of undefined O_TMPFILE,
> > which was introduced in 4.9 release.
> >
> > Attempt to build was made here:
> > https://github.com/Homebrew/homebrew-core/pull/46107
>
> Dmitry, any thoughts? Maybe disabling --stdin on systems without O_TMPFILE?
Maybe it would better to provide emulation? This patch illustrates my
idea, but is /not/ tested:
+#ifdef O_TMPFILE
+static int open_tmpfile_rw(void)
+{
+ const char *tmpdir;
+
+ tmpdir = getenv("TMPDIR");
+ if (!tmpdir) {
+ tmpdir = "/tmp";
+ }
+
+ return open(tmpdir, O_TMPFILE|O_RDWR|O_EXCL, S_IRUSR | S_IWUSR);
+}
+#else
+static char tmpfile_path[] = "/tmp/run-parts.stdin.XX";
+static int cleanup_tmpfile(void)
+{
+ unlink(tmpfile_path);
+}
+
+static int open_tmpfile_rw(void)
+{
+ int fd;
+
+ fd = mkstemp(tmpfile_path);
+ if (fd != -1) {
+ atexit(_tmpfile);
+ }
+ return fd;
+}
+#endif
+
+
/*
* Copy stdin into temporary read-write file, and return file descriptor to it.
*/
@@ -396,15 +429,7 @@ static int copy_stdin(void)
char buffer[4096];
ssize_t bytes;
- tmpdir = getenv("TMPDIR");
- if (!tmpdir) {
-tmpdir = "/tmp";
- };
-
- fd = open(tmpdir, O_TMPFILE|O_RDWR|O_EXCL, S_IRUSR | S_IWUSR);
- if (fd < 0) {
-return -1;
- };
+ fd = open_tmpfile_rw();
do {
ssize_t rest;
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Bug#943583: sysv-rc: information from the Policy Manual for README.runlevels
[2019-10-28 21:51] Sean Whitton > >> but I'm not sure this text has actually ever been updated since Ian > >> Jackson wrote it the mid-nineties. > > > > It seems it is still correct. I double-checked last part, about > > runlevels 0/6, reading source of /etc/init.d/rc -- it is still accurate. > > What I meant here was that it might be that only Ian holds copyright on > the text, not the other copyright holders listed for the Policy Manual > in general. Then it means that I did not update d/copyright in src:sysvinit, and it was right thing to do. Or am I missing any other consequence? -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#943395: runit: Minor fixes to invoke-run
control: tags -1 +pending [2019-10-30 19:45] Lorenzo Puliti > Package: runit > Version: 2.1.2-35 > Followup-For: Bug #943395 > > patch refreshed Thank you. Applied in git. Do you want me to upload #943395 and #942320 right now, or wait for dh-runit and git-daemon? -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#943583: sysv-rc: information from the Policy Manual for README.runlevels
control: tags -1 +pending [2019-10-26 14:11] Sean Whitton > We are removing some implementation details of the runlevels system from > the Policy Manual. Most of the information is duplicated in > README.runlevels as shipped by sysv-rc, and is anyway not relevant to > package maintainers as such, who are only allowed to invoke update-rc.d. > > Directly comparing the text we're removing with the contents of > README.runlevels, however, reveals that the old Policy Manual text > assumes a lot less knowledge of classic UNIX init practices than does > README.runlevels. > > It seems to me that someone who had only ever worked with systems using > systemd, and who now needed to learn how sysvinit runlevels work, would > have an easier time of it if they had the Policy Manual text in addition > to README.runlevels. > > In particular, these three paragraphs explain ideas which are (at least > partially) implicitly assumed by README.runlevels: > > [...] Thank you for you work on comparing with README.runlevels. I included provided paragraphs. > but I'm not sure this text has actually ever been updated since Ian > Jackson wrote it the mid-nineties. It seems it is still correct. I double-checked last part, about runlevels 0/6, reading source of /etc/init.d/rc -- it is still accurate. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#943395: runit: Minor fixes to invoke-run
[2019-10-27 18:31] Lorenz
> > > - "${initscript}" stop
> > > + "${initscript}" stop >/dev/null
> >
> > Why?
> The output from Sysv init script goes to the runit log and it's not
> clear that is from sysv script; also, it's a stop message during a
> start sequence. It's quite confusing.
Reasonable. Can you please refresh patch aganist latest head
(4b1d0685456442f033c00ab0d3cb594d92d0a786), without whitespace changes?
Patch you have sent have missing From: header.
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Bug#942320: update-service: use .symlink to mark a service as disabled
control: tags -1 +pending [2019-10-24 13:10] Lorenzo Puliti > Package: runit > Version: 2.1.2-35 > Followup-For: Bug #942320 > > > Looks good to me, but does not apply: > > Sorry, I somehow picked up the wrong branch. > New patch should be ok Yes, it is okay. Thanks. Applied in git. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#943397: runit: Add a finish-default
[2019-10-24 14:34] Lorenzo Puliti > Package: runit > Version: 2.1.2-35 > Severity: normal > > As discussed in #934231 > > [Dmitry Bogatov] > >> create mode 100644 debian/anacron.runscript/finish > > > There is nothing in this script specific to anacron. I propose > > following: > > [] > > I'm testing the following > > $cat /lib/runit/finish-default > #!/bin/sh > > # no need to sv d service here, runsv will stop trying after the first > attempt to start > [ $1 = -1 ] && echo "runsv: ERROR $1 in $NAME: unexpected error or wrong sh > syntax" > > [ $1 = 161 ] && echo "runsv: ERROR $1 in $NAME: disabled by local settings" \ > && sv d $NAME && exit 0 > > [ $1 = 162 ] && echo "runsv: ERROR $1 in $NAME: configtest or early setup > failed" \ > && sv d $NAME && exit 0 > > [ $1 = 170 ] && echo "runsv: ERROR $1 in $NAME: a runtime hard dependecy is > missing" \ > && sv d $NAME && exit 0 > > exit 0 There is no need in last "exit 0", and please use more verbose and easier to understand "if-then style". Style "foo && bar && zz" interacts unexpectedly with "set -e". You can use "! foo || bar", but we are not after code golf here. > [...] > > As you can see, there is still some non-service specific code, but I don't > know > how to export the NAME inside the sourced script, is it feasible in > dash/POSIX? > Also some daemon may need specific code between Maybe we can change intended usage of "finish-default" to source-only, so /etc/runsv//finish would contain something like #!/bin/sh . /lib/runit/finish-default "$@" This way /lib/runit/finish-default will have access to $0, and definition of NAME could be moved into internals of /lib/runit/finish-default. Also, you can use 'trap "do_stuff" EXIT' to get messages printed on the end of script. Use of "trap EXIT" must be documented, though, as there can be only one trap. To convey such intention, it is possible to give /lib/runit/finish-default following shebang: #!/bin/echo this script must be sourced, not executed. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#943395: runit: Minor fixes to invoke-run
[2019-10-24 13:45] Lorenzo Puliti
> Package: runit
> Version: 2.1.2-35
> Severity: wishlist
> Tags: patch
>
> Hi,
Hi!
> while doing another round of testing with openssh-server i've found
> some minor problem that might need a fix. Detailed description is in
> git commit message.
Something is missing? I see patch 2/2, but not 1/2.
> From bb212cbba9d01476f4a9c29a81c07e7c922c078f Mon Sep 17 00:00:00 2001
> From: Lorenzo Puliti
> Date: Thu, 24 Oct 2019 11:59:05 +0200
> Subject: [PATCH 2/2] minor improvements to invoke-run
>
> * be verbose about uninstalled binary
> * fix indentation in previous patch [1d28c60d] replacing spaces with TAB
> * redirect output of {$initscripts} stop to /dev/null (it goes to
> service log otherwise); it is confusing to see a stop message during
> service startup
> ---
> debian/contrib/lib/invoke-run | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/debian/contrib/lib/invoke-run b/debian/contrib/lib/invoke-run
> index 2a11306..54e6d47 100755
> --- a/debian/contrib/lib/invoke-run
> +++ b/debian/contrib/lib/invoke-run
> @@ -38,15 +38,16 @@ if [ -f "/etc/sv/${service}/.meta/installed" ] ; then
> # uninstalled, but not purged. See #929693 and commit [4c485b]
> # in dh-runit repository.
> if ! [ -f "${installed}" ] ; then
> + echo "runsv: $NAME binary not installed"
Does not check for VERBOSE.
> sv down "${service}"
> exit 0
> fi
> fi
>
> if [ -r /etc/default/runit ]; then
> -set -a
> -. /etc/default/runit
> -set +a
> + set -a
> + . /etc/default/runit
> + set +a
> fi
Indentation change. I do not see why it is necessary, but if it is,
please move to separate commit.
> if [ -r "/etc/default/${service}" ] ; then
> @@ -69,7 +70,7 @@ if [ -x "${initscript}" ] ; then
> exit 0
> fi
> fi
> - "${initscript}" stop
> + "${initscript}" stop >/dev/null
Why?
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Bug#942323: runit-helper: Use dot-symlinks to mark a service as disable
[2019-10-22 01:43] Lorenz > > Sorry, don't follow. Previously no link in /etc/service was created > > if dh-runit decides that service should not be enabled, now hidden > > link is created instead. How it is more confusing? > > OK, from existing users there are no visible consequences and a bug is > fixed. I just meant that probably should be documented somewhere that > runit uses .simlink to mark a service as disabled. No doubt, documentation would be good. I think the most apporiate medium would be introduction of README in bin:runit and short entry in debian/NEWS, like sysvinit does it. > > What buggy behaviour will this change cause for git-run users? > > git-daemon-run use 'update-service --remove' in its maint scripts, so > after #942320 patch is applied, it will set git daemon as disabled on > remove (as it was a user choice) and it will delete the setting on > install. As I remember, git still provides runscript in separate package and does not use dh-runit. How complicated would it be to create patch for src:git that would at least prevented regression due hidden link change? Also, see comments on #942320. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#942320: update-service: use .symlink to mark a service as disabled
[2019-10-14 16:40] Lorenzo Puliti > Hi, Hi! > this is to be consistent with a patch that I'm about to send > for dh-runit. > The attached patch here makes update-service create a .symlink > rather than just removing the symlink to disable a service. > This will help in preserving local admin choice to keep a service disabled. > I've added some detail in the man page but I hope to provide some more > detailed info in update-rc.d man page as runit support is merged there. Looks good to me, but does not apply: > ln -s /var/lib/runit/log/supervise/"$sv" "$svdir"/log/supervise this line of context >fi > fi > +if [ -d "$servicedir"/."$sv" ]; then > +rm "$servicedir"/."$sv" > +fi is nowhere to be found in "debian/contrib/update-service". I am looking at commit [dae57fa82797b673ca9116a81048dedd5ab523db]. I guess you based this your patch on pre-5d98b parent. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#926896: sysvinit-utils: pidof is unreliable
control: tags -1 +help [ Adding to thread "apcupsd" Debian maintainer and "pidof" upstream maintainer. ] [2019-10-21 14:27] Martin von Wittich > Am 20.10.19 um 20:59 schrieb Dmitry Bogatov: > > > > That sounds explainable. pidof() scans /proc directory, and it takes some > > time for kernel to create entry there. > [...] > Even if there were, that wouldn't explain how ps is able to see the > process, while pidof is not. As far as I know, ps also gets this > information from /proc. True. > To verify my assumptions, I've adapted my test script as follows: I adjusted script slightly (added -d option to first ls and replaced "systectl" with "/etc/init.d" like following: #!/bin/bash set -eu /etc/init.d/apcupsd restart START=$SECONDS ps -f -C apcupsd PID="$(ps -o pid -C apcupsd --noheaders)" ls -d /proc/"$PID" while true do echo -n "pidof: " pidof -s apcupsd || echo echo -n "ls: " ls -d /proc/"$PID" [ $((SECONDS - START)) -ge 2 ] && break sleep 0.01 done ps -f -C apcupsd > So the /proc/26476 is there even when pidof doesn't see the process. > >> But there are almost always holes in the output further on, so it's > >> also slightly unreliabl afterwards. and wasn't able to reproduce holes in the middle, but I did observed hole at the beginning: Stopping UPS power management: apcupsd. Starting UPS power management: apcupsd. UIDPID PPID C STIME TTY TIME CMD root 24352 1 0 22:51 ?00:00:00 /sbin/apcupsd /proc/24352 pidof: ls: /proc/24352 pidof: 24352 [... all below is as expected ...] Hole in beginning happened reproducibly, 100% of time. > I had assumed that the problem should be easily reproducible with any > other recently-started process, but that is apparently not the case: > [...] > > Maybe systemd is somehow involved? I tried to replace apcupsd with another servers on my box (tor, apt-cacher-ng), but no holes happened with them. I can't exclude that systemd is somehow related to holes in the middle you observe, but hole in beginning is mysterious enough. Personally, I am out of ideas: as far as I know (and I just web-searched), there is only one way to get list of processes: scan /proc. Jesse, any ideas how it could be possible for process to be discovered by ps(1), but not pidof(1)? Dear apcupsd maintainer, any suggestions how "apcupsd" server process could be special, that it is not discovered by pidof(1) for some time after restart and, reportedly, even once in a while server is running? -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#942743: Simplify package rebuild with custom set of optional features
Source: tor
Severity: wishlist
Tags: patch
Dear maintainer,
In effort to simplify creation and maintenance of derivate packages with
custom set of optional features disabled, here are patches that
enabling/disabling of optional feature is matter of changing exactly one
line in debian/rules.
Applied together, these patches do not alter default configuration (e.g
what is generated by dpkg-buildpackage) is any way, they just make
futher modifications simplier.
From 40ebe9118b90f7524c0b693a457baa430e84ffb4 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Sat, 14 Sep 2019 01:06:42 +
Subject: [PATCH 1/3] Simplify package patching to disable systemd integration
---
debian/config/systemd.mk | 5 +
debian/rules | 7 ++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/debian/config/systemd.mk b/debian/config/systemd.mk
new file mode 100644
index 000..1248ce0
--- /dev/null
+++ b/debian/config/systemd.mk
@@ -0,0 +1,5 @@
+ifeq ($(DEB_HOST_ARCH_OS),linux)
+ dhoptions += --with systemd
+ confflags += --enable-systemd
+endif
+
diff --git a/debian/rules b/debian/rules
index def6107..898bf83 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,6 @@
#!/usr/bin/make -f
# -*- makefile -*-
+include debian/config/systemd.mk
DH_VERBOSE ?= 1
@@ -14,11 +15,6 @@ ifneq (,$(findstring
enable-openbsd-malloc,$(DEB_BUILD_OPTIONS)))
confflags += --enable-openbsd-malloc
endif
-ifeq ($(DEB_HOST_ARCH_OS),linux)
- dhoptions += --with systemd
- confflags += --enable-systemd
-endif
-
%:
dh \
$@ \
@@ -32,6 +28,7 @@ endif
override_dh_auto_configure:
! [ -e debian/micro-revision.i ] || cp debian/micro-revision.i
./micro-revision.i
dh_auto_configure -- \
+ --disable-systemd \
$(confflags) \
--prefix=/usr \
--mandir=\$${prefix}/share/man \
From f099d7efbf18e62e5842d10a56bde7577a7a78a3 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Sat, 14 Sep 2019 01:28:03 +
Subject: [PATCH 2/3] Simplify package patching to disable runit integration
---
debian/config/runit.mk | 1 +
debian/rules | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/debian/config/runit.mk b/debian/config/runit.mk
new file mode 100644
index 000..7eea147
--- /dev/null
+++ b/debian/config/runit.mk
@@ -0,0 +1 @@
+dhoptions += --with runit
diff --git a/debian/rules b/debian/rules
index 898bf83..12c65a2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,7 @@
#!/usr/bin/make -f
# -*- makefile -*-
include debian/config/systemd.mk
+include debian/config/runit.mk
DH_VERBOSE ?= 1
@@ -20,7 +21,6 @@ endif
$@ \
--with quilt \
--with autoreconf \
- --with runit \
$(dhoptions) \
--builddirectory=build \
--parallel
From 5d5cac651f89756a44b889a2c65085519eac74c7 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Mon, 16 Sep 2019 18:23:05 +
Subject: [PATCH 3/3] Simplify package patching to disable libseccomp
integration
---
debian/config/seccomp.mk | 5 +
debian/rules | 3 +++
2 files changed, 8 insertions(+)
diff --git a/debian/config/seccomp.mk b/debian/config/seccomp.mk
new file mode 100644
index 000..07ee2d4
--- /dev/null
+++ b/debian/config/seccomp.mk
@@ -0,0 +1,5 @@
+# This feature is required for "Sandbox" option.
+
+ifneq (,$(findstring $(DEB_BUILD_ARCH),amd64 i386))
+ confflags += --enable-seccomp
+endif
diff --git a/debian/rules b/debian/rules
index 12c65a2..28ca273 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,9 @@
#!/usr/bin/make -f
# -*- makefile -*-
+include /usr/share/dpkg/default.mk
include debian/config/systemd.mk
include debian/config/runit.mk
+include debian/config/seccomp.mk
DH_VERBOSE ?= 1
@@ -29,6 +31,7 @@ override_dh_auto_configure:
! [ -e debian/micro-revision.i ] || cp debian/micro-revision.i
./micro-revision.i
dh_auto_configure -- \
--disable-systemd \
+--disable-seccomp \
$(confflags) \
--prefix=/usr \
--mandir=\$${prefix}/share/man \
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Bug#942323: runit-helper: Use dot-symlinks to mark a service as disable
[2019-10-18 10:43] Richard Lucassen > Dmitry Bogatov wrote: > > > > I've documented this in update-service manpage (see #942320); maybe > > > this need also a 'POLICY' section in dh_runit(1) or a notice to > > > users of runit on upgrade? > > > > What are user-visible consequences for existing users? > > > > [ Added into CC for review Richard, who happened to have issues with > > unforeseen consequences and might see potential problems. ] > > The use of dot files is a much better option. But OTOH: shouldn't these > symlinks in /etc/service/ be part of the package runit-init instead of > runit? There seems to be some misunderstanding. We are discussing changes to "dh-runit" tool, that is used by daemon-providing packages to automate stuff needed to make runit integration work out-of-the-box. PS. Please keep bug in CC. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#926896: sysvinit-utils: pidof is unreliable
[2019-10-17 15:04] Martin von Wittich > I also just noticed this issue. We have a piece of code in our > software that uses pidof to wait to apcupsd to start; I've reduced it > to the following minimal working example: > [...] > There's always at least 4-6 empty "pidof:" lines at the beginning, so > apparently pidof never works in the ~40-60ms after a process was > launched. That sounds explainable. pidof() scans /proc directory, and it takes some time for kernel to create entry there. > But there are almost always holes in the output further on, so it's > also slightly unreliable afterwards. This is really wierd, given that pid is same: process is not restarted. > #!/bin/bash > > set -eu > > systemctl restart apcupsd Do you have receipe to reproduce issue on systemd-free box, so I can try to debug issue myself? -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#942323: runit-helper: Use dot-symlinks to mark a service as disable
[2019-10-18 15:20] Lorenzo Puliti > new patch attached Thank you. > > What are user-visible consequences for existing users? > > Few comes to my mind: > > * In Sysv KNNfoo symlinks are visible, while here .foo symlink are > hidden, so users that are unaware of this change might have an hard > time to understand why services sometimes are not enabled by > runit-helper. (using the NEWS file in runit might help?) Sorry, don't follow. Previously no link in /etc/service was created if dh-runit decides that service should not be enabled, now hidden link is created instead. How it is more confusing? > * we need some user tool that allow to mark a service as wanted-disabled by > local admin: while patches for init-system-helpers are stuck I though about > update-service but: > - there is no 'status' or similar command that checks and report if there > is a .foo link > (maybe enhance the --list command or add a new --status ?) > - the change proposed in #942320 makes update-service a local-admin tool, > so packages > that still use it in maint scripts (like git-run) will become buggy, > probably the > maintainer deserves to be warned before change in update-service happens. What buggy behaviour will this change cause for git-run users? -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#942742: Simplify package rebuild with custom set of optional features
Source: apt-cacher-ng
Severity: wishlist
Tags: patch
Dear maintainer,
In effort to simplify creation and maintenance of derivate packages with
custom set of optional features disabled, here are patches that
enabling/disabling of optional feature is matter of changing exactly one
line in debian/rules.
Applied together, these patches do not alter default configuration (e.g
what is generated by dpkg-buildpackage) is any way, they just make
futher modifications simplier.
From 3dd03142350bbdf8b7b676f4d0663f1f5da4bed5 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Sat, 7 Sep 2019 22:13:12 +
Subject: [PATCH 1/2] Adjust build system to make systemd integration
configurable
---
...tem-to-make-systemd-integration-conf.patch | 39 +++
debian/patches/series | 1 +
2 files changed, 40 insertions(+)
diff --git
a/debian/patches/0002-Adjust-build-system-to-make-systemd-integration-conf.patch
b/debian/patches/0002-Adjust-build-system-to-make-systemd-integration-conf.patch
new file mode 100644
index 000..e5aaa0f
--- /dev/null
+++
b/debian/patches/0002-Adjust-build-system-to-make-systemd-integration-conf.patch
@@ -0,0 +1,39 @@
+From: Dmitry Bogatov
+Date: Sat, 7 Sep 2019 21:50:16 +
+Subject: Adjust build system to make systemd integration configurable
+
+Previously, systemd integration was built-in depending on whether
+libsystemd-dev was installed or not, without any option to configure it
+on per-package basis.
+
+With this change, systemd integration must be enabled explicitly
+with `WANT_SD_NOTIFY` variable.
+---
+ CMakeLists.txt | 7 +++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index adb8a7e..2eab8a2 100644
+--- a/CMakeLists.txt
b/CMakeLists.txt
+@@ -249,6 +249,8 @@ CHECK_CXX_SOURCE_COMPILES("${TESTSRC}" HAVE_PREAD)
+ FILE(READ test/build/HAVE_DAEMON.cc TESTSRC)
+ CHECK_CXX_SOURCE_COMPILES("${TESTSRC}" HAVE_DAEMON)
+
++if (WANT_SD_NOTIFY)
++
+ pkg_check_modules(lsd "libsystemd>=209")
+ # either part of the big library nowadays or in the helper library on older
systems
+ if(NOT lsd_FOUND)
+@@ -258,6 +260,11 @@ _append(CFLAGS_DAEMON ${lsd_CFLAGS})
+ _append(LDFLAGS_DAEMON ${lsd_LDFLAGS})
+ set(HAVE_SD_NOTIFY ${lsd_FOUND})
+
++if (NOT HAVE_SD_NOTIFY)
++message(FATAL_ERROR "Systemd integration is requested, but required library
is not found.")
++endif() # NOT HAVE_SD_NOTIFY
++endif() # WANT_SD_NOTIFY
++
+ SET(CMAKE_REQUIRED_FLAGS "${ACNG_COMPFLAGS} ${ACNG_CXXFLAGS}")
+ FILE(READ test/build/HAVE_MEMORY_SPTR.cc TESTSRC)
+ CHECK_CXX_SOURCE_COMPILES("${TESTSRC}" HAVE_MEMORY_SPTR)
diff --git a/debian/patches/series b/debian/patches/series
index 7bb8252..09a7f20 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
debian-changes
+0002-Adjust-build-system-to-make-systemd-integration-conf.patch
From e834fe321dcec1a1a8c54c70d6352c67f0e93cf2 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Sat, 7 Sep 2019 22:42:40 +
Subject: [PATCH 2/2] Build package with libsystemd by default
---
debian/config/systemd.mk | 3 +++
debian/rules | 3 ++-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/debian/config/systemd.mk b/debian/config/systemd.mk
new file mode 100644
index 000..d71fbb7
--- /dev/null
+++ b/debian/config/systemd.mk
@@ -0,0 +1,3 @@
+ifeq ($(DEB_HOST_ARCH_OS),linux)
+ EXTRA_LIBS += "-DWANT_SD_NOTIFY=yes"
+endif
diff --git a/debian/rules b/debian/rules
index d6fe850..eba829d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,4 +1,5 @@
#!/usr/bin/make -f
+include debian/config/systemd.mk
TGT=$(CURDIR)/debian/apt-cacher-ng
CDIR=$(TGT)/etc/apt-cacher-ng
@@ -15,7 +16,7 @@ DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
# libatomic provides 8-bytes atomic operation for 32-bit MIPS
ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
- EXTRA_LIBS="-DEXTRA_LIBS_ACNG=-latomic"
+ EXTRA_LIBS += "-DEXTRA_LIBS_ACNG=-latomic"
endif
%:
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Bug#911165: debian-policy: drop requirement to ship sysvinit init script with same name
[2018-10-17 16:42] Ian Jackson > Obviously when there are situations where providing an init script is > actually wrong (because under sysvinit or other systems the daemon is > started some other way), the init script should not be provided. > > In the existing text, this could be done as follows: > > | However, any package integrating with other init systems must also > | be backwards-compatible with sysvinit > > + | , usually > > | by providing a SysV-style init > | script with the same name as and equivalent functionality to any > | init-specific job Agreed. This way lintian check logic could be changed to following: * If package provides .service, it must provide /some/ init script, without checking for name. * If package provides .timer, it must provide /some/ cronttab. If for some reason it is not feasible (e.g service, designed by upstream to only run under systemd, then it is override). > As for the Russ's point about exact equivalence, that would be dealt > with by something like this: > > | script with the same name as and > > + | roughly > > | equivalent functionality to any > | init-specific job Second. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#942323: runit-helper: Use dot-symlinks to mark a service as disable
control: tags -1 +confirmed control: tags -1 -patch [2019-10-14 17:09] Lorenzo Puliti > there is a problem in runit-helper with the following logic > [..] > > if I remove (without purging) a package with version >= SINCE and then I > reinstall > such package, runit-helper will not enable the service. This is unexpected, > since > the local admin never tell that he/she wants to keep the service disabled > (and currently has no mean to do that). Good catch. I agree with your proposal. > I propose to use .service symlinks to mark a service as disabled > (directories starting with dots are ignored, this is already > documented in runsvdir(8) manpage). > I've documented this in update-service manpage (see #942320); maybe > this need also a 'POLICY' section in dh_runit(1) or a notice to users > of runit on upgrade? What are user-visible consequences for existing users? [ Added into CC for review Richard, who happened to have issues with unforeseen consequences and might see potential problems. ] > From: Lorenzo Puliti > Date: Thu, 10 Oct 2019 23:54:53 +0200 Can you please fix whitespaces and follow exiting conventions: use tabs? Right now patch simply does not apply, because I fixed whitespacing in your previous patch. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#942053: dh-runit: generates dangling symlinks
[2019-10-09 18:01] Sven Joachim > Package: dh-runit > Version: 2.8.14 > > The fix for bug #934500 has the side effect of introducing broken > symlinks[1] into packages using it, causing complaints by tools that > report such oddities, e.g. adequate(1) or symlinks(1): As I recall, dangling symlink is not violation of Policy (correct me if I am wrong), so the best route is to teach these tools about this special case, like we teach lintian. So, I think adequate(1) need to be patched. Something else? > I find that quite annoying. Sorry, this is not enough. Debian strives to be universal operating system, and pays the price for it: on every system there is something that is not needed for how this system is used. You can use dpkg-exclude to alleviate this particular issue somewhat. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#941924: runit-helper: Remove log directory on purge
control: tags -1 +pending [2019-10-07 17:50] Lorenzo Puliti > Hi, Hi, > I think runit-helper should remove log directories when > called with purge. See Debian Policy 10.8. > Patch attached. Yes, this is true. Thank you. Applied in git, not uploading yet due perl transition. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#556893: #556893,say which 'defaults' are which better
control: reassign -1 init-system-helpers
control: tags -1 +patch
[2019-09-28 15:21] Jesse Smith
> This has been addressed upstream in insserv by allowing the program to
> accept changes like this silently. All we need now is for update-rc.d to
> be updated to use the new behaviour (enabled with the -q flag) and this
> issue can be closed.
Thank you for bug triaging, Jesse. Reassigning back to
init-system-helpers.
Dear init-system-helpers maintainer, please consider applying following
patch:
From 638717158f50fa24a119b69ee0888158d306f492 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Sat, 12 Oct 2019 13:55:45 +
Subject: [PATCH] Prevent insserv(8) from printing too much debug
Closes: #556893
---
script/update-rc.d | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/script/update-rc.d b/script/update-rc.d
index 71fb1a6..03d21cf 100755
--- a/script/update-rc.d
+++ b/script/update-rc.d
@@ -181,7 +181,7 @@ sub create_sequence {
$insserv = "/sbin/insserv" if ( -x "/sbin/insserv");
# If insserv is not configured it is not fully installed
my $insserv_installed = -x $insserv && -e "/etc/insserv.conf";
-my @opts;
+my @opts = ('--silent');
push(@opts, '-f') if $force;
# Add force flag if initscripts is not installed
# This enables inistcripts-less systems to not fail when a facility is
missing
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Bug#941198: initscripts: packages should ship systemd units
[2019-09-28 18:02] Russ Allbery > Sean Whitton writes: > > > I don't currently have any reason to doubt we have a project consensus > > that systemd unit files should be included in packages in addition to > > sysvinit scripts, so I hope we can make this change. > > I agree. This seems entirely reasonable to me. Both the behavior and the > inherent documentation are better with unit files, and systemd is the > default init system so that's an advantage for a lot of our users. > > That said, if anyone does object to this, please do speak up and explain > why this would be a problem. Does it mean that lack of systemd unit file is RC-critical bug? Or I will be able to waive it with "you are welcome to contribute a patch" response? -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
[2019-09-28 10:04] Sean Whitton > Hello, > > On Sat 28 Sep 2019 at 04:18PM +00, Dmitry Bogatov wrote: > > > Reasonable. Then let's drop part about Depends: > > > > [ ... All packages with daemons must provide init.d scripts ...], > > unless software is only usable, by upstream's design, when > > pid1 is provided by some other init system. > > I think this would work. What do you think, David? > > Dmitry, perhaps you could work up a patch against policy.git. From 629b6fd334806e5389e3cfee44997d95ac96501c Mon Sep 17 00:00:00 2001 From: Dmitry Bogatov Date: Sun, 29 Sep 2019 18:53:36 + Subject: [PATCH] Policy: Allow missing init.d script for services, specific to other init Wording: Dmitry Bogatov Closes: #932704 --- policy/ch-opersys.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 3e685cf..309d6fe 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -1006,7 +1006,9 @@ supported by all init implementations. An exception to this rule is scripts or jobs provided by the init implementation itself; such jobs may be required for an implementation-specific equivalent of the ``/etc/rcS.d/`` scripts and may not have a one-to-one correspondence -with the init scripts. +with the init scripts. Another exception is when software is only +usable, by upstream's design, when pid1 is provided by some other init +system. .. _s-upstart: -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
[2019-09-28 08:11] Sean Whitton > Hello, > > On Wed 25 Sep 2019 at 03:43PM +00, Dmitry Bogatov wrote: > > >> Candidate language attached. It adds "Also excepted are packages which > >> require a > >> feature of an alternate init system which is not available in SysV-Style > >> init systems.". Thoughts? > > > > Imho, it opens loophole. > > [...] > > Okay, so what we want to express here is the idea that there is an > exception for a package which uses a feature of systemd, where something > equivalent cannot be achieved by using a sysvinit script? Such as > something to access the systemd dbus interface. > > I'm not sure how to express that right now, but I think it can be done. I believe I proposed wording for this down in this thread. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#941322: runit: bring back test about forced-rescan feature
Source: runit Version: 2.1.2-35 Severity: normal Dear Maintainer, do not forget to debug properly #941273 and make sure, that forced-rescan test works as expected on sbuild and salsa. pgp83W469Oy8G.pgp Description: PGP signature
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
[2019-09-26 17:48] Ansgar > On Thu, 2019-09-26 at 15:26 +0000, Dmitry Bogatov wrote: > > If this is the case, I'd propose wording like following: > > > > [ ... All packages with daemons must provide init.d scripts ...], > > unless software is only usable, by upstream's design, when pid1 is > > provided by some alternative init system. In such case, it must Depend > > on that alternative system (e.g binary package, that provides > > corresponding version of /sbin/init). > > Such a dependency shouldn't be added as one can run software in > containers or so and talk to the outside systemd instance. Note that > iptables doesn't depend on the linux kernel package either. Reasonable. Then let's drop part about Depends: [ ... All packages with daemons must provide init.d scripts ...], unless software is only usable, by upstream's design, when pid1 is provided by some other init system. > Also sysvinit would be an "alternative init system" given the current > default. As you wish. s/alternative/other/. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
[2019-09-25 18:18] Ansgar > Practically the project seems to have already > decided that this is fine, even for packages that don't require > systemd: > > +--- > | There are 1033 non-overridden instances of lintian detecting a > | service unit without an init.d script [7]. > +---[ https://lists.debian.org/debian-devel-announce/2019/09/msg1.html ] I believe it partially my fault in this mis-representation. Yes, problem exists (and it is severe), but not as severe like 1033 out of 1300 daemons missing init.d scripts. This lintian check have number of false-positives, like `foo@.service` files triggering complains about missing `/etc/init.d/foo@` scripts, and sometimes names plainly do not match (e.g bin:ifupdown). -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
[2019-09-25 11:50] David Steele > On Wed, Sep 25, 2019 at 11:43 AM Dmitry Bogatov wrote: > > > > > > [2019-09-22 16:13] David Steele > > > Candidate language attached. It adds "Also excepted are packages which > > > require a > > > feature of an alternate init system which is not available in SysV-Style > > > init systems.". Thoughts? > > > > Imho, it opens loophole. > > [...]> > I'm just looking to avoid the scenario where I add systemctl calls to > an init script, for a package that uses the systemd D-Bus interface. > Alternate language is solicited. systemctl calls in init.d scripts? I do not understand. What software we are talking about? What does it mean "uses systemd D-Bus interface"? Does it mean that it can't do what it is supposed to do when pid1 != systemd? If this is the case, I'd propose wording like following: [ ... All packages with daemons must provide init.d scripts ...], unless software is only usable, by upstream's design, when pid1 is provided by some alternative init system. In such case, it must Depend on that alternative system (e.g binary package, that provides corresponding version of /sbin/init). -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#939971: runit: Export NAME and add a VERBOSE option to invoke-run
Control: tags -1 +pending [2019-09-25 01:01] Lorenzo Puliti > Package: runit > Followup-For: Bug #939971 > > > What is missing is documentation > > ... > > I think you want to source /etc/default/runit *before* > > /etc/default/service. > > updated patch is attached Looks good, applied. Thanks. Just minor nit: please add 'Closes: #n' to commit message, if you know it (like this case, when this is second version of patch). Makes regeneration of changelog simplier. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
[2019-09-22 16:13] David Steele
> On Tue, Jul 23, 2019 at 2:10 PM Sean Whitton wrote:
> >
> > The Policy Editors have decided that dropping the requirement to ship
> > init scripts is not something that can be decided by means of the Policy
> > Changes Process, at least for the time being.
> >
> > In proposing and reviewing wording to resolve this bug, then, we should
> > be careful not to weaken the requirement to ship init scripts.
> > Otherwise, in resolving this bug we would be changing the requirements
> > to ship init scripts by means of the Policy Changes Process.
> >
> > I'm suggesting this be kept in mind. It need not result in a wordier
> > change, and I certainly agree with you that we should assume good faith
> > on the part of package maintainers.
> >
>
> Candidate language attached. It adds "Also excepted are packages which
> require a
> feature of an alternate init system which is not available in SysV-Style
> init systems.". Thoughts?
Imho, it opens loophole. Sysvinit does not provide equivalent of
sd_notify("SD_READY=1"), so any service that links to libsystemd for
that exactly call can be argued as "requiring feature [...] which is not
available [...]".
As real life example I recall Avahi-related bug (can't find number right
now, sorry). Two inter-dependent services, where second fails to start
unless first is already ready to listen.
I'd argue this is bug in design, but if we consider design is written in
stone, this is a bug in init.d script that must be worked around
somehow.
With your change in place, avahi maintainers would be able to drop
sysvinit support instead of fixing init.d script.
Very strong -1.
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Bug#941140: lintian: init.d-script-depends-on-all-virtual-facility is too harsh
Package: lintian Version: 2.17.0 Severity: wishlist Dear Maintainer, please make description of this tag somewhat less harsh. Using several scripts with dependency on $all works (as confirmed in #935302 by upstream maintainer), but should be used sparingly, since no ordering between such scripts is promised. I propose to whitelist src:sysvinit in regards of this tag, and reword like following: The given init script declares a dependency on the virtual facility "$all". This virtual facility is reserved for very special cases, that work specifically with init system. Regular services must not use this facility. pgpEeSAmF_pGU.pgp Description: PGP signature
Bug#933078: runit: forced-rescan feature
[2019-09-13 15:18] Dmitry Bogatov > > [ Lorenzo Puliti ] > > So there is still a lag of 1.5 seconds from the moment runsvdir > > detects a new directory and the moment the runsv process create the ok > > pipe. Also, i'm afraid this lag may be affected from the filesystem > > type and the hardware, so i need to keep a workaround like (1) in > > place. I'm waiting to test with a service that links the supervise > > directory into run (there is none currently), maybe it helps? Any > > hope to further reducing this lag? > > ... but 1.5 seconds to definitely too much. I hope to take a look and > make more accurate testing on this, but my AFK life got quite > distracting recently. I found source of delay (sleep(1)) and reduced failure threhold in src/t/runtest.sh. Please find patches in wip2 branch (ca08d0a) and tell, whether they solve issue. Still there will be delay: ~11769034 nanoseconds (or 0.12 sec) on my computer on test suite, your mileage may vary depending on number of factors. So, probably you will need to watch to updates of /etc/service/.forced-rescan or wait till control pipe appears. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#927254: closed by Xavier Guimard (Bug#927254: fixed in vue-router.js 3.0.7+ds-1)
[2019-07-18 21:10] Xavier > > control: reopen -1 > > control: tags -1 -pending > > > > [2019-07-10 19:39] "Debian Bug Tracking System" > >> This is an automatic notification regarding your Bug report > >> which was filed against the libjs-vue-router package: > >> > >> #927254: libjs-vue-router: ships node module instead of browser one > >> > >> It has been closed by Xavier Guimard . > > > > It did not solve my problem. Package libjs-vue-router still provides files > > in /usr/share/nodejs: > > [...] > Hello, Hello. Sorry for late response, I somehow missed your mail. > I embedded path-to-regexp in build > (https://salsa.debian.org/js-team/vue-router.js/commit/65478a93), now > difference with upstream build is minimal. Could you try this (with > vue-router.js built from https://salsa.debian.org/js-team/vue-router.js) ? It does not build for me. Neither it builds on Salsa CI (I added debian/.gitlab-ci.yml on branch `wip'). https://salsa.debian.org/js-team/vue-router.js/-/jobs/321533 -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#933078: runit: forced-rescan feature
[2019-09-11 00:34] Lorenzo Puliti
> Package: runit
> Version: 2.1.2-34
> Followup-For: Bug #933078
>
> >> `kill -14 1`
> >
> > Fire-and-forget -- yes.
>
> I'm doing some live testing on my box before sending a refreshed patch
> to init-system-helpers maintainers: sadly this is not working as I expect.
>
> I've added a runit-force-rescan sub to update-rc.d
>
> sub runit_force_rescan {
> if (-f "/run/runit.stopit") {
> system("kill", "-14", "1");
> system("sleep", "1.5");
> }
> }
>
> and without the `sleep 1.5` i'm still running into
> an error on postinst stage (example with openssh-server)
When pid1 receives sigalarm, it forwards it to stage2 process, which,
in case of runsvdir, does what it usually does if 5 seconds are expired
*and* /etc/service directory is modified. After it is done, it writes
/etc/service/.forced-rescan.
Seems I was inaccurate in my wording -- you can't just send signal and
expect rescan to happen instantly,...
> So there is still a lag of 1.5 seconds from the moment runsvdir
> detects a new directory and the moment the runsv process create the ok
> pipe. Also, i'm afraid this lag may be affected from the filesystem
> type and the hardware, so i need to keep a workaround like (1) in
> place. I'm waiting to test with a service that links the supervise
> directory into run (there is none currently), maybe it helps? Any
> hope to further reducing this lag?
... but 1.5 seconds to definitely too much. I hope to take a look and
make more accurate testing on this, but my AFK life got quite
distracting recently.
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
pgpQzvHWWJQ8Y.pgp
Description: PGP signature
Bug#939971: runit: Export NAME and add a VERBOSE option to invoke-run
control: tags -1 +confirmend +moreinfo
[2019-09-10 17:09] Lorenzo Puliti
> Package: runit
> Version: 2.1.2-34
> Severity: normal
> Tags: patch
>
> Hi,
> as discussed in #935958 it's inconvenient to print messages like
> 'starting foo' or 'stopping foo' by default, as they are written to
> the service log.
>
> The attached patch does the following:
> * add support for a VERBOSE option to invoke run: the
> value is sourced from /etc/default/runit file
> (off by default) and can be overridden for each service
> placing a file in /etc/sv//conf/
>
> * export the NAME variable in invoke-run
>
> * add a system-wide file to be sourced for runit services
>
> the verbose option should be tested in runscripts like
>
> if [ "$VERBOSE" = 1 ]; then
> echo "runsv: starting $NAME..."
> fi
>
> I'm not sure using /etc/default path (rather than /etc/runit) is
> appropriate; file there are usually meant for daemons but there are
> exceptions (I have a Grub directory there).
I think /etc/default it is fine.
What is missing is documentation. invoke-run(5) should mention that NAME
is exported and /etc/default/runit is sourced.
> debsums: changed file /lib/runit/invoke-run (from runit package)
> part 2 text/plain1579
> >From 354706b5eac44d35814eb584c1b0272995f441ff Mon Sep 17 00:00:00 2001
> From: Lorenzo Puliti
> Date: Tue, 10 Sep 2019 16:31:53 +0200
> Subject: [PATCH] invoke-run: add verbose option and export NAME
> [...]
> diff --git a/debian/contrib/lib/invoke-run b/debian/contrib/lib/invoke-run
> index b3b0c55..b0f6ef6 100755
> --- a/debian/contrib/lib/invoke-run
> +++ b/debian/contrib/lib/invoke-run
> @@ -31,6 +31,8 @@ case "${runscript}" in
> esac
> readonly runscript service
>
> +export NAME=$service
> +
> if [ -f "/etc/sv/${service}/.meta/installed" ] ; then
> readonly installed="/usr/share/runit/meta/${service}/installed"
> # uninstalled, but not purged. See #929693 and commit [4c485b]
> @@ -49,6 +51,12 @@ if [ -r "/etc/default/${service}" ] ; then
> set +a -u
> fi
>
> +if [ -r /etc/default/runit ]; then
> +set -a
> +. /etc/default/runit
> +set +a
> +fi
I think you want to source /etc/default/runit *before*
/etc/default/service.
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Bug#939733: lsb-release: lsb_release does not show point release on Debian 10.1
control: severity -1 +normal [2019-09-10 10:21] Jonathan Wiltshire > >> The x.y there was a remnant from Debian sarge times. > > > > Up until squeeze I have seen it show x.y.z, then from wheezy to > > stretch I see only x.y, but it does seem new behaviour in buster to > > only show x. > > > > $ ansible '*' -i inventories/testing -a 'lsb_release -d' | grep ^Descr | > > sort -u > > Description:Debian GNU/Linux 10 (buster) > > Description:Debian GNU/Linux 8.11 (jessie) > > Description:Debian GNU/Linux 9.10 (stretch) > > This stems from lsb_release switching to reading the cross-distro > standard file, /usr/lib/os-release: > > | $ cat /etc/debian_version > | 10.1 > | $ cat /usr/lib/os-release > | PRETTY_NAME="Debian GNU/Linux 10 (buster)" > | NAME="Debian GNU/Linux" > | VERSION_ID="10" > | VERSION="10 (buster)" As pointed by maintainer of base-files, this format of /usr/lib/os-release is with us for some time (just checked on stretch box). In theory, I can revert #914287, but is it good thing? Actually, I fail to see the whole point of `lsb_release` command. You can't squash all information in your /etc/apt/sources.list into two digits. This said, I feel current behaviour more logical. LSB pretends to provide cross-distributions interface, so reading /usr/lib/os-release feels more natural than /etc/debian_release. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#935607: lintian: classify "Starting $DESC" in init.d scripts
control: tags -1 -moreinfo [2019-09-08 21:26] "Chris Lamb" > > unwanted and to be fixed. > > ... but, unless I'm missing something you can surely do that now > almost trivially using codesearch.debian.net and certainly much > quicker, independetly and with less hassle than introducing two new > Lintian tags, etc. > > I thus suggest you do that and come back to this bug when you/we have > a concrete implementation plan. I should have thought about it myself. Codesearch gives following result: 1. search for literal `Starting $DESC' gives three pages of init scripts. Majority (but not overwhelming, around 2/3) of them do /not/ check for $VERBOSE. Not very representative, given there is ~1300 services in Debian. 2. search for `log_daemon_msg "Starting' gives 85 pages, with around 2/3 (eyeball estimate) not checking for $VERBOSE. This search covers 850 init scripts, which is rather good part. 3. search for literal `"Starting ' gives hundred of pages, most of them false-positive (logging in C code). Not unanimous, but I believe that *checking* for $VERBOSE should be marked as deprecated. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#938952: [debian Buster] [arm64 pinebook] [sysvinit-core] libsoup2.4-1 : Depends: glib-networking (>= 2.32.0) but it is not going to be installed
[2019-09-08 17:53] Jean-Marc LACROIX > > Please: > > > > * Try installing something else, like `tor'. I expect you will get > > similar error (`tor' depends on libsystemd0, sigh) > > ansible@pinebook:~$ sudo apt install tor > [...] Okay, tor installs fine with your apt-pinning. My guess was wrong. > ansible@pinebook:~$ dpkg -l |grep -v ii > Desired=Unknown/Install/Remove/Purge/Hold > | > Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ NameVersion > Architecture Description > +++-===---=== > > ansible@pinebook:~$ dpkg -l |grep systemd > ii dbus-user-session > 1.12.16-1arm64simple interprocess messaging > system (systemd --user integration) > ii libpam-systemd:arm64241-5 > arm64system and service manager - PAM module > ii libsystemd0:arm64 241-5 > arm64systemd utility library > ii syslog-ng-mod-journal 3.19.1-5 > arm64Enhanced system logging daemon > (systemd journal plugin) > ii systemd 241-5 > arm64system and service manager > ii systemd-sysv241-5 > arm64system and service manager - SysV links Okay, on this stage you have systemd as pid1 implementation. > [...] > Now, according Debian doc, i try to install sysvinit Which exactly doc? I guess it needs to be adjusted. > ansible@pinebook:~$ sudo apt install sysvinit sysvinit-utils > Reading package lists... Done > Building dependency tree > Reading state information... Done > Package sysvinit is not available, but is referred to by another package. > This may mean that the package is missing, has been obsoleted, or > is only available from another source > However the following packages replace it: >sysvinit-core:armhf systemd-sysv:armhf sysvinit-core systemd-sysv > > E: Package 'sysvinit' has no installation candidate > > It seems on Debian 10.1, there is now one new package name ? > [...] There were no package renaming at least last year. > ansible@pinebook:~$ sudo apt install sysvinit-core sysvinit-utils > Reading package lists... Done > Building dependency tree > Reading state information... Done > sysvinit-utils is already the newest version (2.93-8). > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > dconf-service : Depends: default-dbus-session-bus or >dbus-session-bus > libsoup2.4-1 : Depends: glib-networking (>= 2.32.0) but it is not > going to be installed > E: Error, pkgProblemResolver::Resolve generated breaks, this may be > caused by held packages. Wait, do you have installation of "recommends" disabled? If I try to install "dconf-service" on my system (antiX + Devuan + Debian, pid1=runit-init), I too get resolution error, but # apt-get install dconf-service --no-install-recommends resolves fine. Please, try this. Otherwise, your better bet would be to reassign to libelogind or dbus or something like this. sysvinit-core only depends on libc and libselinux (sigh), so it can't cause conflicts with packages you show. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#939944: dput: make chown 0644 optional
Package: dput
Version: 1.0.3
Severity: wishlist
Dear Maintainer,
Today I spent some time debugging why upload to my private server get
0644 permissions, no matter how I change permissions of built packages
and no matter how I tweak umask on both sending and receiving hosts.
Problem is following code (scp.py:53)
if change_mode:
fix_command = ['ssh']
for anopt in ssh_config_options:
fix_command += ['-o', anopt]
fix_command += [
'%s%s' % (login_spec, fqdn), 'chmod', '0644'
] + files_to_fix
if debug:
sys.stdout.write("D: Fixing some permissions\n")
sys.stdout.write("D: %s\n" % fix_command)
exit_status = dputhelper.check_call(fix_command)
if exit_status != dputhelper.EXIT_STATUS_SUCCESS:
sys.stdout.write("Error while fixing permissions.\n")
sys.exit(1)
Please, make this behavior optional. It is not documented (or I failed
spectacularly at finding documentation), causes major headache when I
need files to have another (664) permissions and makes `dput` report
error, if remote host allows scp/rsync execution, but not arbitrary
commands.
pgp3XzRhiyUkF.pgp
Description: PGP signature
Bug#924505: bash: set shell to /bin/sh on removal
[2019-09-03 17:36] Matthias Klose > On 02.09.19 21:14, Dmitry Bogatov wrote: > > Subject: [PATCH] Change shells of users from /bin/bash to /bin/sh on removal > > sorry for joining in lately into this game, but I didn't want to do that in > parallel with my other Debian tasks. > I don't like the idea of automatic shell rewriting, and will revert it > with the next regular upload. No need. I cancelled NMU due other issues. > For user accounts it potentially creates broken init files, because > the user's init files might use bashisms. Then you are lucky. System administrator could have uninstalled your shell. > The same might be true for system accounts, although you can > manually check if these accounts use bashisms. Nobody is hurt by > having bash installed, you can avoid that for new installations, You can't. It is essential. Making it possible to strip essential flag from bash is goal of whole game. > so this change doesn't seem to have any benefit which out weights the > regression potential. There also isn't any precedence for other > shells doing that. None other shells are essential, and none of them are used by default for root user. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#924505: [Pkg-shadow-devel] Bug#924505: bash: set shell to /bin/sh on removal
[2019-09-03 22:21] Chris Hofstaedtler > * Matthias Klose [190903 17:37]: > > On 02.09.19 21:14, Dmitry Bogatov wrote: > > > Subject: [PATCH] Change shells of users from /bin/bash to /bin/sh on > > > removal > > > > sorry for joining in lately into this game, but I didn't want to do that in > > parallel with my other Debian tasks. > > > > I don't like the idea of automatic shell rewriting, [..] > > For user accounts it potentially creates broken > > init files, because the user's init files might use bashisms. The same might > > be true for system accounts, although you can manually check if these > > accounts use bashisms. Nobody is hurt by having bash installed, you can > > avoid that for new installations, so this change doesn't seem to have any > > benefit which out weights the regression potential. There also isn't any > > precedence for other shells doing that. > > I also don't understand what the point of the whole exercise is; Point of whole excersise is strip bash of essential flag. > once you have user accounts that use bash, they should just stay as > they were. If so, removing bash, once it is no longer essencial, will break default installation where root shell is bash. This is not how uninstallation is intended to work. > For new systems, defaulting to dash might be useful. No. Firstly, many would object this change. Secondly, it does not solve initial problem. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#934231: anacron: please provide a runscript for runit
[2019-09-04 19:30] Lorenzo Puliti > Package: anacron > Version: 2.3-29 > Followup-For: Bug #934231 > > Hi, Hi, > I have updated the patches and the MR: > First patch adds Gtilab CI test and include a test for the runscript > > https://salsa.debian.org/Lorenzo.ru.g-guest/anacron/pipelines/69420 > > The second one, compared to the previuos version, adds the following: > * bump dh-runit version to 2.8.14 in Build-depends > * add presubj option for dh-runit > * slightly reword the echo messages in run and finish files I see all test jobs pass, not just `daemons'. Great! > create mode 100644 debian/anacron.runscript/finish There is nothing in this script specific to anacron. I propose following: * add this finish script into bin:runit as /lib/runit/finish-default or something like this. * document error codes (161, 160, -1, etc) in invoke-run manpage. * modify dh_runit to generate finish script with following content: #!/bin/sh /lib/runit/finish-default Not sure should it be default or yet-another option. This is more work initially, but will make improvements to finish script transparent (just upgrade bin:runit), should need appear and avoid copy-paste work for future runscripts. FWIW, every time I thought "there will be no need to change ", I was wrong. > diff --git a/debian/anacron.runscript/run b/debian/anacron.runscript/run > new file mode 100644 > index 000..dcfb16d > --- /dev/null > +++ b/debian/anacron.runscript/run > @@ -0,0 +1,21 @@ > +#!/usr/bin/env /lib/runit/invoke-run > +set -e > + > +NAME=Anacron > + > +exec 2>&1 > + > +# exit status of on_ac_power: > +# 0= on-ac // 1= on-battery // 255=unknown, likely a desktop witout APM > +if [ x"$ANACRON_RUN_ON_BATTERY_POWER" != x"yes" -a -x /usr/bin/on_ac_power > ]; then $ man test advices aganist use of `-a` option: NOTE: Binary -a and -o are inherently ambiguous. Use 'test EXPR1 && test EXPR2' or 'test EXPR1 || test EXPR2' instead. > +/usr/bin/on_ac_power || retval=$? Minor style issue. Trailing whitespace. You may want to enable default git pre-commit hook, which catches such issues. > +if [ x"$retval" = x1 ]; then > +echo "deferred while on battery power" && exit 161 > +fi > +fi > + > +# don't restart anacron when it's done Why? Will it work correctly on machine that is up for 24/7? > index 9a38b23..fc5e3ed 100644 > --- a/debian/control > +++ b/debian/control > @@ -3,6 +3,7 @@ Section: admin > Priority: optional > Build-Depends: > debhelper-compat (= 12), > + dh-runit(>=2.8.14), Minor style issue. Please keep spacing consistent, like foo (>= 1.2.3-4~5) -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#933078: runit: forced-rescan feature
[2019-09-06 14:54] Lorenzo Puliti > Package: runit > Version: 2.1.2-34 > Followup-For: Bug #933078 > > Hi, > just to be sure, with this patch all I need to do > in order to force a rescan is > > `kill -14 1` Fire-and-forget -- yes. With this patch I plan to bundle symlink /etc/service/.forced-rescan to somewhere under /run, so to wait for rescan to finish, you'd have to watch target of this symlink. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#939631: mark dh-runit Multi-Arch: foreign
control: tags -1 +pending [2019-09-07 08:22] Helmut Grohne > Package: dh-runit > Version: 2.8.14 > Tags: patch > User: debian-cr...@lists.debian.org > Usertags: cross-satisfiability > Control: affects -1 + src:acpid src:bcron src:irqbalance src:openssh > src:runit src:tor > > The affected packages fail to satisfy their cross Build-Depends, because > their dependency on dh-runit is unsatisfiable. In general, Architecture: > all packages can never satisfy cross Build-Depends unless marked > Multi-Arch: foreign or annotated :native. In this case, it seems like > dh-runit's operation is not influenced by which native arch it is run > on. That makes it a good candidate for a Multi-Arch: foreign marking. > Please consider applying the attached patch. Thank you. I applied your patch in Git, will appear in next upload. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#938964: please don't install runit-helper on everyone's system
[2019-09-04 07:10] Noah Meyerhans
> On Sun, Sep 01, 2019 at 09:38:36PM +0800, Shengjing Zhu wrote:
> > > Just for my curiosity (not going to happen in my watch), would you be
> > > happier if `runit-helper` script was part of init-system-helpers (which
> > > is essential, anyway).
> >
> > I'm not sure why you didn't chose this at first. As it calls itself
> > "helper tools for all init systems".
> > I'm not saying I'm happy with init-system-helpers, but this already
> > exists for long and looks better.
> I think unifying the functionality of this package with
> init-system-helpers would be preferable.
Only if you (or someone else) volonteer to be the ambassador.
> But beyond just polluting the package namespace, I'm a bit annoyed by
> the stuff that this package leaves around the filesystem as well. In
> particular, /var/log/runit shouldn't exist on systems that don't even
> have runit installed. /etc/runit is similarly annoying.
If it does not clean after purge -- please report. It is important bug.
But otherwise, sorry, Debian is not Gentoo. We do have useless
files, packages, directories and even shared libraries around. This is
how things always were. E.g:
* /etc/init.d/*
* /etc/systemd
* /var/lib/systemd
* udev
* libsystemd0
* libselinux
* apparmor
* libblkid
* doc-base
Well, maybe you are using some (or even most) of these, but it is not
the point. Wait, you can't use both apparmor and selinux.
> I think it'd be worthwhile to come up with a slightly more
> sophisticated mechanism for populating runit configuration on systems
> that actually need such configuration, while also eliminating noise on
> systems that don't need it.
This configuration system already exists, and is not tied to runit in
any way. It is called `dpkg --exclude`. So much on unwanted /etc/*
files.
But on package dependencies, you can't just remove `runit-helper` due
hard dependency, that is true. I find it (unlike files in /etc) real
problem. But I do not know solution.
I can relax relation to recommends, and change maintainer script to use
`runit-helper` only if it is installed. In such case, everything will be
fine as long as you do not try to boot with init=/lib/runit/runit-init
(or install runit-init).
And if you do, whether things will work out-of-box or you will end only
with tty1-6 depends on whether `runit-helper` was present when you
installed your services. Actually, it can be something in between.
I hope to reduce amount of code in `runit-helper`, so eventually it can
be reasonably embedded directly into maintainer script. But not today.
> I'm happy to create a separate bug for the filesystem issues if you'd
> like to track them separately from the package name issues.
I am fine discussing it here.
By the way, initially I wanted to ship runscripts for services in
separate packages. This approach was reject by both FTP masters and
discussion on `debian-devel'. Somewhy there is strong opposition to tiny
packages.
Given this and establilished practice of including both systemd service
files and sysvinit init scripts (mandated by Policy) into main package,
I was given no choice.
In ideal world, there would be {foo}-bin, {foo}-systemd, {foo}-sysvinit,
{foo}-run and metapackage {foo}, that depends on everything mentioned
before. Unlikely to happen.
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Bug#938964: please don't install runit-helper on everyone's system
[2019-09-01 21:38] Shengjing Zhu > On Sun, Sep 1, 2019 at 9:23 PM Dmitry Bogatov wrote: > > Just for my curiosity (not going to happen in my watch), would you be > > happier if `runit-helper` script was part of init-system-helpers (which > > is essential, anyway). > I'm not sure why you didn't chose this at first. As it calls itself > "helper tools for all init systems". It calls, yeah. Package: init-system-helpers Maintainer: Debian systemd Maintainers -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#719692: Make run-parts useful for running hook scripts
control: tags -1 +patch [2019-08-19 11:28] Dmitry Bogatov > [2019-08-16 17:35] Clint Adams > > On Thu, Aug 15, 2019 at 09:24:46PM +0000, Dmitry Bogatov wrote: > > > I want this feature too. Dear maintainer, are you interested? Will you > > > accept patch? > > > > Sure. Would you read all of stdin into memory or would you > > do something else? > > I use temporary file. Do you foresee problems with it? Here is patch. > Note, it uses Linux-only (I believe) O_TMPFILE. I can make it > posix-compliant if you want. > [...] Ping? -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#924505: bash: set shell to /bin/sh on removal
[2019-09-01 07:38] Niels Thykier
> > > [2019-03-13 17:17] Dmitry Bogatov
> > > > Package: bash
> > > > Version: 5.0-2
> > > > Severity: wishlist
> > > >
> > > > Dear Maintainer,
> > > >
> > > > To contribute to efford of of making bash non-essential, I propose
> > > > following patch, that should resolve issue with login #620898 (in CC).
> > > > [...]
>
> Hi Dmitry,
>
> It is my belief that the change would be a severe regression when
> applied to deconfigure and I request that you cancel/update your NMU to
> avoid breaking system configuration during upgrades.
>
> (Note: I am not commenting on the entire change - only the deconfigure
> part).
> [...]
Niels, thank you for warning. I canceled upload. I considered another
version of this patch (on bottom), but it have same flaw --
remove-install cycle is supposed to preserve configuration.
Bringing back into thread #620898.
Dear maintainer of `login`, idea of changing /etc/passwd in bash
maintainer script failed. As previously discussed, spawning /bin/sh when
user's shell not found is security hole, but what about patch that
checks specifically for this case:
* if user=root
* if shell=/bin/bash
* if /bin/bash is missing
* then spawn(/bin/sh) // instead of "file not found" error.
What do you think? Will you apply such patch?
From ae1c74362a5d005766f40b6e19cdbf1621fd197c Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Sun, 1 Sep 2019 14:03:55 +
Subject: [PATCH] Change shells of users from /bin/bash to /bin/sh on removal
Closes: #924505
---
debian/bash.prerm | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/debian/bash.prerm b/debian/bash.prerm
index 52052a2..a54a2da 100644
--- a/debian/bash.prerm
+++ b/debian/bash.prerm
@@ -8,7 +8,14 @@ case "$1" in
/usr/share/man/man7/bash-builtins.7.gz
;;
-remove|deconfigure)
+ deconfigure)
+ ;;
+
+ remove|purge)
+ remove-shell /bin/bash
+ for user in $(awk -F: '$7 == "/bin/bash" { print $1 }' /etc/passwd) ; do
+ usermod -s /bin/sh "${user}"
+ done
;;
failed-upgrade)
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Bug#939132: lintian-brush: please add bash-autocompletion
Package: lintian-brush Version: 0.26 Severity: wishlist Dear Maintainer, lintian-brush provides 12 options (beside help/version), and it becomes quite hard to type. Please provide bash completion for Bash shell users, and one-letter options for users of shells without programmable completion. I suggest following one-letter options, for similarity with other programs: --directory = -C (make) --dry-run = -n (make) (not sure about order) --list-fixers = -l --list-tags = -L --verbose = -v I do not have any suggestions about single-letters for other options, I trust your judgement. PS. There is library on creating bash-completion automatically from argparse [1], but I expect it to work slow. https://github.com/kislyuk/argcomplete -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients. pgph6QNXTJ0Au.pgp Description: PGP signature
Bug#939130: RFA - fbless: console fb2 reader
Package: wnpp Severity: wishlist Here I am looking for new maintainer for 'fbless' -- the only console fb2 reader in Debian Archives. Upstream is dead, but software works fine. Originally it is written in Python2, but I just made upload with patch to convert it to work with python3 (#936506). This package did not require much work in past, and I do not expect it to take much effort in future, but if you want to take role of upstream developer -- I welcome you to take role of Debian maintainer too. Description-en: terminal fiction book reader Fbless is ncurses fiction book (.fb2) reader with following features: . * customizable color themes * last viewed point saving * autoscroll mode * support for archived books * basic links support -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients. pgpatjcplx_nC.pgp Description: PGP signature
Bug#935991: dh-runit: please avoid excessive/dangerous chown/chmod
[2019-08-29 12:23] Daniel Kahn Gillmor > > Then I plan to change script to following: > > > > 1 #!/bin/sh > > 2 chown runit-log:adm '/var/log/runit/tor' > > 3 chmod 750 '/var/log/runit/tor' > > 4 umask 0022 > > 5 exec chpst -u runit-log svlogd -tt '/var/log/runit/tor' > > > > The idea is that since /var/log/runit/tor is 750, log files actually can > > only be read by group=adm, even though their permission is 644. > > This looks reasonable and correct to me. I think you can even omit the > "umask 0022" part on line 4: svlogd uses openat() to open its "current" > file with mode 0600 initially, so there's no race condition that leaves > a window where the "current" file will get automatically opened with > too-loose permissions. Okay. Will do. > Looking at svlogd, it appears that after opening, it deliberately uses > fchmod() to set the mode of "current" to 0644 (and it also sets the > rotated-out file to 0755 at rotation time, i don't know why rotated-out > files are marked executable!). Subject: svlogd, when rotating, sets the log files as executable. Why? From: Jamie Heilman <> Date: Mon, 8 Feb 2016 06:12:27 + This is all based off daemontools' multilog ... https://cr.yp.to/daemontools/multilog.html ... which states: While multilog is running, current has mode 644. If multilog sees the end of stdin, it writes current safely to disk, and sets the mode of current to 744. When it restarts, it sets the mode of current back to 644 and continues writing new lines. When multilog decides that current is big enough, it writes current safely to disk, sets the mode of current to 744, and renames current as an old log file. Thus it's effectively using the mode bits as flag to communicate the state of the application, which while unusual, is harmless. > > Is it okay? Or it opens door for some other tricks, that would allow log > > reading by non :adm users? Or some other problems? > > i don't see any other problems with it! while that doesn't mean it's > problem-free, i think it's an improvement :) Good. How urgent is fix? Can I just upload `dh-runit' into unstable and eventually fix will propagate to affected packages, or I have to request binNMU? -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#938968: dh-runit: namespace pollution in maintainer scripts
control: tags -1 +confirmed +pending [2019-08-30 18:22] Sven Joachim > Package: dh-runit > Version: 2.8.13.2 > > The dh-runit helper exports the NAME, ENABLE and SINCE variables from > the maintainer script. These variable names are very generic and could > potentially be used by other scripts called from the maintainer script. > > I guess you are stuck to support these variables in runit-helper for > current maintscripts, but consider giving them a suitable prefix in > future releases. I believe, I can define these variables just for one command, like: NAME='#NAME#' /lib/runit-helper/runit-helper Is it acceptable solution? -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#938952: [debian Buster] [arm64 pinebook] [sysvinit-core] libsoup2.4-1 : Depends: glib-networking (>= 2.32.0) but it is not going to be installed
control: tags -1 +moreinfo [2019-08-30 16:44] Jean-Marc LACROIX > Package: sysvinit > Version: 2.93-8 > Severity: grave > > Dear maintainers, > > It seems there is a dependency issue when installing sysvinit-core as > indicated in following trace > [...] > Package: *systemd* > Pin: release * > Pin-Priority: -1 I think problem is here. *systemd* matches `libsystemd0`, and given that even apt depends on `libsystemd0`, you are unlikely to solve any dependency. Please: * Try installing something else, like `tor'. I expect you will get similar error (`tor' depends on libsystemd0, sigh) * Replace `*systemd*' with `systemd' (without wildcard) in your apt-pinnings and try installing sysvinit-core again. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#935958: runit: Tools to help generating runscripts
[2019-08-30 02:11] Lorenzo Puliti
> > But before patch can be submitted to maintainer, automatic testing is
> > must. I suggest salsa.debian.org/kaction/daemons.
>
> Is there any instruction on how to use it?
Sure. Here is how I did it for Tor:
https://salsa.debian.org/kaction/tor-runscript/commit/460ad44c8046fd91baf053b44ec6ce3d5215753d
Key point is this line in .gitlab-ci.yml:
include:
- https://salsa.debian.org/kaction/daemons/raw/master/pipeline.yml
So you import package on Salsa (or just fork, but Tor does not use
Salsa), add CI, add runscript and tweak it until `daemons` job pass.
Note of warning: tests are run in Docker, not in full virtual machine,
so at least netlink sockets do not work. Maybe you will discover some
other limitations :)
Albeit non-ideal, this CI caught my stupid error, when I forgot to
create /run/tor in runscript, because it worked on my box.
> >> Do I need to 'set -e' in run script, or it's inherited from invoke-run?
> > No, it is not. Do you think invoke-run should?
> Mmm, I don't have an strong opinion on that, I think it's fine as it is now.
Okay. Let's leave it as-is.
> > * please do not print "Starting $NAME". It goes to log, quite
> > pointless and may confuse scripts/tools that want to analyze log.
>
> I know it goes to log, that was exactly my idea but i didn't thought about
> scripts that want to analyze logs.
> Runit is absolutely mute and in some case it's hard for me to understand
> what is wrong with a service. For example, if in the log there is no
> `Starting NAME` message i know something is wrong with the run file;
> if i see a stream of `starting NAME Stopping NAME` i know there is
> some permanent failure condition. I'm not sure I will be able to help in
> solving bug that users will send about runit services without those
> markers. Maybe I can change the message into something less confusing
> like `runsv: starting NAME` and `runsv: NAME stopped` ?
I have two ideas:
* Check for $VERBOSE variable. If you have issues with services {foo},
you can
# mkdir -p /etc/sv/foo/conf
# echo 1 > /et/sv/foo/conf/VERBOSE
* You can write to /dev/tty63 (or some other unused tty). It is hard to
copy-paste from there, though.
Either way, 'runsv:' is improvement, imho.
> > PS. You know that I already got runscript into src:tor and src:acpid?
>
> yes I've noticed that :)
> I've send a couple of patches too and have few others
> ready (but those need the fix for #934173).
> Maybe you can help with Anacron? It's QA maintained.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934231
I am fine doing QA upload, but can you please add CI test?
Also, I am worried about runscripts being so repetive. We already know
historic study case: classic init.d scripts and init-d-script(5).
At minimum, I think we need something like 'invoke-finish' in bin:runit
and dh_runit to create one-line `finish` script by default. Variable
'NAME' should be exported by `invoke-run'.
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Bug#939131: lintian-brush: does not detect bogus fixer name
Package: lintian-brush Version: 0.26 Severity: wishlist $ lintian-brush foo bar No changes made. $ echo $? 0 No good. Please make `lintian-brush' complain loudly about non-existent fixer. pgpX18NPpf9jg.pgp Description: PGP signature
Bug#938964: please don't install runit-helper on everyone's system
[2019-08-30 23:38] Shengjing Zhu > Package: runit-helper > Version: 2.8.13.2 > Severity: normal > > Please, don't do that. Don't let it be a second libsystemd0. Well, I am not happy with this situation myself too, but I do not know do it better. `runit-helper` is essentially dynamically-linked maintainer script. I can easily put its content directly into maintainer script, and it will even solve some problems, but it will introduce new one: every change to what is now `runit-helper` would cause transistion. Was there, did that. I thought about dpkg triggers, but there is no reasonable way to convey required information to it. Also, triggers are meant to be idempotent, while `runit-helper' is not -- it must enable service on first installation, but must respect admin decision to disable it. Just for my curiosity (not going to happen in my watch), would you be happier if `runit-helper` script was part of init-system-helpers (which is essential, anyway). Another option I can propose is making call to `runit-helper` conditional, so you can dpkg-exclude whole `runit-helper` package. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#935991: dh-runit: please avoid excessive/dangerous chown/chmod
control: tags -1 +confirmed [2019-08-28 14:12] Daniel Kahn Gillmor > Package: dh-runit > Version: 2.8.13.2 > Tags: security > Control: affects -1 tor openssh-server > > by default, dh-runit sets up logging runscripts like this: > > > 1 #!/bin/sh > 2 chown -R runit-log:adm '/var/log/runit/tor' > 3 chmod 750 '/var/log/runit/tor' > 4 chmod u+rw,g+r,o-rwx '/var/log/runit/tor'/* > 5 exec chpst -u runit-log svlogd -tt '/var/log/runit/tor' > > > Lines 2 and 4 are dangerous due to linking attacks. > [...] Thank you. I wasn't aware of such problems. Then I plan to change script to following: 1 #!/bin/sh 2 chown runit-log:adm '/var/log/runit/tor' 3 chmod 750 '/var/log/runit/tor' 4 umask 0022 5 exec chpst -u runit-log svlogd -tt '/var/log/runit/tor' The idea is that since /var/log/runit/tor is 750, log files actually can only be read by group=adm, even though their permission is 644. Is it okay? Or it opens door for some other tricks, that would allow log reading by non :adm users? Or some other problems? -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#935997: dh-runit: Avoid useless dependency on runit-helper
control: severity -1 normal control: tags -1 +confirmed +pending [2019-08-28 21:50] Lorenzo Puliti > Package: dh-runit > Version: 2.8.13.2 > Severity: wishlist > > Hi, > > I recently try to add a runscript to openssh-server but it look > that dh-runit added a dependency on runit-helper also to > openssh-client. > [...] > > but i wonder if dh-runit code can limit the dependency of runit-helper only to > the package that really ships the runscript Sure. Confirmed and fixed. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#935939: Does not respect local admin changes and recreates files in /etc/sv
control: severity -1 wishlist
control: tags -1 +confirmed
control: retitle -1 Make /etc/sv/{name}/supervise symlinks behave as conffiles
[2019-08-28 12:40] Michael Biebl
> Am 28.08.19 um 11:52 schrieb Colin Watson:
>
> > Empty directories also come back no matter what you do, so even after
> > fixing this, /etc/sv/ssh/.meta and /etc/sv/ssh/log would still come
> > back.
>
> Urgh, that's ugly. Please consider creating those directories
> dynamically then and don't ship them in the package.
Wontfix. This is normal behaviour, as pointed by Colin. See:
$ dpkg -L w3m | grep etc/
/etc/w3m
/etc/w3m/config
/etc/w3m/mailcap
$ find /etc | grep w3m
/etc/w3m
/etc/w3m/mailcap
/etc/w3m/config
$ sudo rm -r /etc/w3m
$ find /etc | grep w3m
$ sudo dpkg -i /tmp/w3m_0.5.3-37+b1_amd64.deb
[...]
$ find /etc|grep w3m
/etc/w3m
Directory comes back. Maybe it should be addressed in dpkg.
By the way, init-system-helpers behave in same way -- I can `rm -fr
/etc/systemd', but after re-installation `/etc/systemd/system' comes
back.
I find this issue cosmetic, but if it is important to you, use
/etc/dpkg/dpkg.cfg.d/excludes.
Colin Watson
> On Wed, Aug 28, 2019 at 09:42:31AM +0200, Michael Biebl wrote:
> > Since I have no use for runit, I removed the /etc/sv directory.
> > Unfortunately, if the openssh-server package is upgraded (or
> > reinstalled), the local admin choice is not respected and the files in
> > /etc/sv are recreated.
> > [...]
>
> The exceptions are /etc/sv/ssh/supervise and /etc/sv/ssh/log/supervise,
> which are symlinks to /var/lib/runit/supervise/ssh and
> /var/lib/runit/log/supervise/ssh respectively, and those do get
> reinstalled. Symlinks can't really be conffiles, but perhaps this could
> be done using generated maintainer script code or in runit-helper?
> Reassigning to dh-runit, anyway, since there isn't much I can do about
> this in openssh-server at present.
AFAIK, Policy does not forbid shipping non-conffiles into /etc. Some
other packages do so as well, e.g /etc/os-release and /etc/mysql/my.cf
just to name a few.
So, once we admit that `/etc/sv/openssh-server/supervise' is not
conffile, behaviour described by submitter is perfectly logical.
I agree that it would be great if it was conffile, so I do not wontfix
the bug for now. I will ask dpkg maintainers on possiblity of marking
symlinks as conffiles.
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Bug#936043: ITP: gitbatch -- Manage git repositories in one place
[2019-08-29 13:28] "Dawid Dziurla" > Package: wnpp > Severity: wishlist > Owner: Dawid Dziurla > > * Package name: gitbatch > Version : 0.5.0-1 > Upstream Author : Ibrahim Serdar Acikgoz > * URL : https://github.com/isacikgoz/gitbatch > * License : Expat > Programming Lang: Go > Description : Manage git repositories in one place > > Managing multiple git repositories is easier than ever. Often one would end > up working on many directories and manually pulling updates etc. To make > this routine faster, gitbatch was created, a simple tool to handle this job. > Although the focus is batch jobs, one can still do de facto micro management > of > git repositories (e.g add/reset, stash, commit etc.) Sounds like `myrepos'. What `gitbatch' does that is not possible with `myrepos'? -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#935607: lintian: classify "Starting $DESC" in init.d scripts
control: tags -1 -moreinfo
[2019-08-27 10:23] "Chris Lamb"
> Hi Dmitry,
>
> > [ Should I tag '-moreinfo' on reply, or you prefer doing it yourself? ]
>
> Please. A wishlist bug with "moreinfo" means (at least for me) that it
> is blocking on input from the reporter/requester and, if you believe
> you have resolved all the outstanding queries, then it makes sense to
> remove it so that it's easier to find things in the BTS that are ready
> to be worked on. Does that make sense?
Sure, it does. Just double-checked to not disrupt your workflow.
> > > > [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
> > >
> > > Can you describe what is wrong with this? (So we can add it to the
> > > long description at the very least...)
> >
> > Both behaviours are fine, as long they are used consistently.
>
> Oh, I think I see. Well, actually I was confused about this bug and
> indeed am not sure enough to implement anything yet. The problem is
> the use of the conditional checking of $VERBOSE, regardless of the
> action?
>
> I think what would be good is bunch of "good" and "bad" examples here
> to help me be 100% sure.
Again, there is no "good" and "bad" yet. Here is pseudo-code:
for line in lines(/etc/init.d/script) {
next unless if line =~ 'log daemon msg "(Starting|Stopping)';
if line =~ '$VERBOSE' {
classify 'do check for VERBOSE'
} else {
classify 'do NOT check for VERBOSE'
}
}
When we see, which of these styles is majority, we can proclaim other
unwanted and to be fixed.
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Bug#934500: dh-runit: permissions of supervise directory
[2019-08-27 16:35] Jan Braun > > > Personally, I'd prefer linking /etc/sv/foo/supervise to a place of my > > > choosing and expect that link to be preserved. Not sure how others > > > would feel, or how they'd try to deal with the issue. > > > > Why would you need it? Content of 'supervise' directory is transient, > > there is nothing valuable in it. > > Except the permissions, if non-default. Okay. > > While I understand desire to make things as configurable as possible, it > > will put burden of /properly/ purging things from dpkg to me, which I'd > > rather avoid. > > Are you saying "me" as in the Debian maintianier of runit, or "me" as in > the local admin of the machine in question? As Debian maintainer. > When I add files in non-default locations, I expect dpkg/maintainer > scripts not to touch them, This. Maintainers scripts is my burden. > and possibly dpkg to message me "directory /some/path not empty, not > removed" when purging the package, alerting me that I might need to > clean up manually. I think that kind of behaviour is required by > debian policy, it has worked whenever I needed it in the past, and > AFAICT it works with the runit* packages right now. So there should be > no additional burden on you, the Debian maintainer. That is the point. dpkg manages files that are part of package (as of dpkg -L), that is why I want make /etc/sv/foo/service symlink part of package. If I create something in maintainer script, I have to purge it in maintainer script, with all kinds of interesting corner cases (e.g #848239 #848240) > If you meant the purging of /var/lib/runit/supervise/foo in case the > runit* packages decide to put things there by default, that's an > unconditional "rm -rf" in the appropriate maintainer script and not much > of a burden. Or am I missing something there? If admin put something valuable in /var/lib/runit/supervise/foo I have to re-implement (see runit-helper source) "directory not empty, not removing" logic. > As to where Debian's runit should point the symlink by default: > > /var/lib/runit/supervise/foo: > + persists non-default supervise dir permissions at no cost to the > local admin. > - unneccessarily persists the rest of the supervise dir. > /run/runit/supervise/foo: > - requires admin effort to get persistent non-default supervise dir > permissions. > + saves writes to a durable medium during operation. > > I don't really have a preference here. Thanks for this summary. I did not thought about saving writes. As I pointed above I have strong preference for /run/runit. Actually, I consider /var/lib/runit/supervise major design error of mine. > And I don't need to. :) Because on my machines, I'm back to a ramdisk on > /etc/service, which: > + persists exactly what it's told to (by placing it in /etc/sv ) > + saves writes to durable storage > - requires a reboot or other admin action to apply their /etc/sv > changes to the ramdisk. :( > > I doubt that's an acceptable default configuration for Debian, but it's > implemented as an option with very little effort: > * a few lines setting up the ramdisk in /etc/runit/2 (conditional on > /etc/service being a symlink to /run/service), > * a one-line change preventing /lib/runit/invoke-run from dying to > the changed path¹, > * a new script (or patch to update-service) to implement said > admin action without rebooting. > Holler if you're interested in adding it to Debian. (Which would be > nice, but I can live very well on my local modifications too.) Not sure > if having this as an option should tilt the /run vs. /var decision. While I see advantages of your setup, I am not ready to support it Debian-wide, in numerous Debian configurations. What I can offer is following: * I can bundle your /etc/runit/2 in /usr/share/doc/runit/contrib, with clear notice that this setup is not officially supported by Debian, but is succesfully used by some admins. * You can propose patch for update-service. As long it still work with default configuration and does not introduces too much complexity, I am okay to apply it. Lorenzo knows better about `update-service` than me. * You can file bug on `invoke-run`, we will see what can be amended. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#588666: boot message stuck onto next message
control: tags -1 +fixed-upstream [2019-08-26 16:32] Jesse Smith > On Sun, 25 Aug 2019 16:07:30 +0000 Dmitry Bogatov wrote: > > > > > Each line a process sends: > > > > * should be prefixed by the name of the process that sent it. > > > > * should end with a newline. > > > > > > And (#398269) each line should be either from a process or the kernel, > > > distinguishable enough. > > > > > > I fully agree, that should be basic and not need discussion. > > > > Okay, reassigning then. > > > > @Jesse, yet another feature request for startpar :) > > > I have added a command line flag (-n) which causes the name of the > sending process to prefix output, unless the command is interactive. > > It looks like this: startpar -n -t 1 process-a process-b > > process-a: Starting process... > process-b: Starting process... > process-b: Done. > process-a: Done. > > This will be in the next release of startpar. I'm looking at adding a > newline to the end of output too. Great. Thank you. Tagged as-needed. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#934500: dh-runit: permissions of supervise directory
[2019-08-24 16:03] Jan Braun > Dmitry Bogatov schrob: > > No, I did not consider this aspect. Thank you. > > But since runscripts are conffiles, admin can add line > > > > chown -R trusted_user:0 /run/runit/supervise/foo > > > > into /etc/sv/foo/run, and they will be preserved during upgrade. Not > > that staightforward, but still solution. Is it acceptable? > That means they'll get a conffile prompt if/whe the maintainer changes > the run file. This can be solved in /lib/runit/invoke-run. Something like running /etc/service/foo/run.pre before "run". Feel free to file wishlist. With heavy heart, but I will implement it. > Personally, I'd prefer linking /etc/sv/foo/supervise to a place of my > choosing and expect that link to be preserved. Not sure how others > would feel, or how they'd try to deal with the issue. Why would you need it? Content of 'supervise' directory is transient, there is nothing valuable in it. While I understand desire to make things as configurable as possible, it will put burden of /properly/ purging things from dpkg to me, which I'd rather avoid. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#935607: lintian: classify "Starting $DESC" in init.d scripts
[ Should I tag '-moreinfo' on reply, or you prefer doing it yourself? ] [2019-08-24 14:44] "Chris Lamb" > > some init.d script print description of service they are starting with > > following line: > > > > log_daemon_msg "Starting X display manager" "xdm" > > or > > log_action_begin_msg "Starting $DESC" > > > > The pattern is `"Starting '. Some (minority, I think) do the same, but > > only if $VERBOSE != no, like this: > > > > [ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME" > > Can you describe what is wrong with this? (So we can add it to the > long description at the very least...) Both behaviours are fine, as long they are used consistently. Otherwise they cause wierd output when $VERBOSE = no (see #658374). For example this output with VERBOSE=yes: Starting Foo # ignores VERBOSE Foo writes output on its own Starting Bar # checks VERBOSE Bar writes output on its own turns into following confusing output with VERBOSE=no Starting Foo # ignores VERBOSE Foo writes output on its own Bar writes output on its own which creats illusion that "Bar writes output on its own" is caused by Foo. > Also, do we need to do this for "stop" or other actions too? Yes, this too. Thanks. > > Please add classification tag, that distinguish these cases. After that, > > minority behaviour could be marked with minor severity tag > > Just FYI what we prefer to do here is to mark it as 'experimental' but > the idea is the same (ie. fix false-positives first). That is fine. Note, that both behaviours are correct, they just need to be uniform. I'd avoid marking some behaviour as more preferable than another, as long as we do not have data to say which is majority. Hope it clarifies. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
