Bug#928919: patch: Do not hide errors from initscripts
Package: initscripts Severity: wishlist Tags: patch From 987ac0ec780a063052346ff8adb33a072694ae11 Mon Sep 17 00:00:00 2001 From: Dmitry Bogatov Date: Sat, 11 May 2019 20:19:11 + Subject: [PATCH] Do not hide errors from initscripts --- debian/src/initscripts/etc/init.d/bootlogs | 2 -- debian/src/initscripts/etc/init.d/bootmisc.sh| 2 -- debian/src/initscripts/etc/init.d/checkfs.sh | 2 -- debian/src/initscripts/etc/init.d/checkroot-bootclean.sh | 2 -- debian/src/initscripts/etc/init.d/checkroot.sh | 2 -- debian/src/initscripts/etc/init.d/halt | 2 -- debian/src/initscripts/etc/init.d/hostname.sh| 2 -- debian/src/initscripts/etc/init.d/mountall-bootclean.sh | 2 -- debian/src/initscripts/etc/init.d/mountall.sh| 2 -- debian/src/initscripts/etc/init.d/mountnfs-bootclean.sh | 2 -- debian/src/initscripts/etc/init.d/mountnfs.sh| 2 -- debian/src/initscripts/etc/init.d/rmnologin | 2 -- debian/src/initscripts/etc/init.d/sendsigs | 2 -- debian/src/initscripts/etc/init.d/umountfs | 2 -- debian/src/initscripts/etc/init.d/umountnfs.sh | 2 -- debian/src/initscripts/etc/init.d/umountroot | 2 -- debian/src/initscripts/etc/init.d/urandom| 2 -- 17 files changed, 34 deletions(-) diff --git a/debian/src/initscripts/etc/init.d/bootlogs b/debian/src/initscripts/etc/init.d/bootlogs index 686a2afb..3916e4ef 100644 --- a/debian/src/initscripts/etc/init.d/bootlogs +++ b/debian/src/initscripts/etc/init.d/bootlogs @@ -65,5 +65,3 @@ case "$1" in exit 3 ;; esac - -: diff --git a/debian/src/initscripts/etc/init.d/bootmisc.sh b/debian/src/initscripts/etc/init.d/bootmisc.sh index 461b7472..f56b4078 100755 --- a/debian/src/initscripts/etc/init.d/bootmisc.sh +++ b/debian/src/initscripts/etc/init.d/bootmisc.sh @@ -58,5 +58,3 @@ case "$1" in exit 3 ;; esac - -: diff --git a/debian/src/initscripts/etc/init.d/checkfs.sh b/debian/src/initscripts/etc/init.d/checkfs.sh index 67929dec..ab5a4bac 100755 --- a/debian/src/initscripts/etc/init.d/checkfs.sh +++ b/debian/src/initscripts/etc/init.d/checkfs.sh @@ -145,5 +145,3 @@ case "$1" in exit 3 ;; esac - -: diff --git a/debian/src/initscripts/etc/init.d/checkroot-bootclean.sh b/debian/src/initscripts/etc/init.d/checkroot-bootclean.sh index effe252b..1cf811cd 100755 --- a/debian/src/initscripts/etc/init.d/checkroot-bootclean.sh +++ b/debian/src/initscripts/etc/init.d/checkroot-bootclean.sh @@ -39,5 +39,3 @@ case "$1" in exit 3 ;; esac - -: diff --git a/debian/src/initscripts/etc/init.d/checkroot.sh b/debian/src/initscripts/etc/init.d/checkroot.sh index 873e6748..cb7e1537 100755 --- a/debian/src/initscripts/etc/init.d/checkroot.sh +++ b/debian/src/initscripts/etc/init.d/checkroot.sh @@ -375,5 +375,3 @@ case "$1" in exit 3 ;; esac - -: diff --git a/debian/src/initscripts/etc/init.d/halt b/debian/src/initscripts/etc/init.d/halt index c179a25a..f4f5ffaf 100755 --- a/debian/src/initscripts/etc/init.d/halt +++ b/debian/src/initscripts/etc/init.d/halt @@ -79,5 +79,3 @@ case "$1" in exit 3 ;; esac - -: diff --git a/debian/src/initscripts/etc/init.d/hostname.sh b/debian/src/initscripts/etc/init.d/hostname.sh index 71635d37..95880cc1 100755 --- a/debian/src/initscripts/etc/init.d/hostname.sh +++ b/debian/src/initscripts/etc/init.d/hostname.sh @@ -46,5 +46,3 @@ case "$1" in exit 3 ;; esac - -: diff --git a/debian/src/initscripts/etc/init.d/mountall-bootclean.sh b/debian/src/initscripts/etc/init.d/mountall-bootclean.sh index 546c5322..d4d1dad8 100755 --- a/debian/src/initscripts/etc/init.d/mountall-bootclean.sh +++ b/debian/src/initscripts/etc/init.d/mountall-bootclean.sh @@ -31,5 +31,3 @@ case "$1" in exit 3 ;; esac - -: diff --git a/debian/src/initscripts/etc/init.d/mountall.sh b/debian/src/initscripts/etc/init.d/mountall.sh index 129a4325..50d192cb 100755 --- a/debian/src/initscripts/etc/init.d/mountall.sh +++ b/debian/src/initscripts/etc/init.d/mountall.sh @@ -112,5 +112,3 @@ case "$1" in exit 3 ;; esac - -: diff --git a/debian/src/initscripts/etc/init.d/mountnfs-bootclean.sh b/debian/src/initscripts/etc/init.d/mountnfs-bootclean.sh index d1a6d8bc..d6ffae12 100755 --- a/debian/src/initscripts/etc/init.d/mountnfs-bootclean.sh +++ b/debian/src/initscripts/etc/init.d/mountnfs-bootclean.sh @@ -31,5 +31,3 @@ case "$1" in exit 3 ;; esac - -: diff --git a/debian/src/initscripts/etc/init.d/mountnfs.sh b/debian/src/initscripts/etc/init.d/mountnfs.sh index 00ac7572..a33e9ef7 100755 --- a/debian/src/initscripts/etc/init.d/mountnfs.sh +++ b/debian/src/initscripts/etc/init.d/mountnfs.sh @@ -102,5 +102,3 @@ case "$1" in exit 3
Bug#928810: patch: Make debian-watch-uses-insecure-uri more generic
Package: lintian-brush
Severity: wishlist
Tags: patch
From 2789fed85a6088c85f8f37ba96984eb7f3d8e8ef Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Fri, 10 May 2019 23:32:01 +
Subject: [PATCH] Make debian-watch-uses-insecure-uri more generic
Instead of using hard-coded list of hosts, that are known to support
https new implementation just replace "http://; with "https://; and
makes sure, that uscan report is same.
---
fixers/debian-watch-uses-insecure-uri.sh | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/fixers/debian-watch-uses-insecure-uri.sh
b/fixers/debian-watch-uses-insecure-uri.sh
index 85136b8..59c1e4f 100755
--- a/fixers/debian-watch-uses-insecure-uri.sh
+++ b/fixers/debian-watch-uses-insecure-uri.sh
@@ -1,6 +1,17 @@
#!/bin/sh
-perl -p -i -e
's/http:\/\/code.launchpad.net\//https:\/\/code.launchpad.net\//' debian/watch
-perl -p -i -e 's/http:\/\/launchpad.net\//https:\/\/launchpad.net\//'
debian/watch
-perl -p -i -e 's/http:\/\/ftp.gnu.org\//https:\/\/ftp.gnu.org\//' debian/watch
+before=$(mktemp)
+after=$(mktemp)
+uscan --dehs > "${before}" 2>&1
+sed -i.bak s,http://,https://,g debian/watch
+uscan --dehs > "${after}" 2>&1
+
+# Make sure that reports are same up to http/https substitution in URL.
+sed -i s,http://,https://,g "${before}" "${after}"
+if cmp -s "${before}" "${after}" ; then
+ rm -f debian/watch.bak
+else
+ mv debian/watch.bak debian/watch
+fi
+rm -f "${before}" "${after}"
echo "Use secure URI in debian/watch."
echo "Fixed-Lintian-Tags: debian-watch-uses-insecure-uri"
pgpahziaUrAG9.pgp
Description: PGP signature
Bug#928809: lintian: suggest adding gitlab-ci file
Package: lintian
Version: 2.13.0
Severity: wishlist
Dear Maintainer,
please add suggestion that if Vcs-Git points to salsa.debian.org,
CI should be used.
While CI config can be located anywhere (ci_config_path property of
project), both Debian Wiki and salsa(1) manpage mention
"debian/.gitlab-ci.yml" path.
So, in pseudo-code I propose following:
if ($vcs =~ salsa.debian.org && ! -r "debian/.gitlab-ci.yml") {
tag-pedantic "consider useing Gitlab CI"
}
pgpDDpOYqSppt.pgp
Description: PGP signature
Bug#928811: patch: New fixer: patch-file-present-but-not-mentioned-in-series.sh
Package: lintian-brush
Severity: wishlist
Tags: patch
From dac3dbdaf7505502a860bb365ccd88da1717dc87 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Sat, 11 May 2019 14:46:44 +
Subject: [PATCH] New fixer: patch-file-present-but-not-mentioned-in-series.sh
Make sure that debian/patches contain only patches, mentioned in series
file.
---
fixers/index.desc | 3 +++
.../patch-file-present-but-not-mentioned-in-series.sh | 10 ++
2 files changed, 13 insertions(+)
create mode 100755 fixers/patch-file-present-but-not-mentioned-in-series.sh
diff --git a/fixers/index.desc b/fixers/index.desc
index 735179f..058889c 100644
--- a/fixers/index.desc
+++ b/fixers/index.desc
@@ -120,6 +120,9 @@ Lintian-Tags:
package-uses-deprecated-debhelper-compat-version,
package-uses-old-debhelper-compat-version
+Fix-Script: patch-file-present-but-not-mentioned-in-series.sh
+Lintian-Tags: patch-file-present-but-not-mentioned-in-series
+
Fix-Script: possible-missing-colon-in-closes.sh
Lintian-Tags: possible-missing-colon-in-closes
diff --git a/fixers/patch-file-present-but-not-mentioned-in-series.sh
b/fixers/patch-file-present-but-not-mentioned-in-series.sh
new file mode 100755
index 000..66ff555
--- /dev/null
+++ b/fixers/patch-file-present-but-not-mentioned-in-series.sh
@@ -0,0 +1,10 @@
+#!/bin/sh -eu
+test -r debian/patches/series || exit 0
+cd debian/patches
+
+for f in * ; do
+ test "${f}" != series || continue
+ grep -q -- "${f}" series || rm "${f}"
+done
+echo "Remove patches missing from debian/patches/series."
+echo "Fixed-Lintian-Tags: patch-file-present-but-not-mentioned-in-series"
pgpfSBQ_qypeg.pgp
Description: PGP signature
Bug#928808: tracker.debian.org: automatic filing bugs
Package: tracker.debian.org Severity: wishlist Dear Maintainer, would it be possible to automatically file bugs with issues, already detected by tracker? Personally, I would be especially interested in auto-reporting bugs about new upstream releases and lintian warnings/errors. Sure, this feature must be opt-in, but it would be great improvement to my workflow. Question is access-control. Probably, only maintainer/uploader of package can make decision, whether bugs should be auto-reported. I see it as something like this: C: mailto:cont...@tracker.debian.org?subject=autoreport=packagename S: C: S: Ideally, email, signed with DD/DM key would not require confirmation. pgpINifVQhT2p.pgp Description: PGP signature
Bug#928394: RFS: freetype-py/2.1.0.post1-1 [ITP]
[2019-05-06 01:31] Bastian Germann
> Thanks for coming back to me. I have fixed the things you pointed out.
In debian/rules you write ${DEB_VERSION_UPSTREAM} -- note "{", not "(".
Make uses $(foo) syntax for variable access. Build still successfull,
but, well, please double check this moment.
Also, you have no autopkgtest. I heard, default one for python could be
added with following in "debian/control".
Testsuite: autopkgtest-pkg-python
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#670585: "ok hat location is writable"
[2019-05-08 14:57] Tito
> > Problem is that I do not understand, when /var/log/fsck exist for sure.
> >
> > Collegues, I need help with evaluating proposed change.
> >
> Hi,
> I guess if it is a one partition only setup /var/log will
> exist as soon as as root is switched from initrd and/or
> remounted read-write, if it is a multi-partition setup
> with separated partitions for /tmp, /home and /var,
> /var will exist as soon as root is switched from
> initrd but /var/log will exist only after /var is mounted.
So it means, that check 'test -w "${FSCK_LOGFILE}"' that you proposed is
only meaningful after 'mountall', but not in 'checkfs'. So I have to
keep more vague
"Log is being saved in ${FSCK_LOGFILE} if that location is writable"
Did I miss something?
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#928637: RFS: emacs-neotree/0.5.2-1 [ITP]
[2019-05-07 22:48] Nicholas D Steeves > Package: sponsorship-requests > Severity: wishlist > Control: block 872873 by -1 > > I am looking for a sponsor for my package "emacs-neotree". Neotree is > a very popular Emacs addon on MELPA (Emacs addon repository), and is > at the 99th percentile for MELPA unstable, and the 98th for MELPA stable. > > https://melpa.org/#/neotree > https://stable.melpa.org/#/neotree > > Package name: emacs-neotree > Version : 0.5.2-1 > Upstream Author : jaypei > URL : https://github.com/jaypei/emacs-neotree > License : GPL-3+ > Section : lisp > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/e/emacs-neotree/emacs-neotree_0.5.2-1.dsc Everything super-nice, just uploaded. One minor request: on next upload, add field "Upstream-Contact" into debian/copyright. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#670585: "ok hat location is writable"
[2019-05-06 07:33] Tito
> [ Dmitry Bogatov ]
> > - log_success_msg "Done checking file systems.
> > -A log is being saved in ${FSCK_LOGFILE} if that location is writable."
> > + log_success_msg 'Done checking file systems'
> > + log_success_msg "Log is being saved in
> > ${FSCK_LOGFILE} if that location is writable"
> > fi
> > fi
> Hi,
> maybe something like:
>
> if test -w ${FSCK_LOGFILE} ; then
> log_success_msg "Log is saved in ${FSCK_LOGFILE}
> else
> log_success_msg "Cannot save log in ${FSCK_LOGFILE}
> fi
Thank you, Tito. But I am not sure this is correct:
As I understand the whole point of "logsave" is that if directory of
logfile (/var/log/fsck) does not exist, "logsave" will wait till it
appears.
So, by the time we are logging this message, ${FSCK_LOGFILE} may not
exists yet, but its future content is hanging somewhere in memory of
"logsave" process.
Problem is that I do not understand, when /var/log/fsck exist for sure.
Collegues, I need help with evaluating proposed change.
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#928481: mmh: wierd boundary-separators generated
Package: mmh
Severity: normal
Dear Maintainer,
mmh sometimes generates boundary separators in multipart messages with
non-ascii symbols in it. Not sure about RFC-compliance, but at least
Python standard library does not work well with them.
Here is example of problematic separator:
--21189_ĵaŭ_Maj__2_15_03_59_UTC_2019
Notice non-ascii "ĵ" letter. The separator looks like output of date(1)
(my locale is eo.utf-8).
According to my investigation, such boundary is generated in mhsign.sh
script, newboundary() function, line 185 (in mmh=0.4 release), which
have following line:
b=$$_`date|sed 's/[ : ]/_/g'`
I think the simpliest fix would be using C locale for date. Patch is
attached. Not sure, whether it is safe to export LC_ALL=C at top of
script.
From 063686f0e94067edfbc44cb58bc2404b326f8754 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Fri, 3 May 2019 18:37:19 +
Subject: [PATCH] Ensure that multipart message boundaries are ascii-only
---
uip/mhsign.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/uip/mhsign.sh b/uip/mhsign.sh
index 894ca5e..44b3870 100755
--- a/uip/mhsign.sh
+++ b/uip/mhsign.sh
@@ -182,7 +182,7 @@ fixheaders() {
### newboundary -- output a suitable boundary marker
newboundary() {
- b=$$_`date|sed 's/[ : ]/_/g'`
+ b=$$_`LC_ALL=C date|sed 's/[ : ]/_/g'`
for i in 0 x '=' _ + , Z 9 4 ; do
if grep "^--$b" $TEMP/body >/dev/null 2>&1 ; then
## oops, bad boundary -- try again
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
pgpVw_j2n_1Q9.pgp
Description: PGP signature
Bug#928484: libgitlab-api-v4-perl: incorrect handling of non-json data
Package: libgitlab-api-v4-perl
Version: 0.16-1
Severity: important
Dear Maintainer,
I am trying to use gitlab-api-v4 tool to get CI job output, but get
following output:
malformed JSON string, neither array, object, number, string or atom,
at character offset 0 (before "\x{1b}[0KRunning wit...") at
/usr/share/perl5/GitLab/API/v4/RESTClient.pm line 179.
It seems that library assumes,
# JSON decoding may fail. Catch it and provide a more contextually rich
# error message?
return $self->json->decode( $res->{content} );
that data, returned by server is always valid JSON. In case of
GET /projects/:id/jobs/:job_id/trace
endpoint, it is not the case.
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
pgpJxquwf4aTt.pgp
Description: PGP signature
Bug#928394: RFS: freetype-py/2.1.0.post1-1 [ITP]
[2019-05-03 17:18] Bastian Germann > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "freetype-py". This closes a > very long-standing wnpp issue. I posted an earlier version last > September but got no attention so far. > > * Package name: freetype-py >Version : 2.1.0.post1-1 >Upstream Author : Nicolas P. Rougier > * URL : https://github.com/rougier/freetype-py > * License : BSD >Section : python > > It builds those binary packages: > > python3-freetype - Freetype Python bindings for Python 3 Here what I found interesting: * Lintian complains about "font-in-non-font-package" and "font-outside-font-dir". Why do you ship .ttf font in examples directory? * Policy is slightly outdated. * In debian rules, instead of "cat PKG-INFO | sed ..." you can use $DEB_VERSION_UPSTREAM. See /usr/share/dpkg/pkg-info.mk. By the way, it is useless-use-of-cat. * You can use B-D: debhelper-compat (= 11). Why not 12, by the way? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#928350: cdist: new upstream release
control: tags -1 +upstream [2019-05-02 15:04] Dmitry Bogatov > Dear Maintainer, > > new upstream release 4.11.1 is available on new upstream hosting: > http://code.ungleich.ch/ungleich-public/cdist.git Upstream transition is not finished yet, and there is no GPG-signed release tarball at new hosting yet. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#670585: "ok hat location is writable"
control: usertags -1 +objections
[2019-05-02 22:00] Antoni Villalonga
> I've found the message here:
>
> /etc/rcS.d/S10checkfs.sh
> 124 log_success_msg "Done checking file systems.
> 125 A log is being saved in ${FSCK_LOGFILE} if that location is writable."
>
> I think the console width was 80 chars and it caused "if that location..."
> message drop to next line. After that, "[ ok " message overwrited from the
> beggining of the line, causing the anoying message.
> If this problem is meant to be "fixed"? Shorter messages (if any) may
> be the easy way.
Thank you for suggestion. I managed reproduce similar (but not exactly
same) glitch with long line and 80 column wide terminal.
I believe following patch, that splits and slightly rewords message
should fix issue. Second part is still quite long -- long enough to fill
exactly 80 columns, but I have no idea how to shorten it futher.
Opinions?
From 2799d371c413b9c606e968eb61f94711ce70cd4f Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Fri, 3 May 2019 17:21:17 +
Subject: [PATCH] Split long message into several lines
Long message on 80-column may cause visual glitches due interation of
terminal control characters and newline breaking, so it is safer to
make sure that no argument to 'log_{success,warning,error}_msg' is
no longer than 70 characters (generously leaving 10 characters for colored
ok/warn/error marker on the left).
Closes: #670585
Thanks: Antoni Villalonga
---
debian/src/initscripts/etc/init.d/checkfs.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/debian/src/initscripts/etc/init.d/checkfs.sh
b/debian/src/initscripts/etc/init.d/checkfs.sh
index 13a10d10..67929dec 100755
--- a/debian/src/initscripts/etc/init.d/checkfs.sh
+++ b/debian/src/initscripts/etc/init.d/checkfs.sh
@@ -121,8 +121,8 @@ Continuing with system boot in 5 seconds."
then
handle_failed_fsck
else
- log_success_msg "Done checking file systems.
-A log is being saved in ${FSCK_LOGFILE} if that location is writable."
+ log_success_msg 'Done checking file systems'
+ log_success_msg "Log is being saved in
${FSCK_LOGFILE} if that location is writable"
fi
fi
fi
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#928483: execline: vim syntax highlighting
Package: execline
Version: 2.5.0.1-4
Severity: wishlist
Dear Maintainer,
please consider including (any maybe suggesting upstream) attached vim
syntax highlighting files.
There seems to be no well-established extension for execline scripts. I
choosed arbitrary ".ex".
setlocal shiftwidth=2
setlocal tabstop=2
setlocal expandtab
let b:undo_ftplugin = ""
au BufRead,BufNewFile *.ex set filetype=execline
if exists("b:current_syntax") | finish | endif
syntax keyword Special background
syntax keyword Special backtick
syntax keyword Special cd
syntax keyword Special define
syntax keyword Special dollarat
syntax keyword Special elgetopt
syntax keyword Special elgetpositionals
syntax keyword Special elglob
syntax keyword Special emptyenv
syntax keyword Special exec
syntax keyword Special exitcodes
syntax keyword Special exit
syntax keyword Special export
syntax keyword Special fdblock
syntax keyword Special fdclose
syntax keyword Special fdmove
syntax keyword Special fdreserve
syntax keyword Special fdswap
syntax keyword Special forbacktickx
syntax keyword Special foreground
syntax keyword Special forstdin
syntax keyword Special forx
syntax keyword Special getcwd
syntax keyword Special getpid
syntax keyword Special heredoc
syntax keyword Special homeof
syntax keyword Special ifelse
syntax keyword Special if
syntax keyword Special ifte
syntax keyword Special ifthenelse
syntax keyword Special importas
syntax keyword Special loopwhilex
syntax keyword Special multidefine
syntax keyword Special multisubstitute
syntax keyword Special pipeline
syntax keyword Special piperw
syntax keyword Special redirfd
syntax keyword Special runblock
syntax keyword Special shift
syntax keyword Special trap
syntax keyword Special tryexec
syntax keyword Special umask
syntax keyword Special unexport
syntax keyword Special upgrade
syntax keyword Special wait
syntax keyword Special withstdinas
syntax match Function /\(^\| \):[a-z-]\+\($\| \)/
syntax match Comment /^#.*/
pgpIPqM8FMW6i.pgp
Description: PGP signature
Bug#928482: salsa: add feature to request membership
Package: devscripts Version: 2.19.4 Severity: wishlist Dear Maintainer, please make it possible to request membership in salsa team with salsa(1) command line tool. pgpqpAEQ6ELr0.pgp Description: PGP signature
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
[2019-05-01 13:25] Alessandro Vesely > Put it another way, if I drop the (admittedly unrealistic) possibility > to edit rc?.d's by hand, I would have to conclude that that > architecture is a relic devoid of its functionality. Do we maintain > it for aesthetic reasons, like the Colosseum? > I wouldn't know. I like it, probably just because I've been using it > for so long. I appreciate LSB comment convention as a clever > evolution, which helps ordering the links. Preserving that somewhat > baroque directory structure, deprived of its flexibility merits, > however, sounds fictional. Beauty in the eye of beholder. I do not see anything baroque or fictional in /etc/rc[0-6] directory structure. In theory, we could have replaced symlink tree with some other output format. Plain text file, autogenerated shell script, cdb database, whatever. To do so, we would need at least: * change insserv to generate new format * change /etc/init.d/rc and startpar to read this format * have transition plan from symlink tree format It would have at least following downsides: * it will break third-party scripts. They exist. I wrote some. I see following upsides, aside from aesthetic: * we could move output under /var, where it actually belongs. So, I do not think it worth the trouble, sorry. But I think it would be nice to add note /etc/rc[0-9]/README, that content of this directories are not meant to be edited manually. Sad that I can't chmod 444 symlink. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#928350: cdist: new upstream release
--21189_ĵaÅ_Maj__2_15_03_59_UTC_2019 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Package: cdist Severity: wishlist Dear Maintainer, new upstream release 4.11.1 is available on new upstream hosting: http://code.ungleich.ch/ungleich-public/cdist.git -- = Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction = -- --21189_ĵaÅ_Maj__2_15_03_59_UTC_2019 Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEhnHVzDbtdH7ktKj4SBLY3qgmEeYFAlzLBt8ACgkQSBLY3qgm EeZLJxAAn7oZM/heftRovJjC0na6ji1AKKFC+8n4VlQXL5VLib+v7lB4kFD7v4bT E69sQIn2tsIfQa12PCqLFQ53gp88wDN3MDlj+wl2fq8AO6a9iqbxPwbiEOYh2IQC lcSMTVdHbIBKLTJPfgrprICeyc/E098ciY+McIpaX615iff5tG3O2/XQ64hvoLeR JYT1ZIb7LcTS8WKcPf9y0bPIa6ZLvErIvEhBSSk4kCid6+KcnxpdTg7ZPd0t1dU6 vAbcc1Uc20sS6NEgwhkG2Y3NoAYYYPo4WbuxlguiWpjfMlWrpgp8e8goHjVV93d0 /XEwycl+ZDHmEx6Npv7l3j+EFGRd/RiibsMp2U3/pGN94F0j9M9KIDcVRe1XlMqJ BbqlELFQuk/NTu/QEFPsIY/U0/sRQDpigRjbMeFKvsV09XVvPIoXiTDZNeLtXiUE uqqiYAM2lkxZAIxIWcjrVoFhzsp5WbLAukFgLqGwP5ocTjgiyzs3X/0+M6jzUdFI ml9UUL2EbN8t1LQfHrXkotDxlj8eIbR2t6qVSlxFJITMhWq3ofwN1NR84OWFr4P9 rLagQTg49JFDTL0nvB2VWFA02TDwUEQC8KWdgbHFFq4FnSFhSa8jxNejwP6WuoSq T+UrOWz7HxIa4W5ocPlUBp33lXD5vWbAlLrv0g4yXa7K9qb4NkA= =BazI -END PGP SIGNATURE- --21189_ĵaÅ_Maj__2_15_03_59_UTC_2019--
Bug#928348: initscripts use unsafe `: >` shell command to create files
Package: initscripts
Severity: wishlist
Followup-For: Bug #923478
[ Moving discussion to separate bug ]
[ Please, drop #923478 on reply ]
[2019-04-29 02:44] Chris Hofstaedtler
> part text/plain 517
> * Dmitry Bogatov [190429 01:14]:
> > [2019-04-26 13:17] Chris Hofstaedtler
> > > > According my experiments, it will. Even if I remove this code, something
> > > > (login/getty, maybe?) still creates /var/run/utmp, root:root.
> > >
> > > Which init was used in your experiments?
> >
> > sysvinit-core.
>
> https://sources.debian.org/src/sysvinit/2.93-8/src/init.c/?hl=2797#L2797
>
> Note that the comment citing the preconditions is not telling the
> entire story on modern systems.
Thank you very much, Chris. I should have found it myself.
Then creating /var/run/utmp is needed, since "runit-init" would not
create it itself: it relies on initscripts. Based on patch of Christian,
I propose following patch. Dear sysvinit folks, opinions?
From ce3417109303bafbc771f40428579e6691a436df Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Wed, 1 May 2019 23:43:13 +
Subject: [PATCH] Error handle redirection used to truncate /var/run/wtmp
Signed-off-by: Cristian Ionescu-Idbohrn
Signed-off-by: Dmitry Bogatov
---
debian/src/initscripts/etc/init.d/bootmisc.sh | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/debian/src/initscripts/etc/init.d/bootmisc.sh
b/debian/src/initscripts/etc/init.d/bootmisc.sh
index 06facc2f..461b7472 100755
--- a/debian/src/initscripts/etc/init.d/bootmisc.sh
+++ b/debian/src/initscripts/etc/init.d/bootmisc.sh
@@ -12,6 +12,7 @@
PATH=/sbin:/usr/sbin:/bin:/usr/bin
[ "$DELAYLOGIN" ] || DELAYLOGIN=yes
+. /lib/lsb/init-functions
. /lib/init/vars.sh
do_start () {
@@ -25,18 +26,20 @@ do_start () {
;;
esac
- # Create /var/run/utmp so we can login.
- true > /var/run/utmp
- if grep -q ^utmp: /etc/group
- then
- chmod 664 /var/run/utmp
- chgrp utmp /var/run/utmp
- fi
-
# Remove bootclean's flag files.
# Don't run bootclean again after this!
rm -f /tmp/.clean /run/.clean /run/lock/.clean
rm -f /tmp/.tmpfs /run/.tmpfs /run/lock/.tmpfs
+
+ readonly utmp='/var/run/utmp'
+ if > "${utmp}" ; then
+ chmod 644 "${utmp}" || log_warning_msg "failed to chmod
${utmp}"
+ chgrp utmp "${utmp}" || log_warning_msg "failed to chgrp
${utmp}"
+ return 0
+ else
+ log_failure_msg "failed to truncate ${utmp}"
+ return 1
+ fi
}
case "$1" in
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#928347: shellcheck: new upstream release 0.6
--21081_ĵaÅ_Maj__2_15_03_52_UTC_2019 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Package: shellcheck Version: 0.5.0-3 Severity: wishlist Dear Maintainer, upstream version 0.6 is released. Please consider packaging it. -- System Information: Debian Release: 10.0 APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing')= , (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=3Deo.utf8, LC_CTYPE=3Deo.utf8 (charmap=3DUTF-8), LANGUAGE=3Deo= =2Eutf8 (charmap=3DUTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: runit (via /run/runit.stopit) Versions of packages shellcheck depends on: ii libatomic1 8.3.0-6 ii libc6 2.28-8 ii libffi6 3.2.1-9 ii libgmp102:6.1.2+dfsg-4 shellcheck recommends no packages. shellcheck suggests no packages. -- no debconf information --21081_ĵaÅ_Maj__2_15_03_52_UTC_2019 Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEhnHVzDbtdH7ktKj4SBLY3qgmEeYFAlzLBtgACgkQSBLY3qgm EeZr5Q//dTLXzh/skP3LGWBFdSyD3dHrbYvL9Mju2AxFoS+XsJvogKsEmO/Ld3XM CjAGlF9AdplKvQ/+0QAhEP4HiLwN5OKdc5eZEp297LTQwR/rj7cUyHL4E04Cz8hh sPgSh1ndM5Jx9+fMiri3ZfNVJgzT06/ui0wvH/ZGIpg53DPp6VgJUt6jcFRpE5lH +800/xiV/GCHU3oBLKdd+1DcWuUHoQv0j3HhSmZ6SKhIVD1s2JlBbjYSt4NAdpGM dR9VDzxurEyA/qRIWJbrrz/N8JVvT50Qv0GtDLyHq+mmyv/V6Xa7LDvgNrJhNTYq 2p3RQFE9cdgntnszlL2tifDflI6ohxa8BORQ6GSBtj8M4nMaXcVK7xGxjsqSxdKz xlt2KWnG9UQT5uP9xAj96HqVwi4OQ4JUaAQ6MRlsk/w8bVa2V8+lOHDuqLj2yceV HM7O9m4+rvhe15rbAB+PgqiZL4CARegqw+v4ZnF2fQftMPb/SZWyTXKCaopMtlD1 Fkkim6mBjSsVqV6LKKKp+S5LC9pkZkJykeEtgLCPbvC4Jm4WFUEXmKBdbAY0vRp3 xTARVmC0oMoFNOviWN77qYUbNjbG5Ozsz1vZ5TcQG7+C8b4f41En4ZVefdQt3Duv CYTYovqo3YYlAts2bdSdCmgeewpnjY4OJGl1zmvzFIJ1gJ5rxJ8= =/5Kv -END PGP SIGNATURE- --21081_ĵaÅ_Maj__2_15_03_52_UTC_2019--
Bug#928349: shellcheck: dubious diagnostics SC2188
--21134_ĵaÅ_Maj__2_15_03_54_UTC_2019 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Package: shellcheck Version: 0.5.0-3 Severity: normal Dear Maintainer, shellcheck complains on empty redirection: $ cat /tmp/foo.sh #!/bin/sh > /tmp/foo $ shellcheck /tmp/foo.sh > /tmp/foo ^-- SC2188: This redirection doesn't have a command. Move to its command (= or use 'true' as no-op). As discussed in #923478, empty redirection is posix-complaint, more concise way to say "true > /tmp/foo": create file if it does not exist and make sure it have zero size. Futhermore, shellcheck complains on such construction in bash mode, where it definitely works as intended. I think this diagnostics is incorrect. -- = Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction = -- --21134_ĵaÅ_Maj__2_15_03_54_UTC_2019 Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEhnHVzDbtdH7ktKj4SBLY3qgmEeYFAlzLBtoACgkQSBLY3qgm EebuEw/9Ef8RAl3ocRaWY+iJMSoM3qzbsiNXLFqSOx6RhQSOUQnuiBjR9uQxhr56 E/W2AMVPEGPtsZ7X32QYZYQP2SCQUOlHXYLoqedA6WVsQcRzLg9KrKey8c5XTgi8 luLsL/z3IE6Z+qMJ9ebi+qEQoKMBts3Q8yUX4YSli/B1cUbtqOOFKyYwpOYrqWSM 2QHKc6kVwHckvwDp9EScX4vrZVQD2LYYfH3Zz+6zKbuBRqMfluUXLsG/Yrdn3XP9 nTDVH5MZkD+NRZ75s870jQtU6AD8fJCQcKkPHVtBN69rrSTxgCmgLzsxd117WKGH cGa+ce0+Ss1pZfokEIe+CI9kaWT0BtqeYWh1ASZTlS/x9uaHmBrdJ2E5UK5zKbgj v+xkvP8AUUx/BjU2/TP2NBfnCnQdFz2CpVW+p/YJ+exN/gqMbF0e5UslIi+3pDoz 2dlj3scZH8AZzMRgxH0iTY1IhagctVUEEGnN1FajYJKaVGtymSfoAL/oH90oUB67 RnMdfoJ0A/VQV2E4kLJIo0Hh/54G+/kpQxTAWpGSfa4Ks7Ppsw3r/hQpKvNaHwXy K/tsz+2tkaVyqREOzSmjuZFnHG/ZZrG/rbaIBarK2czlnG1kO7e5NKeYoEgf9hsx kf98aJzZQ2H26siod/exLGgE8xiOyM1ES5DIhCaRrHjCwCQyMv8= =OOxU -END PGP SIGNATURE- --21134_ĵaÅ_Maj__2_15_03_54_UTC_2019--
Bug#926547: insserv: tests/run-tests are not used
[2019-04-28 21:05] Jesse Smith > > I have been looking into the issues with the insserv test scripts. There > are a few problems here, in brief: > [...] > > In other words, I think there is some difference in expectations between > what I think insserv should be doing and what the scripts we inherited > from downstream think insserv should be doing. I'm interested in getting > some feedback on this. If a script has no LSB header, should it be given > preset defaults, or should it be ignored? If the latter, I think we can > remove this series of tests. Which will mean there are just two errors > left for me to sort out. In my opinion, insserv should print warning about missing LSB headers and ignore them. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#928249: sysv-rc: fix styling
Source: sysvinit
Version: 2.94-2
Severity: wishlist
I hope to make running shellcheck part of `make test', and here is
little step in that direction. This patch fixes only suggestions, that
require no refactoring -- just more of double quotes.
Review is welcome.
From fe660a07d02f5ad46ec39924a5ab4354682a8fd0 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Mon, 29 Apr 2019 03:13:41 +
Subject: [PATCH] Fix style in /etc/init.d/rc script
Fix several style recommentations in /etc/init.d/rc script, suggested
by shellcheck(1).
---
debian/src/sysv-rc/rc | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/debian/src/sysv-rc/rc b/debian/src/sysv-rc/rc
index ed828cf5..025a1c54 100755
--- a/debian/src/sysv-rc/rc
+++ b/debian/src/sysv-rc/rc
@@ -38,7 +38,9 @@ stty onlcr 0>&1
# Now find out what the current and what the previous runlevel are.
+# shellcheck disable=SC2153 # this variable is set by /sbin/init
runlevel=$RUNLEVEL
+
# Get first argument. Set new runlevel to this argument.
[ "$1" != "" ] && runlevel=$1
if [ "$runlevel" = "" ]
@@ -117,16 +119,15 @@ case "$CONCURRENCY" in
startup() {
action=$1
shift
- scripts="$@"
- for script in $scripts ; do
- $debug "$script" $action
+ for script ; do
+ "$script" "$action"
done
}
;;
esac
# Is there an rc directory for this new runlevel?
-if [ -d /etc/rc$runlevel.d ]
+if [ -d "/etc/rc$runlevel.d" ]
then
case "$runlevel" in
0|6)
@@ -150,7 +151,7 @@ then
elif [ "$previous" != N ]
then
CURLEVEL=""
- for s in /etc/rc$runlevel.d/K*
+ for s in "/etc/rc$runlevel.d/K"*
do
# Extract order value from symlink
level=${s#/etc/rc$runlevel.d/K}
@@ -161,10 +162,10 @@ then
fi
CURLEVEL=$level
SCRIPTS=""
- for i in /etc/rc$runlevel.d/K$level*
+ for i in "/etc/rc$runlevel.d/K$level"*
do
# Check if the script is there.
- [ ! -f $i ] && continue
+ [ ! -f "$i" ] && continue
#
# Find stop script in previous runlevel but
@@ -198,7 +199,7 @@ then
else
# Now run the START scripts for this runlevel.
CURLEVEL=""
- for s in /etc/rc$runlevel.d/S*
+ for s in "/etc/rc$runlevel.d/S"*
do
# Extract order value from symlink
level=${s#/etc/rc$runlevel.d/S}
@@ -209,9 +210,9 @@ then
fi
CURLEVEL=$level
SCRIPTS=""
- for i in /etc/rc$runlevel.d/S$level*
+ for i in "/etc/rc$runlevel.d/S$level"*
do
- [ ! -f $i ] && continue
+ [ ! -f "$i" ] && continue
suffix=${i#/etc/rc$runlevel.d/S[0-9][0-9]}
if [ "$previous" != N ]
@@ -252,4 +253,3 @@ fi
trap - EXIT # Disable emergency handler
exit 0
-
pgp8b9fesZDrb.pgp
Description: PGP signature
Bug#928251: dh-sysuser: create reasonable descriptions for system users
Package: dh-sysuser Version: 1.3.3 Severity: wishlist Portage system in Gentoo implements bright idea: system users that comes with packages have description field (fifth in /etc/passwd) set to something like: "Created by Portage for package " Currently, dh_sysuser creates users with empty descriptions. I think, implementing described idea from Portage is clear improvement. pgprvIaoGlOJv.pgp Description: PGP signature
Bug#928252: surfraw: extra /bin/sh hanging in memory
Package: surfraw
Version: 2.3.0-0.2
Severity: wishlist
Dear Maintainer,
when I invoke "BROWSER=w3m surfraw duckduckgo my-search-term" I get
following pstree:
|-bash---surfraw---sh---duckduckgo---w3m---3*[{w3m}]
Notice, there is multiple /bin/sh processes hanging in memory while I am
browsing. At least first of them is caused by following code in
/usr/bin/surfraw (lines 671-678):
localelvidir=$(get_local_elvi_dir)
if [ -x "$localelvidir/$elvi" ]
then
sh -c "$localelvidir/$elvi $opts $searchterms"
elif [ -x "$elvidir/$elvi" ]
then
sh -c "$elvidir/$elvi $opts $searchterms"
else
There is no more code after those 'sh -c', so adding 'exec' would
improve code.
pgp12TXfYwh4d.pgp
Description: PGP signature
Bug#928250: sysv-rc: make depend on "lsb-base"
Source: sysvinit
Version: 2.94-2
Severity: wishlist
From d754b4a470bc7f5bf3b04beb0a18c6b2895f8f8a Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Mon, 29 Apr 2019 02:49:32 +
Subject: [PATCH] Make lsb-base hard dependency of sysv-rc
Since "initscripts" package already depends on "lsb-base", and sysv-rc
is used almost exclusively with "initscripts", there is no point in having
it soft (recommends) dependency on "lsb-base".
Now, with "lsb-base" as hard dependency of "sysv-rc", /etc/init.d/rc
script, provided by "sysv-rc", could be simplified: there is no longer
need to check, whether file /lib/lsb/init-functions exists.
---
debian/control| 3 +--
debian/src/sysv-rc/rc | 8 +---
2 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/debian/control b/debian/control
index 06c59aef..1e24709e 100644
--- a/debian/control
+++ b/debian/control
@@ -69,12 +69,11 @@ Description: System-V-like utilities
Package: sysv-rc
Architecture: all
Multi-Arch: foreign
-Recommends:
- lsb-base (>= 3.2-14),
Pre-Depends:
init-system-helpers (>= 1.25~),
Depends:
insserv (>> 1.12.0-10),
+ lsb-base (>= 3.2-14),
startpar,
sysvinit-utils (>= 2.86.ds1-62),
${misc:Depends},
diff --git a/debian/src/sysv-rc/rc b/debian/src/sysv-rc/rc
index d36ecc75..ed828cf5 100755
--- a/debian/src/sysv-rc/rc
+++ b/debian/src/sysv-rc/rc
@@ -56,13 +56,7 @@ if [ -f /etc/default/rcS ] ; then
fi
export VERBOSE
-if [ -f /lib/lsb/init-functions ] ; then
- . /lib/lsb/init-functions
-else
- log_action_msg() { echo $@; }
- log_failure_msg() { echo $@; }
- log_warning_msg() { echo $@; }
-fi
+. /lib/lsb/init-functions
#
# Check if we are able to use make like booting. It require the
pgp2A8GXIgk0l.pgp
Description: PGP signature
Bug#923449: runit: cgroups support
[2019-02-28 12:06] Dmitry Bogatov > Package: runit > Version: 2.1.2-23 > Severity: wishlist > > Just a thought. What about adding support of cgroups into invoke-run > script. It could create one cgroup for every service and set configure > its limits from config directory /etc/sv//cf-conf, for example. Some experiments had shown following wierd behaviour: 1. create new cgroup without any limits # mkdir /sys/fs/cgroups/foobar # cd /sys/fs/cgroups/foobar 2. try to put process it it # echo $$ > tasks bash: echo: write error: No space left on device 3. Now, perform magic I have searched for on web for hour or so: # echo 0 | tee cpuset.mems cpuset.cpus # echo $$ > tasks 4. Success! This is workaround I need to keep in mind when implementing cgroup support. Dear kernel maintainers, is intendend behaviour? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#923478: [Pkg-shadow-devel] Bug#923478: initscripts use unsafe `: >` shell command to create files
[2019-04-26 13:17] Chris Hofstaedtler > > According my experiments, it will. Even if I remove this code, something > > (login/getty, maybe?) still creates /var/run/utmp, root:root. > > Which init was used in your experiments? sysvinit-core. > If it was systemd or anything else honoring tmpfiles.d, > /lib/tmpfiles.d/systemd.conf has: > > F! /run/utmp 0664 root utmp - sysvinit-core does not read tmpfiles.d > > Thus I am asking your advice, whether it is safe to not create > > /var/run/utmp in initscripts. > > Depending on the init, removing initscripts is already allowed, and > it's likely that fresh installs do not even get it installed > anymore. True. But, as you mentioned, systemd uses its own way of creating this file. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#927702: RFS: python-aiosqlite/0.10.0-1 [ITP] -- sqlite library for Python 3 using asyncio
[2019-04-24 00:26] Benjamin Hof > On 23 April 2019, 12:36 +0000, Dmitry Bogatov wrote: > >... > > > I am looking for a sponsor for my package "python-aiosqlite": > > > > Is this package dependency of some application? > > Yes, postfix-mta-sts-resolver (#917366). I see. Please package test-dependency too, run tests and I will upload. Feel free to add me to X-Debbugs-CC if you need sponsor for test-dependency. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#923478: [Pkg-shadow-devel] Bug#923478: initscripts use unsafe `: >` shell command to create files
[2019-04-22 09:18] "Serge E. Hallyn" > > [ Dmitry Bogatov ] > > Dear login maintainers, currently we have following core executed during > > boot: > > > > # Create /var/run/utmp so we can login. > > true > /var/run/utmp > > if grep -q ^utmp: /etc/group > > then > > chmod 664 /var/run/utmp > > chgrp utmp /var/run/utmp > > fi > > > > It seems that system boots and works just fine without it. Are there any > > subtle reasons to keep creating /var/run/utmp in initscripts? > > Is the above pseudocode? If not, where is that code precisely? It is from /etc/init.d/bootmisc.sh from initscripts=2.94-3, lines 28-34. > Near as I can tell, if you do not create it, it will never exist, > and pututent entries will not be saved. According my experiments, it will. Even if I remove this code, something (login/getty, maybe?) still creates /var/run/utmp, root:root. Thus I am asking your advice, whether it is safe to not create /var/run/utmp in initscripts. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#926547: insserv: tests/run-tests are not used
[2019-04-06 19:14] Dmitry Bogatov > Package: insserv > Version: 1.18.0-2 > Severity: normal > > Dear upstream maintainer, > > during preparation of debian package of insserv=1.19.0 I discovered > issue with test suite (tests/run-tests), which was imported from > `debian/run-tests'. > [...] Friendly ping, Jesse. There is no urgency, but uploading insserv=1.19.0 requires getting it fixed. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
[2019-04-22 19:07] Alessandro Vesely > > On Mon 22/Apr/2019 11:55:55 +0200 Dmitry Bogatov wrote: > > I agree, better not to break things if we don't need to, but introducing > > complexity to support broken setup? > I thought that script was way less complex than insserv... Hm, seems I was prejudced. Sorry. Probably `insserv` really could be simplified by replacing with high-level language implementation; but it is not for me to decide. Probably you want to propose such change to insserv's upstream. He is subscribed to this list, I believe, but you may wish to report it separately. History knows precendends: TexInfo >= 5.0 was succesfully reimplemented in Perl instead of C. > > Cycled dependencies or otherwise incoherent dependencies is broken > > setup. Fix it. We already discussed how to fix it. Asking to support it > > is like asking to support situation, when dependency of your package is > > removed by `dpkg -r'. > > Let me just note, in passing, that you're assuming any script belongs to > some package. What if a simple-minded user wants to write "Hello world" > on every boot? Normally, $ cat /etc/rc.local #!/bin/sh echo "Hello world" but also you can modify any script in /etc/init.d/, so you will get your "Hello world" text printed at any moment of boot process. Modifications will be preserved between upgrades, and you will even have option to merge your changes and Debian ones. > Similarly, LSB defines installation of scripts, and casually mentions rc > as an example implementation. Given that the implementation can > actually host more than the specification assumes, why artificially > limit it? Not artificially, just keeping scope of program in check. > I'd never complicate things in order to support unspecified martians. > The point is building every time from scratch, rigidly enjoining specs, > like it or lump it, versus an incremental, tolerant, minimal changes > operation. What is the point of "incremental, tolerant, minimal changes operation"? C compiler always builds .o file from source file always afresh, and it reduces its complexity, and insserv(8) can be seen as compiler from content of /etc/init.d/, /etc/insserv/ and /etc/insserv.conf to /etc/rc[0-6].d The only possible reason to attempt reusing existing content of /etc/rc[0-6].d is perfomance, and it does not apply. I argue, that isserv(8) is compiler, not build tool like make(1), since it is impossible to separate processing of any individual file from rest of them: /etc/init.d/, /etc/insserv/ and /etc/insserv.conf together are single input. It is possible to consider each /etc/rc[0-6].d as separate output, but it is useless. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#927702: RFS: python-aiosqlite/0.10.0-1 [ITP] -- sqlite library for Python 3 using asyncio
[ Benjamin Hof ] > I am looking for a sponsor for my package "python-aiosqlite": Is this package dependency of some application? > Alternatively, one can download the package with dget using this > command: > > dget -x > https://mentors.debian.net/debian/pool/main/p/python-aiosqlite/python-aiosqlite_0.10.0-1.dsc Debianization looks fine, but it is quite unfortunate, that tests can't be run. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#927254: [Pkg-javascript-devel] Bug#927254: libjs-vue-router: ships node module instead of browser one
[2019-04-19 07:03] Xavier > [ Dmitry Bogatov ] > > I am working on packaging Laminar CI system, and libjs-vue-router is one > > of its dependencies. Upstream build system of Laminar downloads its > > dependencies from web, but to comply with Policy, I patched it to use > > local files. Unfortunately, it did not work. > > > > Upstream author of Laminar (in CC) kindly provided following information: > > > > OK this is a problem. It looks like the libjs-vue-router package is not > > really a pure javascript package but actually a node.js one (probably > > should be named node-vue-router). It even lists nodejs in its > > dependencies: > > https://packages.debian.org/sid/libjs-vue-router > > [...] > > Provided files are not node-* ones but recompiled using rollup. Could > you check if Laminar works well with > https://unpkg.com/vue-router@3.0.2/dist/vue-router.js file ? (same > version than in Buster) Yes, file from this URL is OK. Is it present in some Debian package? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#927740: rcs-blame: home is gone
Package: rcs-blame Severity: wishlist Dear Maintainer, upstream web site of this software is gone: 404. Please consider removing misleading Homepage: field. pgpmSTlSo1AYe.pgp Description: PGP signature
Bug#927283: RFS: lebiniou/3.31-1 -- displays images that evolve with sound
[2019-04-18 13:21] Olivier Girondel > On 4/18/19 12:24 PM, Dmitry Bogatov wrote: > > Looks fine. Are you sure you want to upload into unstable now, during > > freeze? It may cause inconvenience should need to fix RC bug in > > previous version arise. > > Hi Dmitry, > No problem, this can wait. I was not implying that I refuse to upload. I can upload as-is, into unstable (but consider possible interactions with release-team) or you can s/unstable/experimental/ and I will upload to experimental. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
[2019-04-18 18:30] Alessandro Vesely > On Thu 18/Apr/2019 12:43:24 +0200 Ian Jackson wrote: > > Dmitry Bogatov writes: > >> > >> As far as I know, "A depends B, B depends A" situation is called > >> RC-critical bug. > > > > If shipped by Debian but it can perhaps arise due to old packages, > > ad-hoc packages, etc. I agree that it's wrong but ISTM that it is > > better not to break things if we don't need to. > > > > But I think the current behaviour of insserv in this situation is to > > bomb out completely and refuse to operate, isn't it ? So it already > > fails to disturb the existing symlinks ? > > At least, that's what happens at mine. I had to write a quick script to > overcome that, http://www.tana.it/sw/fix-init/. I agree, better not to break things if we don't need to, but introducing complexity to support broken setup? Cycled dependencies or otherwise incoherent dependencies is broken setup. Fix it. We already discussed how to fix it. Asking to support it is like asking to support situation, when dependency of your package is removed by `dpkg -r'. > > As for "stable sort": > > > > So IMO if someone wants to send a patch which improves the algorithm > > so that it preserves more of the existing link ordering, when > > right now it doesn't care, we ought to consider it. (We'd want to > > be sure it didn't have any meaningfully different behaviour in > > "normal" configurations.) > > Rather than a patch, I'd consider an alternative executable. The link above > displays a man page for the script. I'm not advocating that script, as it has > many defects. However, I like its man page and its options. I don't think You can try introducing new package into debian: insserv-with-support-of-inconsistent-scripts and make it Provides: insserv. > > Note that the existing scheme parallelises things when the > > dependencies permit, and we should not take a patch which fails to > > parallelise things just because the existing links aren't parallel. > > Here's a point I had never considered. Perhaps, that's because I tend to boot > very sparingly --even on laptops, since suspend works well enough. I accept > parallelism can be a very important point for several people. An instance of > diversity? Data point: I do not care much of speed of boot (as long it is not 90s), and I do not care at all of support for inconsistent LSB dependencies. PS. About services starting before you can see config. There is /sbin/rc.policy mechanism. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#927363: RFS: urlwatch/2.17-1
[2019-04-18 15:30] Maxime Werlen > I am looking for a sponsor for my package "urlwatch" > > * Package name: urlwatch >Version : 2.17-1 >Upstream Author : Thomas Perl > * URL : https://thp.io/2008/urlwatch/ > * License : BSD-3-clause >Section : web > > It builds those binary packages: > urlwatch - monitors webpages for you > > To access further information about this package, please visit the > following URL: > https://mentors.debian.net/package/urlwatch > > Alternatively, one can download the package with dget using this command: > dget -x > https://mentors.debian.net/debian/pool/main/u/urlwatch/urlwatch_2.17-1.dsc > > More information about urlwatch can be obtained from > https://github.com/thp/urlwatch. > > Changes since the last upload: > > urlwatch (2.17-1) unstable; urgency=medium > > * New upstream release > * Handling .gitignore properly in d/.gitignore Into unstable? Are you sure? During freeze we usually upload into experimental, unless you are going to get unblock from release team. Otherwise fine. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#926471: lintian/patch: check that daemons have init.d script
--27303_ĵaÅ_Apr_18_10_24_27_UTC_2019
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Here is prelimitary patch, that implement the check. It seems to affect
t/tags/checks/init.d/init.d-lsb-depends-nonrel/ check, and, maybe,
something else -- I did not run whole test suite.
=46rom 8717235c0e585b758130e576088a3b670f92be7f Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Thu, 18 Apr 2019 10:13:26 +
Subject: [PATCH] Check that daemons have init.d script
Ref: policy 9.11
Closes: #926471
---
checks/init.d.desc | 10 ++
checks/init.d.pm | 16
.../init.d-missing-script/debian/bar.service | 0
.../init.d-missing-script/debian/control.in | 16
.../init.d/init.d-missing-script/debian/install | 3 +++
.../init.d/init.d-missing-script/debian/rules| 4
.../init.d/init.d-missing-script/debian/run | 0
t/tags/checks/init.d/init.d-missing-script/desc | 7 +++
.../checks/init.d/init.d-missing-script/output | 4
9 files changed, 60 insertions(+)
create mode 100644 t/tags/checks/init.d/init.d-missing-script/debian/bar.s=
ervice
create mode 100644 t/tags/checks/init.d/init.d-missing-script/debian/contr=
ol.in
create mode 100644 t/tags/checks/init.d/init.d-missing-script/debian/insta=
ll
create mode 100755 t/tags/checks/init.d/init.d-missing-script/debian/rules
create mode 100644 t/tags/checks/init.d/init.d-missing-script/debian/run
create mode 100644 t/tags/checks/init.d/init.d-missing-script/desc
create mode 100644 t/tags/checks/init.d/init.d-missing-script/output
diff --git a/checks/init.d.desc b/checks/init.d.desc
index d1873805d..632177b35 100644
--- a/checks/init.d.desc
+++ b/checks/init.d.desc
@@ -372,6 +372,16 @@ Info: The given init script appears to contain content=
from the
Please double-check the script and/or replace it with content suitable to
this binary package.
=
+Tag: init.d-missing-script
+Severity: important
+Certainty: certain
+Ref: policy 9.11
+Info: The package provides daemon, but contains no init.d script
+ The package contains file for running service under alternative
+ init system, but no mandanory init.d script.
+ .
+ See init-d-script(5) for one of possible ways writing init.d scripts.
+
Tag: init.d-script-should-always-start-service
Severity: important
Certainty: possible
diff --git a/checks/init.d.pm b/checks/init.d.pm
index 0d59d79b5..557eac05f 100644
--- a/checks/init.d.pm
+++ b/checks/init.d.pm
@@ -86,6 +86,8 @@ sub run {
=
my (%initd_postinst, %initd_postrm);
=
+check_missing_script($info);
+
# read postinst control file
if ($postinst and $postinst->is_file and $postinst->is_open_ok) {
my $fd =3D $postinst->open;
@@ -502,6 +504,20 @@ sub check_defaults {
return;
}
=
+# Check for missing init.d script, when equivalent for alternative init
+# system is present.
+sub check_missing_script {
+my ($info) =3D @_;
+for my $file ($info->sorted_index) {
+my $service;
+if ($file =3D~ m,etc/sv/([^/]+)/run$, or
+$file =3D~ m,lib/systemd/system/(.*)\.service,)
+{ $service =3D $1; } else { next; }
+tag 'init.d-missing-script', $file
+unless $info->index_resolved_path("/etc/init.d/${service}");
+}
+}
+
1;
=
# Local Variables:
diff --git a/t/tags/checks/init.d/init.d-missing-script/debian/bar.service =
b/t/tags/checks/init.d/init.d-missing-script/debian/bar.service
new file mode 100644
index 0..e69de29bb
diff --git a/t/tags/checks/init.d/init.d-missing-script/debian/control.in b=
/t/tags/checks/init.d/init.d-missing-script/debian/control.in
new file mode 100644
index 0..f2a6964cb
--- /dev/null
+++ b/t/tags/checks/init.d/init.d-missing-script/debian/control.in
@@ -0,0 +1,16 @@
+Source: {$source}
+Priority: optional
+Section: mail
+Maintainer: {$author}
+Standards-Version: {$standards_version}
+Build-Depends: {$build_depends}
+Rules-Requires-Root: no
+
+Package: {$source}
+Architecture: {$package_architecture}
+Depends: $\{misc:Depends\}
+Description: Package with daemon, but no init.d script
+ This is a test package designed to exercise some feature or tag of
+ Lintian. It is part of the Lintian test suite and may do very odd
+ things. It should not be installed like a regular package. It may
+ be an empty package.
diff --git a/t/tags/checks/init.d/init.d-missing-script/debian/install b/t/=
tags/checks/init.d/init.d-missing-script/debian/install
new file mode 100644
index 0..db29ac80e
--- /dev/null
+++ b/t/tags/checks/init.d/init.d-missing-script/debian/install
@@ -0,0 +1,3 @@
+# Actual content does not matter, Lintain checks only for file names.
+debian/bar.service /lib/systemd/system/
+debian/run /etc/sv/foo/
diff --git a/t/tags/checks/init.d/init.d-missing-script/debian/rules b/t/ta=
gs/checks/init.d/init.d-m
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
[2019-04-17 18:02] Alessandro Vesely > On Wed 17/Apr/2019 00:44:26 +0200 Dmitry Bogatov wrote: > > Right now insserv implements little more than topological sort. You can > > modify relations between scripts by editing LSB headers. What do you > > mean 'adjusting links without subverting existing order'? Mind to provide > > example? > > > I just meant respecting the existing order, either if possible or if a fix is > not at all obvious. Suppose A requires B and B requires A, a circular loop > which is somehow resolved by having S10A S20B. Now, you want to insert links > for C, which is new. If C requires B, you can insert it at S21C, even if C > doesn't require A. That is, assume that the existing configuration works. As far as I know, "A depends B, B depends A" situation is called RC-critical bug. > I recall having seen all links renumbered as 01, 02, 03, ... On the machine > I'm writing from now --a client where the boot sequence was never tampered > with-- links are numbered with gaps. I see several 01's, a single 02, then > 14, > 16, ... Perhaps unconditional renumbering was changed since I posted that > bug? On my system no gaps: 01, 02, 03, 04, 05, 06 in rc2.d/ > To edit LSB headers may make sense for one's own scripts. Arbitrary > insserv overrides don't seem to be the right thing to do... Or is it > customary? If you have special needs -- it is okay. If ordering is wrong -- report bug. The whole idea of Debian is to ship things that work. > Bottom line, I've been trying to recover some of the flexibility we > had before LSB's. I know that train has left many years ago... To be honest, I have rather basic knowledge, how things worked before LSB. But as you describe it, manual moving symlinks feels like manual editing output of `gcc'. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#927283: RFS: lebiniou/3.31-1 -- displays images that evolve with sound
[2019-04-17 12:33] Olivier Girondel > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "lebiniou": > > * Package name: lebiniou >Version : 3.31-1 >Upstream Author : Olivier Girondel > * URL : https://biniou.net > * License : GPL-2+ >Section : graphics > > It builds this binary packages: > > lebiniou - displays images that evolve with sound Looks fine. Are you sure you want to upload into unstable now, during freeze? It may cause inconvenience should need to fix RC bug in previous version arise. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#926306: RFS: socklog/2.1.0-9
[2019-04-16 19:10] Mathieu Mirmont > Both issues fixed, I re-uploaded the package to mentors (same links). Uploaded. For next upload, please, take a look at following: * in `debian/rules' you skip dh_dwz step. Please write comment why. * in socklog-init init script you mix tabs and spaces. It is of no importance to Policy, but looks wierd. * file a bug aganist Lintian and either add comment into 'd/socklog.lintian-override', or, hopefully, this file will be unneeded by time of next upload of `socklog'. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#927254: libjs-vue-router: ships node module instead of browser one
Package: libjs-vue-router Version: 3.0.2+ds-1 Severity: normal Dear Maintainer, I am working on packaging Laminar CI system, and libjs-vue-router is one of its dependencies. Upstream build system of Laminar downloads its dependencies from web, but to comply with Policy, I patched it to use local files. Unfortunately, it did not work. Upstream author of Laminar (in CC) kindly provided following information: OK this is a problem. It looks like the libjs-vue-router package is not really a pure javascript package but actually a node.js one (probably should be named node-vue-router). It even lists nodejs in its dependencies: https://packages.debian.org/sid/libjs-vue-router I tried all the variations under /usr/share/javascript/vue-router, all fail in some variation of the same issue. I don't know how it worked for me last time, probably I made a mistake and accidentally used the "browser" vue-router js file. If you use the latest "browser" version of vue-router, available here: https://unpkg.com/vue-router@3.0.3/dist/vue-router.js and linked from their installation page: https://router.vuejs.org/installation.html#direct-download-cdn then it works. So I think what should happen, at least ideally, is that the existing libjs-vue-router package should be renamed node-vue-router (and it should not symlink from /usr/share/javascript/vue-router to ../../lib/nodejs/vue-router/dist, and it should depend on node-vue not libjs-vue), and a new package named libjs-vue-router should be created containing the "browser" version. This would seem to be consistent with Debian Javascript packaging as I understand it I have no expertise to comment on this, but can you please consider this argument? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction -- pgpf7qHlYY1XP.pgp Description: PGP signature
Bug#926306: RFS: socklog/2.1.0-9
[2019-04-13 11:11] Mathieu Mirmont
> On Fri, Apr 12, 2019 at 05:22:35PM +0000, Dmitry Bogatov wrote:
> > [2019-04-10 23:48] Mathieu Mirmont
> > >
> > > part 1 text/plain 434
> > > On Wed, Apr 10, 2019 at 08:20:30AM +, Dmitry Bogatov wrote:
> > > > You can repack it as new upstream version. New version would be
> > > > something like `2.1.0+repack-1'. Do not forget add clarification into
> > > > Debian.source.
> > >
> > > I've updated the package and uploaded to mentors:
> > >
> > > https://mentors.debian.net/package/socklog
> > > https://mentors.debian.net/debian/pool/main/s/socklog/socklog_2.1.0+repack-1.dsc
> >
> > Lintian (2.11.0) warnings:
> >
> > W: socklog: missing-versioned-depends-on-init-system-helpers
> > postinst:152 "update-rc.d defaults
> -disabled" needs i
> > nit-system-helpers >= 1.50
>
> Embarassingly I don't know how to get rid of this one. I've added a
> depencency on init-system-helpers (>= 1.50) naturally but the warning
> remains.
>
> Since ${misc:Pre-Depends} already includes init-system-helpers (>=
> 1.54~) I added lintian overrides. It's a bit dirty though, and the
> line number makes it a moving target. I'll fix the line numbers in the
> lintian overrides but if you know how to fix this in a better way I'm
> all ears.
I see. I suggest you to submit bug aganist Lintian, but in mean time I
am fine uploading with overrides. It may be useful to add reference to
that bug in override comment.
> > Oh, and extremely minor notice: in `debian/control' you align fields
> > with tabs. It does not look pretty, if tabstop is not 8. What about
> > expand(1)?
>
> Ah yeah sorry, I'll untabify this.
Thank you. By the way, you know about wrap-and-sort(1)?
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#913027: ITP: hblock -- Improve your security and privacy by blocking ads, tracking and malware domains
[ Kun-Hung Tsai ] > > Hi Héctor, I am intending to package this good work. > > Is it OK to reference files you create for debian package > > under resources/deb? [2019-01-20 14:05] Héctor Molinero Fernández > Hi, I created those files as an experiment to package hBlock. The generated > package works correctly, however, I don't know the best practices for > creating an official package for Debian. > > I would be happy to help in any way I can. Kun-Hung Tsai, are you still working on it? I probably have some free cycles to help/review/sponsor upload, if you wish. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
[2019-04-15 09:14] Alessandro Vesely > I get this: > insserv: There is a loop between service umountnfs and rsyslog if stopped > insserv: loop involving service rpcbind at depth 3 > insserv: loop involving service umountnfs at depth 2 > insserv: loop involving service gdm3 at depth 1 > insserv: loop involving service sendsigs at depth 2 > insserv: loop involving service networking at depth 7 > insserv: exiting now without changing boot order! > > I run fixinit instead > http://www.tana.it/sw/fix-init/ > >> Now, as to whether this should be considered a bug or a desired effect > >> is open to debate. On the one hand it is understandable people might not > >> want insserv to overwrite their changes. On the other hand, in my case > >> insserv is fixing a mistake in my symlinks, and adjusting them to match > >> their LSB headers. > > Running interactively in some cases may make sense. Instead, insserv is run > every time one installs a package which includes a daemon, automatically. > > Nowadays, stable sort algorithms are really widespread. Adjusting links > without subverting their existing order is not that hard. I am not going to implement it, but even as user I fail to understand your proposal. Right now insserv implements little more than topological sort. You can modify relations between scripts by editing LSB headers. What do you mean 'adjusting links without subvering existing order'? Mind to provide example? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#923478: initscripts use unsafe `: >` shell command to create files
[2019-04-14 13:35] Cristian Ionescu-Idbohrn > On Sun, 14 Apr 2019, Dmitry Bogatov wrote: > > > > Definitely. But default one is from bin:util-linux. > > On my sid/unstable: > > # dpkg -S /bin/login > login: /bin/login You are right, it is from src:shadow. > > So I question, how much of this code is actually necessary: > > > > * group 'utmp' exists on bare system, so conditional is not needed. > > * if /var/run/utmp is missing, nothing bad seems to happen, so does > >this code is needed at all? > > > > Opinions? > > IMO, less code is better. I didn't loog at the source. But I can > see this: > > # strings /bin/login | egrep 'utmp|faillog|/' > /lib64/ld-linux-x86-64.so.2 > /usr/share/locale > No utmp entry. You must exec "login" from the lowest level "sh" > [...] I took a look at source. It seems that this error may only happen if UID != 0. I'd better add login maintainers into thread. Dear login maintainers, currently we have following core executed during boot: # Create /var/run/utmp so we can login. true > /var/run/utmp if grep -q ^utmp: /etc/group then chmod 664 /var/run/utmp chgrp utmp /var/run/utmp fi It seems that system boots and works just fine without it. Are there any subtle reasons to keep creating /var/run/utmp in initscripts? > > PS. Cristian, it seems I did not enough research prior asking you to > > make patch and caused labour wasted. I am sorry. > > No worries. Still, I would be cautious. That redirection (with or > without a command prefix) is still questionable, as it _truncates_ the > file (as opposed to just touching it). It is under /var/run, which is tmpfs, so it is okay. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#926901: bcron: init.d script and runit service conflict
[2019-04-12 01:32] Mathieu Mirmont > Package: bcron > Version: 0.11-8 > Severity: important > > Dear Maintainer, > > The bcron package provides both init.d scripts and runit services. > When installing it in a system where runsvdir is running (for instance > via runit-init or runit-sysv), then the daemons are started by both > runsvdir and by update-rc.d: > > $ pstree > bash-+-daemon---bcron-update > |-daemon---bcron-sched---bcron-exec > |-daemon---unixserver > |-pstree > `-runsvdir-+-runsv-+-bcron-update > | `-svlogd > |-runsv-+-svlogd > | `-unixserver > `-runsv-+-bcron-sched---bcron-exec > `-svlogd > > This issue is most likely present in all packages that ship both > init.d scripts and runit services, I aritrarily picked bcron to report > the bug, please feel free to re-assign. No, usual behaviour in this case is that init.d script is started first, and runscript is keep trying to start daemon too, but fails, since daemon refuses to start second instance of itself. It is no good too, of course. I believe this bug will be fixed as effect of #924769 (not marked as resolved, due my typo in changelog), which is now in Archives as runit=2.1.2-28/experimental. With #924769 in effect, runscript will stop init.d instance before starting its own. Mind to check? > I suspect that a fix could be implemented in invoke-rc.d by making it > aware of runsvdir, similarly to how it is already aware of systemd and > openrc? Yes, it is planned, but pushing changes to init-system-helpers is quite long and painful process for me for social reasons. If you are willing to help, you are more then welcome. Take a look at #924132. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#711853: insserv: Design bug: rcN.d unstable and not, maintainable
control: tags -1 +wontfix +moreinfo [2019-04-11 10:54] Jesse Smith > >> When update-rc.d calls insserv, the rcN.d directories are rebuilt > >> without taking into consideration any adjustment that might have > >> been set up locally. That seems to be done on the assumption that > >> the dependencies coded in the LSB blocks are universally accurate. > >> Now, LSBs are a great improvement over numeric priorities, but to > >> hamper local system tuning, which is not necessarily related to > >> LSBs, IMHO is an insult to the legendary versatility of SysV init. > > > > I believe it is not how things work now. Last time I checked, call > > `insserv foo` does not update any links to `foo' if there is already at > > least one of them. > > > > @Jesse, am I right? > > I just ran a quick test and can confirm that if I have an existing link > to a service, for example /etc/rc5.d/S05bluetooth, then running the > command "insserv bluetooth" will attempt to remove the old symlink and > replace it with one that conforms to the LSB headers. In my case, > removing the original link and creating /etc/rc5.d/S04bluetooth. > > Now, as to whether this should be considered a bug or a desired effect > is open to debate. On the one hand it is understandable people might not > want insserv to overwrite their changes. On the other hand, in my case > insserv is fixing a mistake in my symlinks, and adjusting them to match > their LSB headers. > > My thought on this is if someone wants to improve their start-up routine > it makes more sense for them to edit their script's LSB header and > re-run insserv rather than editing links by hand. Thank you Jesse. Sounds reasonable. Dear submitter, please consider, whether your issue could be solved by editing LSB headers and if not, why. So far, tagging as wontfix and moreinfo, subject to close-on-timeout. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#923478: initscripts use unsafe `: >` shell command to create files
[2019-04-11 14:45] Cristian Ionescu-Idbohrn
>
> part text/plain1537
> On Thu, 11 Apr 2019, Dmitry Bogatov wrote:
> >
> > Warning message and make do_start return 1, I guess.
>
> This is what I can come up with:
Thank you.
> + else
> + echo "Error: failed to truncate $utmp" >&2
> + exit 4
4 -- "insufficent privilegies". I believe, it is better to return 1
("generic or unspecified error"), but see futher discussion below.
Oh, and you skip 'rm -f' statements in case of error with /var/run/utmp.
I would get quite surprised, should I get error that root has
insufficent privilegies.
I am sorry to ping-pong your patch, but I feel it wrong to amend patches
(change code, keep attribution) of others.
> > By the way, is
> >
> > # Create /var/run/utmp so we can login
> >
> > comment still accurate? I am confident, that `fgetty' does not check
> > for presence of /var/run/utmp, and at glance, I can't find code in
> > src:util-linux, that would prevent login when /var/run/utmp is
> > absent.
>
> I really can't say. I suppose it depends on which `login' is used?
Definitely. But default one is from bin:util-linux.
I just did some testing on my virtual machine of Debian 9 (stable):
* I logged in as root on tty1, deleted /var/run/utmp and tried to login
on tty2. I succeed to login as both root and non-root.
* I commented out from bootmisc.sh all code, that works with
/var/run/utmp and rebooted. There were no errors, and I logged in
just fine.
Something already created /var/run/utmp root:root, 644.
So I question, how much of this code is actually necessary:
* group 'utmp' exists on bare system, so conditional is not needed.
* if /var/run/utmp is missing, nothing bad seems to happen, so does
this code is needed at all?
Opinions?
PS. Cristian, it seems I did not enough research prior asking you to
make patch and caused labour wasted. I am sorry.
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#923485: initscripts: Please make /etc/rc.local a conffile
control: tags -1 +confirmed control: reopen -1 control: retitle -1 upgrade sid->experimental modifies conffile [2019-04-10 11:55] Andreas Beckmann > Followup-For: Bug #923485 > Control: found -1 2.94-2 > > Hi, > > now piuparts complains about a modified conffile on upgrades from sid to > experimental. > > You need to compare /etc/rc.local.dpkg-old against all known md5sums of > variants previously installed by some package version, and delete it if > it matches one of them, s.t. it is "upgraded to the new version". > Only preserve the old one if it obviously contains user modifications. Any suggestions how can I make list of /all/ known md5sums? Or, wait, isn't md5sum of file installed by version in testing (which is going to be Buster) is enough? > >From the piuparts output: > > Setting up insserv (1.18.0-2) ... > insserv: FATAL: service mountdevsubfs has to exists for service hwclock > insserv: exiting now! Wierd. mountdevsubfs is dependency of hwclock, true, but why would it be missing? $ dpkg -S /etc/init.d/mountdevsubfs.sh initscripts: /etc/init.d/mountdevsubfs.sh $ apt-cache policy initscripts initscripts: Installed: 2.94-2 Candidate: 2.94-2 Version table: *** 2.94-2 100 1 http://cdn-fastly.deb.debian.org/debian experimental/main amd64 Packages 100 /var/lib/dpkg/status 2.93-8 500 500 http://cdn-fastly.deb.debian.org/debian testing/main amd64 Packages 500 http://cdn-fastly.deb.debian.org/debian sid/main amd64 Packages 2.91-1+devuan1.2 100 100 http://packages.devuan.org/devuan experimental/main amd64 Packages -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#926896: sysvinit-utils: pidof is unreliable
control: tags -1 +moreinfo [2019-04-11 20:55] Witold Baryluk > Package: sysvinit-utils > Version: 2.93-8 > Severity: important > > root@debian:~# echo; whoami; echo; ps aux | grep 'dd if'; echo; hd > /proc/41344/cmdline ; echo; ls -l /proc/413 > 44/exe; echo; pidof dd || echo "Not found"; echo; ls -l /proc/41344/exe I tried somthing similar, works fine: $ dd if=/dev/random of=/dev/null bs=64k ## on another tty $ pidof dd # YMMV 19329 So it seems there is nothing special in name 'dd'. We need more information. Can you reproduce problem? Can you reproduce problem as non-root? Does it specific to 'dd'? Can you provide typescript [script(1)] of how things go wrong on your computer? You use AppArmor. Does pidof have profile? Is there anything about pidof(1) in AppArmor logs? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#538304: insserv: start and stop in same runlevel
control: tags -1 +fixed-upstream [2019-04-11 17:50] Jesse Smith > > part text/plain1086 > On 4/11/19 7:43 AM, Dmitry Bogatov wrote: > > [2019-01-24 19:42] Jesse Smith > >> I'm looking into this bug in insserv and want to make sure I'm > >> understanding the issue correctly. As I read it, the problem is that if > >> the user specifies the same runlevel in both the Default-Start and > >> Default-Stop fields, insserv will set up the "Stop" symbolic link, but > >> will not complain about it? > >> > >> Ideally, insserv should probably still use this behaviour, but print a > >> warning that the same runlevels should not be listed in both the > >> Default-Start and Default-Stop fields. Is this a correct summary of the > >> above request? > > Yes, seems so. > > I have addressed this upstream. The next version of insserv will print a > warning when an init.d script has the same runlevel specified in the > Default-Start and Default-Stop fields. The output looks like this: > > insserv: Script bluetooth has overlapping Default-Start and > Default-Stop runlevels (2 3 4 5) and (0 1 3 6). This should be fixed. > > Apart from the warning, insserv functions as before. Thank you. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#926306: RFS: socklog/2.1.0-9
[2019-04-10 23:48] Mathieu Mirmont > > part 1 text/plain 434 > On Wed, Apr 10, 2019 at 08:20:30AM +0000, Dmitry Bogatov wrote: > > You can repack it as new upstream version. New version would be > > something like `2.1.0+repack-1'. Do not forget add clarification into > > Debian.source. > > I've updated the package and uploaded to mentors: > > https://mentors.debian.net/package/socklog > https://mentors.debian.net/debian/pool/main/s/socklog/socklog_2.1.0+repack-1.dsc Lintian (2.11.0) warnings: W: socklog: missing-versioned-depends-on-init-system-helpers postinst:152 "update-rc.d defaults-disabled" needs i nit-system-helpers >= 1.50 W: socklog: missing-versioned-depends-on-init-system-helpers postinst:165 "update-rc.d defaults-disabled" needs i nit-system-helpers >= 1.50 W: socklog: missing-versioned-depends-on-init-system-helpers postinst:178 "update-rc.d defaults-disabled" needs i nit-system-helpers >= 1.50 Oh, and extremely minor notice: in `debian/control' you align fields with tabs. It does not look pretty, if tabstop is not 8. What about expand(1)? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#926306: RFS: socklog/2.1.0-9
[2019-04-10 12:46] Mathieu Mirmont > > Are you sure you need "Depends: runit"? Maybe it is just me, but I > > thought that `socklog' is just an implementation of `syslog'. If > > so, hard dependency on bin:runit is quite heavyweight. > > It heavily relies on runsv and svlogd, that's how it splits files by > syslog service name. Essentially socklog is a data collector for svlogd. > > The alternative would be to re-implement runsv and svlogd by redirecting > the output of socklog to a file and using logrotate, but clearly that > would be a hack, it's not how it's meant to be run, and it would have > the risk of losing messages when logrotate kicks in. > > The dependency on runit is less risky than that. Also the dependency is > on runit alone, not on any of the runit-* packages that call runsvdir, > so it's quite lite. I see. Fine. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#926855: sysvinit: unused lintian overrides
--4588_ĵaÅ_Apr_11_10_43_30_UTC_2019 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Source: sysvinit Severity: wishlist Tags: patch Control: user kact...@debian.org Control: usertags -1 objections =46rom 47363719d13afc82a02d7ccbd0ce464aeaed7439 Mon Sep 17 00:00:00 2001 From: Dmitry Bogatov Date: Wed, 10 Apr 2019 22:49:58 + Subject: [PATCH] Remove unused lintian overrides --- debian/bootlogd.lintian-overrides| 1 - debian/initscripts.lintian-overrides | 5 - debian/source/lintian-overrides | 1 - 3 files changed, 7 deletions(-) delete mode 100644 debian/source/lintian-overrides diff --git a/debian/bootlogd.lintian-overrides b/debian/bootlogd.lintian-ov= errides index ff227d42..78f7a58c 100644 --- a/debian/bootlogd.lintian-overrides +++ b/debian/bootlogd.lintian-overrides @@ -7,4 +7,3 @@ bootlogd: init.d-script-missing-dependency-on-remote_fs etc= /init.d/bootlogd: req bootlogd: script-in-etc-init.d-not-registered-via-update-rc.d = bootlogd: init.d-script-missing-dependency-on-local_fs -bootlogd: init.d-script-depends-on-all-virtual-facility diff --git a/debian/initscripts.lintian-overrides b/debian/initscripts.lint= ian-overrides index e5dca6ac..15171e63 100644 --- a/debian/initscripts.lintian-overrides +++ b/debian/initscripts.lintian-overrides @@ -24,8 +24,3 @@ initscripts: script-in-etc-init.d-not-registered-via-upda= te-rc.d = initscripts: init.d-script-missing-dependency-on-local_fs initscripts: init.d-script-depends-on-all-virtual-facility - -# Init scripts, provided by bin:initscripts are explicitly whitelisted -# in `data/systemd/init-whitelist' by Lintian. The `brightness' script -# is very new, and not yet in that whitelist. -initscripts: missing-systemd-service-for-init.d-rcS-script brightness diff --git a/debian/source/lintian-overrides b/debian/source/lintian-overri= des deleted file mode 100644 index af2d30fe.. --- a/debian/source/lintian-overrides +++ /dev/null @@ -1 +0,0 @@ -sysvinit source: debian-watch-file-should-mangle-version --4588_ĵaÅ_Apr_11_10_43_30_UTC_2019 Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEhnHVzDbtdH7ktKj4SBLY3qgmEeYFAlyvGlIACgkQSBLY3qgm EeYCVw//czubr/DipuKqLpasG21TrZnnKUDMq7PkyLRMRgJVUzzD4ttd4le7BJHQ bEwJtayvLaLnEecDxhgsAXcVHQZWSs7lZePQJhrZQPpUkPysnzLf4yi0vbjfueyd HkXTFd1WfI4ii+w1LvlEvL2i7lUskUO9y9c97GMEMq8kslZ/AdfFiP7LtTp5svl3 O3aZJMX2Nu+zDub2LqsQXne0nUB6Lmk33jDB56WdUeicy+2ieKpynmsJRpvnF3S7 UjyI4uqQALudrYgD+E9f3JIvJPlwgNGSjdlvCGJmlchfL3MAnc53DJnGgW8cGfZx 3F5e13Zx9eeEEGn8yLVg3HWts0NxJGJIjyQx4J84F+fT6qNjQQ3617hElbky1vz5 DSeMr5bGmdj5Xjknn4U4uX5GLkZ2E74mpspuB7Sg2m5pPDCaugnw4psPUpBaoKNe jkLnAKpPjZfAUP4ouR7YPTuWevlpZ3TDmP6DpHYTFTgz1eydNkhelts/KArhXmLb kO+Mgx940PQGxdsV4wsfdZSUdxTIMNknrwRDqRYwjZCfTA2UW4G9U7YjSgwrqE7Z P+y6k8LFct9MFvZkP9eWsIIhxRr7R35/7shg6+899PBklhk7b5+zI2PQSqisqq7q ilM6k8SRv8jdRhE5jcdjnSqgcRaoJUawUiVfOkLjdKOGdt2fK7s= =4XkN -END PGP SIGNATURE- --4588_ĵaÅ_Apr_11_10_43_30_UTC_2019--
Bug#923478: initscripts use unsafe `: >` shell command to create files
[2019-04-08 20:20] Cristian Ionescu-Idbohrn > On Mon, 8 Apr 2019, Dmitry Bogatov wrote: > > [2019-04-07 10:52] Cristian Ionescu-Idbohrn > > > > > On Sat, 6 Apr 2019, Dmitry Bogatov wrote: > > > > > > The redirection in /etc/init.d/bootmisc.sh on line 29 is _not_ error > > > handled. Writing to a file can fail (for various reasons). > > > > > > OTOH, the redirection in /lib/init/bootclean.sh on line 22 _is_ error > > > handled. > > > > Good catch. Mind to send a patch into a separate bug? > > Sure. So, what do you want it to do when truncating /var/run/utmp > fails? > > 29 : > /var/run/utmp > 30 if grep -q ^utmp: /etc/group > 31 then > 32 chmod 664 /var/run/utmp > 33 chgrp utmp /var/run/utmp > 34 fi Warning message and make do_start return 1, I guess. By the way, is # Create /var/run/utmp so we can login comment still accurate? I am confident, that `fgetty' does not check for presence of /var/run/utmp, and at glance, I can't find code in src:util-linux, that would prevent login when /var/run/utmp is absent. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#926854: sysv-rc: remove check for .legacy-bootordering
--4520_ĵaÅ_Apr_11_10_43_23_UTC_2019 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Package: sysv-rc Version: 2.94-2 Severity: wishlist Tags: +patch Control: user kact...@debian.org Control: usertags -1 +objections =46rom 340c02c2d3ef1d9cad35129e2e7f1bf3f8993ff1 Mon Sep 17 00:00:00 2001 From: Dmitry Bogatov Date: Wed, 10 Apr 2019 16:35:32 + Subject: [PATCH] Remove check for .legacy-bootordering flag file With legacy bootordering gone in 2012, it is safe to remove check for /etc/init.d/.legacy-bootordering from /etc/init.d/rc script. --- debian/src/sysv-rc/rc | 3 --- 1 file changed, 3 deletions(-) diff --git a/debian/src/sysv-rc/rc b/debian/src/sysv-rc/rc index 57004020..d36ecc75 100755 --- a/debian/src/sysv-rc/rc +++ b/debian/src/sysv-rc/rc @@ -73,9 +73,6 @@ CONCURRENCY=3Dmakefile test -s /etc/init.d/.depend.boot || CONCURRENCY=3D"none" test -s /etc/init.d/.depend.start || CONCURRENCY=3D"none" test -s /etc/init.d/.depend.stop || CONCURRENCY=3D"none" -if test -e /etc/init.d/.legacy-bootordering ; then - CONCURRENCY=3D"none" -fi if grep -wqs concurrency=3Dnone /proc/cmdline; then CONCURRENCY=3D"none" fi -- = Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction = -- --4520_ĵaÅ_Apr_11_10_43_23_UTC_2019 Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEhnHVzDbtdH7ktKj4SBLY3qgmEeYFAlyvGksACgkQSBLY3qgm EeYaIA/9H7MnvQZL6BNvVEw32BJSH283kGRhf5j1sx0K1Jtt8KJyxy/zoZR17BxO ITPitw+ybfujQZzjuL+1Hti9BDynGWgTTiggOdt4uFd4JnJ2fLTkVK9ZdO5Y0mIh kT+EYwYP3jbx0Homy8S93s4hm6AlkW7yIzOg69fj1gaOXjfKKuUO1kckPZ+H/RZO N8iyE09nrUmRSekKjAEQwZwv7zTqNAlWb5RtRNHA1lR8HX7r580Zrl30Fo5STby5 gMuFMA5VDaLpWaKjI/BBZdrcLNm6VxozyJQUhldE284kbnwL+3A5RlF1oKMOI0N+ obQMYcqJ7408LED6R+5zbPX4I2wwdVBU2tj1JN9eDsJPoEqZunRGZmBY6Y1Ww7iP KsmmjET9+k34CYzv7prB5UsPSfPhtOLicMKcumvRtPHH9yeGOJF6fGF/X1lobGIm 22dmoiDNHY4x4vqodj3C5PVJfjRvR26bUPshYPA/v6PKqefSrjZXY48i2p+l7o0+ f2m5sUKkXOB+xBOe6d6ZkCAbWzo/A2ww1Z6fzI9Nif+GelbwVt9EIHwhFbqklASS U+O4S22nr4QOEH7F5D80+J0Bpve9lEUyXWmR3Vw18cgNBE83zjWsWhZQoGtaF1Ib ew7RWquVsMPtXmkb8eVNTyhobE71/NWyL9gKI3qzY/wfTAjj4v4= =AQmz -END PGP SIGNATURE- --4520_ĵaÅ_Apr_11_10_43_23_UTC_2019--
Bug#374039: #374039 shutdown -h -H: warn that then cannot poweroff perhaps
control: tags -1 +fixed-upstream [2019-04-08 12:54] Jesse Smith > On 4/8/19 12:38 PM, Dmitry Bogatov wrote: > > control: tags -1 +upstream > > > > [ Please keep attribution ] > > > > [2019-04-07 11:12] Jesse Smith > >> > >> That is what halt means - to stop running the system without powering > >> off. > > Maybe, but many of us are accustomed that /sbin/halt turns off the computer, > > so here comes confusion. > > That is certainly true, but I'd like to point out that /sbin/halt only > turns off the computer because Debian modifies halt's behaviour. If you > run /sbin/halt without Debian's modifications, the traditional action > (stop without powering off) occurs. I'd almost consider this a bug since > /sbin/halt should be used to stop the system while /sbin/poweroff should > be used to, well, turn off the power to the system. I believe at least in some of RPM-based distributions /sbin/halt also turns off computer. But it is just outdated memories from my studentship times :) > >> Halting is often used to run through the shutdown process and leave > >> output on the screen for debugging purposes. Or when you want the OS to > >> stop, but leave the power on. There is no negative side-effect to using > >> the -H option, no loss of data. There isn't any reason to print an extra > >> warning. > > Okay, what about including this explanation into manpage? I know, Unix > > is about sharp tools, but before I started working on sysvinit, I > > believed, that "halt == turn-off", so extra explanation, that it is > > different things would be nice to user. > > I'm in favour of this change and can expand on the explanation in the > manual page for the next release. Thank you! -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#711853: insserv: Design bug: rcN.d unstable and not maintainable
control: tags -1 +moreinfo [2013-06-10 13:53] Alessandro Vesely > When update-rc.d calls insserv, the rcN.d directories are rebuilt > without taking into consideration any adjustment that might have > been set up locally. That seems to be done on the assumption that > the dependencies coded in the LSB blocks are universally accurate. > Now, LSBs are a great improvement over numeric priorities, but to > hamper local system tuning, which is not necessarily related to > LSBs, IMHO is an insult to the legendary versatility of SysV init. I believe it is not how things work now. Last time I checked, call `insserv foo` does not update any links to `foo' if there is already at least one of them. @Jesse, am I right? Dear submitter, can you please re-evaluate, whether problem still present with insserv=1.18.0-2 and dependency-based boot system? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#538304: insserv: start and stop in same runlevel
[2019-01-24 19:42] Jesse Smith > I'm looking into this bug in insserv and want to make sure I'm > understanding the issue correctly. As I read it, the problem is that if > the user specifies the same runlevel in both the Default-Start and > Default-Stop fields, insserv will set up the "Stop" symbolic link, but > will not complain about it? > > Ideally, insserv should probably still use this behaviour, but print a > warning that the same runlevels should not be listed in both the > Default-Start and Default-Stop fields. Is this a correct summary of the > above request? Yes, seems so. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#926306: RFS: socklog/2.1.0-9
[2019-04-08 01:03] Mathieu Mirmont > On Sat, Apr 06, 2019 at 07:13:56PM +0000, Dmitry Bogatov wrote: > > > > [2019-04-04 13:30] Mathieu Mirmont > > > > * I know, it is pain, but there should be init.d script. You may want to > > > > take a look at bcron=0.11-8. > > > > > > Sure, no worries. How about systemd service files? It makes little sense > > > to run socklog along with systemd I think, but for the principle it may > > > be required to profile service files. What do you think? > > > > Up to you. Presence of systemd unit files is not mandated by Policy, > > unlike init.d scripts. > > Done, the init scripts call daemon(1) and runsv(1) and they work > pretty nicely. Are you sure you need "Depends: runit"? Maybe it is just me, but I thought that `socklog' is just an implementation of `syslog'. If so, hard dependency on bin:runit is quite heavyweight. > > > > I believe there should be separate sysuser for socklog-* services. > > > > Ideally, separate sysuser for /every/ from socklog-* service, but I do > > > > not know, whehter it is possible. > > > > > > Yeah good point. I tend to think that a single user for all socklog-* > > > services would be enough, but if you prefer I can add one user per > > > service. > > > > Yes, I'd prefer as much separation, as possible. > > Done, one user per service. I see. Thank you. > There is one more issue that I noticed this weekend: the orig.tar.gz > file that is registered in debian archives is not the same as the > upstream tarball. It is in fact a tarball of the upstream tarball > (!). I don't know why it's done this way, and it pretty much breaks > breaks source format 3.0 (quilt) because I can't get dpkg-source to > unpack the tarball before applying the patches. Do you know how to > deal with that? You can repack it as new upstream version. New version would be something like `2.1.0+repack-1'. Do not forget add clarification into Debian.source. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#926776: xdm: add support for runit init system
Package: xdm
Version: 1:1.1.11-3
Severity: wishlist
Tags: +patch
User: ru...@packages.debian.org
Usertags: +runscript
Dear Maintainer,
please consider applying following patch that add support for runit init
system.
From a42aabe7d6d48f7d8d51cb4b9e5b6c0ce84c881b Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Mon, 8 Apr 2019 17:37:12 +
Subject: [PATCH] Add runscript
---
debian/control | 2 ++
debian/rules | 1 +
debian/xdm.runit | 1 +
debian/xdm.runscript | 2 ++
4 files changed, 6 insertions(+)
create mode 100644 debian/xdm.runit
create mode 100755 debian/xdm.runscript
diff --git a/debian/control b/debian/control
index 4886b7d..eba8144 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,7 @@ Maintainer: Debian X Strike Force
Uploaders: Cyril Brulebois
Build-Depends:
debhelper (>= 9),
+ dh-runit (>= 2.8.8),
dpkg-dev (>= 1.16.1),
pkg-config,
libxmu-dev (>= 1:1.0.1),
@@ -35,6 +36,7 @@ Depends:
x11-xserver-utils,
procps,
Provides: x-display-manager
+Breaks: ${runit:Breaks}
Description: X display manager
xdm manages a collection of X servers, which may be on the local host or
remote machines. It provides services similar to those provided by init,
diff --git a/debian/rules b/debian/rules
index 5d2dbd3..0e28855 100755
--- a/debian/rules
+++ b/debian/rules
@@ -124,6 +124,7 @@ clean: xsfclean
binary-arch: $(STAMP_DIR)/install
dh_testdir
dh_testroot
+ dh_runit
dh_installdocs
dh_install --sourcedir=debian/tmp --list-missing
diff --git a/debian/xdm.runit b/debian/xdm.runit
new file mode 100644
index 000..abcbe9f
--- /dev/null
+++ b/debian/xdm.runit
@@ -0,0 +1 @@
+debian/xdm.runscript logscript,name=xdm,since=1:1.1.11-4
diff --git a/debian/xdm.runscript b/debian/xdm.runscript
new file mode 100755
index 000..9572461
--- /dev/null
+++ b/debian/xdm.runscript
@@ -0,0 +1,2 @@
+#!/bin/sh
+exec /usr/bin/xdm -nodaemon -error /dev/stdout
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
pgphB58401uUw.pgp
Description: PGP signature
Bug#926777: runit-init: make bin:runit-init single symlink
Package: runit-init Version: 2.1.2-25 Severity: wishlist Dear Maintainer, please make bin:runit-init as small, as possible. Ideally, it would consist of single symlink /sbin/init -> , that would make experimentation with init system simplier and safer. Also, when runit-init is being replaced by another init system, system is left with means to reboot (reverse of #861536). pgpqDq3eF5fFK.pgp Description: PGP signature
Bug#923478: initscripts use unsafe `: >` shell command to create files
[2019-04-07 10:52] Cristian Ionescu-Idbohrn > On Sat, 6 Apr 2019, Dmitry Bogatov wrote: > > [2019-04-05 11:11] Cristian Ionescu-Idbohrn > > > > > Thing is neither the `:' nor the `true' commands are needed. To > > > truncate a file it's sufficient to redirect _nothing_ to that file. > > > > > >$ dash -c '>/tmp/dir/; echo $?; echo hello world;' > > > dash: 1: cannot create /tmp/dir/: Is a directory > > > 2 > > > hello world > > > > Nice to know. Is this behaviour mandated by posix? > > Not in so many words, but it doesn't say there _must_ be input to > redirect to stdout or stderr. > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07 > > "The overall format used for redirection is: > > [n]redir-op word" > > (nothing about input). dash, bash, busybox ash work fine, but not zsh > (it's waiting for input). > > I've been using these redirections for many, many years without any > ill effects: > > >file # truncate or create > >>file # `touch' or create > > > > The real problem is that a failing redirection is _not_ error handled > > > (in the /etc/init.d/bootmisc.sh case). > > > > Sorry, failed to parse. You seems to tell, that there is another problem > > in 'bootmisc.sh', but I do not understand, which one. > > The redirection in /etc/init.d/bootmisc.sh on line 29 is _not_ error > handled. Writing to a file can fail (for various reasons). > > OTOH, the redirection in /lib/init/bootclean.sh on line 22 _is_ error > handled. Good catch. Mind to send a patch into a separate bug? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#374039: #374039 shutdown -h -H: warn that then cannot poweroff perhaps
control: tags -1 +upstream [ Please keep attribution ] [2019-04-07 11:12] Jesse Smith > > Halt action is to halt or drop into boot monitor on systems that > > support it." is not enough to convey, that in many cases it brings > > machine into state, when it is still on, display still showing > > letters, but no interation (except physical poweroff) is possible. > > That is what halt means - to stop running the system without powering > off. Maybe, but many of us are accustomed that /sbin/halt turns off the computer, so here comes confusion. > > "Maybe -H is actually produces useful behaviour in some cases (no > > idea), but please add into manpage warning like "Do not use -H option, > > unless you really know what are you doing." > > Halting is often used to run through the shutdown process and leave > output on the screen for debugging purposes. Or when you want the OS to > stop, but leave the power on. There is no negative side-effect to using > the -H option, no loss of data. There isn't any reason to print an extra > warning. Okay, what about including this explanation into manpage? I know, Unix is about sharp tools, but before I started working on sysvinit, I believed, that "halt == turn-off", so extra explanation, that it is different things would be nice to user. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#926545: startpar: option -v is not present in manual
control: tags -1 +fixed-upstream [2019-04-06 17:23] Jesse Smith > > Manual page startpar(8) does not mention `-v' (version) option, while > > it is present > > Agreed. I have added the -v flag to the startpar manual page. Good. Thank you. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#926390: sysvinit-utils: /lib/init/init-d-script always fails when VERBOSE=no
control: severity -1 important
[2019-04-04 12:44] Marc Lehmann
> Package: sysvinit-utils
> Version: 2.88dsf-59.9
> Severity: normal
>
> Dear Maintainer,
>
> I tried to install the snmpd package, but the post-install script always
> failed because invoke-rc.d snm,pd restart failed.
>
> Surprisingly, running it interactively always worked.
>
> It turned out the problem was /lib/init/init-d-script's jandling of
> VERBOSE, in shoprt, if VERBOSE=no, it always fails.
>
> The reason is that "snmpd restart" falls through to the last case
> statement in init-s-script:
>
> restart)
>call do_restart
>;;
>...
>exit $? # See https://bugs.debian.org/822753#53
>
> do_restart looks like this:
>
> call do_start_cmd
> case "$?" in
> 0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
> 2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
> esac
>
> and this always has exit status 1, as do_startr_cmd returns either 0, 1
> or 2, and in all cases, [ no != no ] is false, so the exit status becomes
> false, and thuis the whole init script exit status becomes false.
>
> The end result is that the snmpd package always failed postinstall and
> couldn't be removed either, while it's init-scripot works fine when
> running at the shell, because VERBOSE isn't "no".
>
> If this is a bug in snmpd's init script, could you reassign
> it to the correct package?
Thank you for so in-depth research. I believe this issue is resolved as
side-effect of #427889 in commit 26e498959, included in release 2.94-2.
Can you please try upgrading initscripts to 2.94-2 or applying patch,
included in this mail and see, whether it solves problem?
Non-uninstallable package is bad, very bad. I am afraid, we will need
upload to unstable and unblock from release team.
From 26e4989597d0fca9348443721c512f2b6774971c Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Sun, 24 Mar 2019 22:18:22 +
Subject: [PATCH] Make init-d-scripts exit with sensible values (Closes:
#427889)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
According to Policy=4.3.0.3,
The "init.d" scripts must ensure that they will behave sensibly (i.e.,
returning success and not starting multiple copies of a service) if
invoked with "start" when the service is already running, or with
"stop" when it isn’t, and that they don’t kill unfortunately-named
user processes.
This patch ensures, that exit values, returned by start-stop-daemon(8)
are sensible and propagated correctly into do_{start,stop,restart} functions.
Unfortunately, as resolved in #426877, --oknodo option is opt-in, and
default behaviour of start-stop-daemon is non-sensible with regard of
starting/stopping daemon, already running/stopped.
---
debian/init-d-script | 38 +++---
1 file changed, 15 insertions(+), 23 deletions(-)
diff --git a/debian/init-d-script b/debian/init-d-script
index 131dbd65..59ae3221 100755
--- a/debian/init-d-script
+++ b/debian/init-d-script
@@ -43,22 +43,10 @@ call() {
# Function that starts the daemon/service
#
-# Return
-# 0 if daemon has been started
-# 1 if daemon was already running
-# 2 if daemon could not be started
do_start_cmd() {
- start-stop-daemon --start --quiet ${PIDFILE:+--pidfile ${PIDFILE}} \
- $START_ARGS \
- --startas $DAEMON --name $NAME --exec $DAEMON --test > /dev/null \
- || return 1
- start-stop-daemon --start --quiet ${PIDFILE:+--pidfile ${PIDFILE}} \
- $START_ARGS \
- --startas $DAEMON --name $NAME --exec $DAEMON -- $DAEMON_ARGS \
- || return 2
- # Add code here, if necessary, that waits for the process to be ready
- # to handle requests from services started subsequently which depend
- # on this one. As a last resort, sleep for some time.
+ start-stop-daemon --start --quiet --oknodo \
+ ${PIDFILE:+--pidfile ${PIDFILE}} $START_ARGS \
+ --startas $DAEMON --name $NAME --exec $DAEMON -- $DAEMON_ARGS
}
do_start()
@@ -68,12 +56,15 @@ do_start()
fi
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
call do_start_cmd
- case "$?" in
+ retval=$?
+ case ${retval} in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
if is_call_implemented do_start_cleanup ; then
call do_start_cleanup
+ else
+ return ${retval}
fi
}
@@ -81,11 +72,6 @@ do_start()
# Function that st
Bug#575204: initscripts: grep complains about invalid back reference in umountfs
[2019-02-19 04:46] Pierre Ynard
>
> part text/plain 571
> > Probably we could just pass -F option to grep?
>
> grep -F would seem a lot safer in many places, yes.
Okay, collegues, what do you think about this patch? It solves problem
at hand, but would introduce another false-positive, if mount options
can look like absolute file path. Can they?
From 16e9c7ba09032523c209aab79b3e3f774ce49a9b Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Fri, 5 Apr 2019 19:18:06 +
Subject: [PATCH] Correctly quote arguments to grep in umountfs script (Closes:
#575204)
---
debian/src/initscripts/etc/init.d/umountfs | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/src/initscripts/etc/init.d/umountfs
b/debian/src/initscripts/etc/init.d/umountfs
index b75095ee..633a3f6d 100755
--- a/debian/src/initscripts/etc/init.d/umountfs
+++ b/debian/src/initscripts/etc/init.d/umountfs
@@ -23,7 +23,7 @@ do_stop () {
TMPFS_MTPTS=""
while read -r DEV MTPT FSTYPE REST
do
- echo "$PROTECTED_MOUNTS" | grep -qs "^$DEV $MTPT " && continue
+ echo "$PROTECTED_MOUNTS" | grep -qsF "$DEV $MTPT " && continue
case "$MTPT" in
/|/usr|/proc|/dev|/.dev|/dev/pts|/dev/shm|/dev/.static/dev|/proc/*|/sys|/sys/*|/run|/run/lock|/run/shm|/run/rpc_pipefs|/dev/vcs)
continue
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#926546: git-buildpackage: gbp-pq: usage of "rediff" term
Package: git-buildpackage Version: 0.9.14 Severity: wishlist Dear Maintainer, gpb pq --export --commit creates commit with subject "Rediff patches". Can you please consider renaming it to "Refresh patches" to be consistent with terminology of "quilt"? Sorry about raising such bike-shedding topic, but I believe consistency is good thing. pgpuyRSg1XLC0.pgp Description: PGP signature
Bug#926306: RFS: socklog/2.1.0-9
[2019-04-04 13:30] Mathieu Mirmont > > * I know, it is pain, but there should be init.d script. You may want to > > take a look at bcron=0.11-8. > > Sure, no worries. How about systemd service files? It makes little sense > to run socklog along with systemd I think, but for the principle it may > be required to profile service files. What do you think? Up to you. Presence of systemd unit files is not mandated by Policy, unlike init.d scripts. > > I believe there should be separate sysuser for socklog-* services. > > Ideally, separate sysuser for /every/ from socklog-* service, but I do > > not know, whehter it is possible. > > Yeah good point. I tend to think that a single user for all socklog-* > services would be enough, but if you prefer I can add one user per > service. Yes, I'd prefer as much separation, as possible. > Thanks for the review! My pleasure. By the way, you seems to forgot to add changelog entry about new maintainer. Something in lines: * Set myself as maintainer (Closes: #) -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#926547: insserv: tests/run-tests are not used
Package: insserv
Version: 1.18.0-2
Severity: normal
Dear upstream maintainer,
during preparation of debian package of insserv=1.19.0 I discovered
issue with test suite (tests/run-tests), which was imported from
`debian/run-tests'.
Firstly, this test suite is not run by Makefile:
check: insserv
ifeq ($(ISSUSE),-DSUSE)
issuse=true tests/common
# issuse=true tests/suse
else
tests/common
endif
If I try to execute them myself, I get following error:
$ tests/run-testsuite
[...]
./tests/run-testsuite: line 982: _order: command not found
error: 88 test executed, 3 fatal tests failed, 1 nonfatal test failed.
Looking up line 982 reveals following:
${severity}_order S mountall needlocal
with `severity' variable is not set anywhere in script. If I set it
myself, like
$ severity=check ./tests/run-testsuite
[...]
error: 244 test executed, 3 fatal tests failed, 3 nonfatal test failed.
I get more sensible output, but still 6 tests are failing.
@Jesse, could you please take a look and maybe cut another upstream
release?
pgpx2XamoicJk.pgp
Description: PGP signature
Bug#926544: startpar: why installed in private directory?
Package: startpar Version: 0.61-1 Severity: normal User: kact...@debian.org Usertags: +objections Hello! Why is startpar(8) is installed into private directory? As I checked, /etc/rc script is fine with startpar(8) in either /lib/startpar or in $PATH. Actually, I believe startpar(8) should be startpar(1), since it can useful to non-privilleged user. (GNU Parallel maybe more powerful, but still). So I intend to move startpar(8) into /sbin on 0.62-1 upload. Objections? @Jesse, could you please consider changing section of manpage to 1? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction -- pgp_krpVWPBoD.pgp Description: PGP signature
Bug#923478: initscripts use unsafe `: >` shell command to create files
[2019-04-05 11:11] Cristian Ionescu-Idbohrn > Thing is neither the `:' nor the `true' commands are needed. To > truncate a file it's sufficient to redirect _nothing_ to that file. > >$ dash -c '>/tmp/dir/; echo $?; echo hello world;' > dash: 1: cannot create /tmp/dir/: Is a directory > 2 > hello world Nice to know. Is this behaviour mandated by posix? If yes, we could simplify code futher. > The real problem is that a failing redirection is _not_ error handled > (in the /etc/init.d/bootmisc.sh case). Sorry, failed to parse. You seems to tell, that there is another problem in 'bootmisc.sh', but I do not understand, which one. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#926545: startpar: option -v is not present in manual
Package: startpar Version: 0.61-1 Severity: minor Tags: +upstream Manual page startpar(8) does not mention `-v' (version) option, while it is present $ /lib/startpar/startpar -v startpar version 0.61 and actually used in /etc/rc script. Please, either remove or document it. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction -- pgpQLUolC_WGK.pgp Description: PGP signature
Bug#926471: lintian: add warning about missing init.d script
Package: lintian Version: 2.11.0 Severity: wishlist Dear Maintainer, According to Policy, 9.11: Packages may integrate with these replacement init systems by providing implementation-specific configuration information about how and when to start a service or in what order to run certain tasks at boot time. However, any package integrating with other init systems must also be backwards-compatible with sysvinit by providing a SysV- style init script with the same name as and equivalent functionality to any init-specific job, as this is the only start-up configuration method guaranteed to be supported by all init implementations. As such, presence in package files /lib/systemd/system/.service or /etc/sv/ without corresponding /etc/init.d/ is violation of "must" in Policy. Please add apporiate error to Lintian. pgpvLNIxiCKgb.pgp Description: PGP signature
Bug#923450: Ping on tech-ctte question about bin:init-system-helpers
--22231_ĵaÅ_Apr__4_10_20_41_UTC_2019 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ping? The bug was created month ago, and there seems no activity at all. -- = Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction = -- --22231_ĵaÅ_Apr__4_10_20_41_UTC_2019 Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEhnHVzDbtdH7ktKj4SBLY3qgmEeYFAlyl2nkACgkQSBLY3qgm Eeayng/6Aq5Du6PpCzfVDDu21iiX2Gz384EwnxraQXd2p+zv6zITm1qRYYMioUcq NJa7BzkYEBimCiWz5piYqGqqng+cSP+wgHpLj44jwshH61g0HBUFhaj1E0qSeeQF jiRRqWVkz0ED0e0MHhhRotmBq9eJOQreXyJth1FlNZMgFvb8TPdI/2/QW5ipzw5h vsFa461OUpfmbIqQG/52mOqIWQF4+XCfRe3wtWolLSbqUdaTjSO8K4Kjv4U0RMIS VoJuATAL3eppdJuCf/X+wSyIS2hcaMUmMJESKjGGUuSIludnOaXK+pA4/TmepHEI Jw5KwtqpI4q2GpAnTniZVu84JbiRRcgDxicod0CbcShClVUPnytKrFKrGH4LOWs5 VPP/zoKkvwlisGu22qmxXAY2o/L+DvkePsmqCXz8/INGCHg8QW8Jq9bpgebRr064 llxKRmNWCk5w6l55DXQuU5RxIpUMiike1aIjaZ+j2aepzMcJP76ApSy3AT+fPJOP qSsqxwHpcAQSPF3O4rVAvi2wp0+0oF/cCnBqRAkD3uHPwuqprH0o4OcWP5eTa/wE c/znhgnke+HQgOq6I8dkqDzvn2FqupRHHA0tQv8EG/Lu/LKUtffVsSMYLYFHK4wb RiCP0ZbxS09UIyXgnRNch61liG5W6ALKAH6HY1dPnOgcQU4N754= =R4Cb -END PGP SIGNATURE- --22231_ĵaÅ_Apr__4_10_20_41_UTC_2019--
Bug#926306: RFS: socklog/2.1.0-9
[2019-04-03 10:45] Mathieu Mirmont
> Package: sponsorship-requests
> Severity: normal [important for RC bugs, wishlist for new packages]
>
> Dear mentors,
>
> I am looking for a sponsor for my package "socklog"
>
> * Package name: socklog
> Version : 2.1.0-9
> Upstream Author : Gerrit Pape
> * URL : http://smarden.org/socklog
> * License : BSD
> Section : admin
>
> It builds those binary packages:
>
> socklog - system and kernel logging services (programs)
> socklog-run - system and kernel logging services
>
> To access further information about this package, please visit the
> following URL:
>
> https://mentors.debian.net/package/socklog
>
>
> Alternatively, one can download the package with dget using this
> command:
>
> dget -x
> https://mentors.debian.net/debian/pool/main/s/socklog/socklog_2.1.0-9.dsc
>
> Changes since the last upload:
>
> * Convert the package to debhelper (Closes: #857208)
> * patches: Import previous patches
> * patch: remove the chkshsgr test
> * watch: add the uscan watch file
> * socklog-run: migrate to dh-runit (Closes: #668718, #834089)
> * gitlab-ci.yml: add GitLab CI file
> * control: update the Vcs fields
> * doc-base: register the html documentation
> * lintian: add overrides
* Please, do not use ${runit:Conflicts}. As suggested by Lintian, it is
very strong relations. Use ${runit:Breaks} only. The very
introduction of ${runit:Conflicts} was my mistake. It will make
Lintian override unneeded.
* Please, consider merging bin:socklog-run into bin:socklog. Option
`since' for dh_runit will be useful for it.
* I know, it is pain, but there should be init.d script. You may want to
take a look at bcron=0.11-8.
* Please, add description to 0002-import-patch-tryto. It is unclear,
what issue this patch resolves.
* In patch 0003-remove-chkshgrp you remove test, that fails on CI. Does
it also fails in sbuild? If not, probably it should only be disabled in
Gitlab CI?
* It is matter of taste, but are you aware, that you can
Build-Depends: debhelper-compat (= 12)
and remove `debian/compat'?
* Dep-5 would be nice.
* What is the purpose of 'log' user, you create with dh_sysuser? You
know, that bin:runit provides user `runit-log' since -20, don't you?
* All services run as same user, 'nobody'. It is unfortunate, since nobody is
quite popular owner for NFS files.
I believe there should be separate sysuser for socklog-* services.
Ideally, separate sysuser for /every/ from socklog-* service, but I do
not know, whehter it is possible.
* I believe, README file is useless -- it contains copyright, authorship
and homepage information only, which is already present in Debian
package files.
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#925995: sysvinit-utils: Manpage typo for SERVICE(8): "Jan 206" instead of 2006
control: reassign -1 init-system-helpers control: tags -1 +confirmed [2019-03-29 19:03] hyiltiz > Package: sysvinit-utils > Version: 2.93-8 > Severity: minor > > The last line of the manpage SERVICE(8) has a typo: should be Jan 2006. Thank you for your report. I see typo too. service(8) belongs to bin:init-system-helpers. Reassigning. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#616330: Reproducible?
control: tags -1 +moreinfo Hello! Sorry for very late response. Before I dig into code, do you still experience the problem? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction -- pgp2fl_qWpI_1.pgp Description: PGP signature
Bug#427889: Proposing patch
control: tags -1 patch
I believe this patch is adequate solution:
From 26e4989597d0fca9348443721c512f2b6774971c Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Sun, 24 Mar 2019 22:18:22 +
Subject: [PATCH] Make init-d-scripts exit with sensible values (Closes:
#427889)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
According to Policy=4.3.0.3,
The "init.d" scripts must ensure that they will behave sensibly (i.e.,
returning success and not starting multiple copies of a service) if
invoked with "start" when the service is already running, or with
"stop" when it isn’t, and that they don’t kill unfortunately-named
user processes.
This patch ensures, that exit values, returned by start-stop-daemon(8)
are sensible and propagated correctly into do_{start,stop,restart} functions.
Unfortunately, as resolved in #426877, --oknodo option is opt-in, and
default behaviour of start-stop-daemon is non-sensible with regard of
starting/stopping daemon, already running/stopped.
---
debian/init-d-script | 38 +++---
1 file changed, 15 insertions(+), 23 deletions(-)
diff --git a/debian/init-d-script b/debian/init-d-script
index 131dbd65..59ae3221 100755
--- a/debian/init-d-script
+++ b/debian/init-d-script
@@ -43,22 +43,10 @@ call() {
# Function that starts the daemon/service
#
-# Return
-# 0 if daemon has been started
-# 1 if daemon was already running
-# 2 if daemon could not be started
do_start_cmd() {
- start-stop-daemon --start --quiet ${PIDFILE:+--pidfile ${PIDFILE}} \
- $START_ARGS \
- --startas $DAEMON --name $NAME --exec $DAEMON --test > /dev/null \
- || return 1
- start-stop-daemon --start --quiet ${PIDFILE:+--pidfile ${PIDFILE}} \
- $START_ARGS \
- --startas $DAEMON --name $NAME --exec $DAEMON -- $DAEMON_ARGS \
- || return 2
- # Add code here, if necessary, that waits for the process to be ready
- # to handle requests from services started subsequently which depend
- # on this one. As a last resort, sleep for some time.
+ start-stop-daemon --start --quiet --oknodo \
+ ${PIDFILE:+--pidfile ${PIDFILE}} $START_ARGS \
+ --startas $DAEMON --name $NAME --exec $DAEMON -- $DAEMON_ARGS
}
do_start()
@@ -68,12 +56,15 @@ do_start()
fi
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
call do_start_cmd
- case "$?" in
+ retval=$?
+ case ${retval} in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
if is_call_implemented do_start_cleanup ; then
call do_start_cleanup
+ else
+ return ${retval}
fi
}
@@ -81,11 +72,6 @@ do_start()
# Function that stops the daemon/service
#
-# Return
-# 0 if daemon has been stopped
-# 1 if daemon was already stopped
-# 2 if daemon could not be stopped
-# other if a failure occurred
do_stop_cmd() {
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 \
$STOP_ARGS \
@@ -114,12 +100,15 @@ do_stop()
fi
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
call do_stop_cmd
- case "$?" in
+ retval=$?
+ case ${retval} in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
if is_call_implemented do_stop_cleanup ; then
call do_stop_cleanup
+ else
+ return ${retval}
fi
}
@@ -130,12 +119,15 @@ do_restart() {
[ "$VERBOSE" != no ] && log_daemon_msg "Restarting $DESC" "$NAME"
call do_stop_cmd
call do_start_cmd
- case "$?" in
+ retval=$?
+ case ${retval} in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
if is_call_implemented do_restart_cleanup ; then
call do_restart_cleanup
+ else
+ return ${retval}
fi
}
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
pgpzdbvR43eVZ.pgp
Description: PGP signature
Bug#925545: udhcpd: support for Runit supervision system
Package: udhcpd
Version: 1:1.30.1-3
Severity: wishlist
Tags: patch
User: ru...@packages.debian.org
Usertags: runscript
Dear Maintainer,
please consider applying patch, that adds support for Runit supervision
system.
dpkg-source: warning: extracting unsigned source package
(/home/iu/devel/salsa/debian/busybox_1.30.1-2.dsc)
dpkg-source: warning: extracting unsigned source package
(/home/iu/devel/salsa/debian/busybox_1.30.1-3.dsc)
diff -Nru busybox-1.30.1/debian/changelog busybox-1.30.1/debian/changelog
--- busybox-1.30.1/debian/changelog 2019-03-02 08:11:13.0 +
+++ busybox-1.30.1/debian/changelog 2019-03-24 11:24:02.0 +
@@ -1,3 +1,9 @@
+busybox (1:1.30.1-3) UNRELEASED; urgency=medium
+
+ * Add runscript for Runit system.
+
+ -- Dmitry Bogatov Sun, 24 Mar 2019 11:24:02 +
+
busybox (1:1.30.1-2) unstable; urgency=high
* Complete the fix for [CVE-2018-20679] Closes: #918846
diff -Nru busybox-1.30.1/debian/control busybox-1.30.1/debian/control
--- busybox-1.30.1/debian/control 2019-03-02 07:57:49.0 +
+++ busybox-1.30.1/debian/control 2019-03-24 11:24:02.0 +
@@ -5,7 +5,7 @@
Uploaders:
Chris Boot ,
Christoph Biedl ,
-Build-Depends: debhelper (>= 11~), zip
+Build-Depends: debhelper (>= 11~), zip, dh-runit (>= 2.8.8)
Standards-Version: 4.1.5
Vcs-Git: https://salsa.debian.org/installer-team/busybox.git
Vcs-Browser: https://salsa.debian.org/installer-team/busybox
@@ -123,6 +123,7 @@
lsb-base,
${misc:Depends},
Provides: dhcpd
+Breaks: ${runit:Breaks}
Description: Provides the busybox DHCP server implementation
Busybox contains a very small yet fully function RFC compliant DHCP
server formerly known as udhcpd.
diff -Nru busybox-1.30.1/debian/rules busybox-1.30.1/debian/rules
--- busybox-1.30.1/debian/rules 2019-03-02 07:57:49.0 +
+++ busybox-1.30.1/debian/rules 2019-03-24 11:19:17.0 +
@@ -47,7 +47,7 @@
export KCONFIG_NOTIMESTAMP=1
%:
- dh $@
+ dh $@ --with runit
##
diff -Nru busybox-1.30.1/debian/udhcpd.runit busybox-1.30.1/debian/udhcpd.runit
--- busybox-1.30.1/debian/udhcpd.runit 1970-01-01 00:00:00.0 +
+++ busybox-1.30.1/debian/udhcpd.runit 2019-03-24 11:22:23.0 +
@@ -0,0 +1 @@
+debian/udhcpd.runscript name=udhcpd,logscript,since=1:1.30.1-3
diff -Nru busybox-1.30.1/debian/udhcpd.runscript
busybox-1.30.1/debian/udhcpd.runscript
--- busybox-1.30.1/debian/udhcpd.runscript 1970-01-01 00:00:00.0
+
+++ busybox-1.30.1/debian/udhcpd.runscript 2019-03-24 11:23:50.0
+
@@ -0,0 +1,3 @@
+#!/bin/sh
+exec 2>&1
+exec /usr/sbin/udhcpd -f /etc/udhcpd.conf
pgpGqW8136v5J.pgp
Description: PGP signature
Bug#589050: Proposed patch for sysvinit#589050
control: tags 589050 +patch From 68c4d0e2fe23cd814cdadcffe6b2f874104912a6 Mon Sep 17 00:00:00 2001 From: Dmitry Bogatov Date: Sun, 24 Mar 2019 23:50:24 + Subject: [PATCH] Improve description of VERBOSE in rcS(5) (Closes: #589050) --- debian/src/initscripts/man/rcS.5 | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/debian/src/initscripts/man/rcS.5 b/debian/src/initscripts/man/rcS.5 index f49a0e45..df832178 100644 --- a/debian/src/initscripts/man/rcS.5 +++ b/debian/src/initscripts/man/rcS.5 @@ -55,10 +55,12 @@ If you set the variable to \fBno\fP then it is advisable to ensure that \fI/run/nologin\fP does not exist. .IP \fBVERBOSE\fP -Setting this option to \fBno\fP (in lower case) will make the boot process -a bit less verbose. -Setting this option to \fByes\fP will make the boot process -a bit more verbose. +Choose, whether boot process should be verbose +(value +.BR yes ) +or quiet (value +.BR no ). +Setting this variable to any other value results in undefined behaviour. .IP \fBFSCKFIX\fP When the root and all other file systems are checked, pgpi46QWCcnQh.pgp Description: PGP signature
Bug#924792: pidof: unsanitized user input makes pidof crash
control: tags -1 +fixed-upstream [2019-03-20 13:50] Jesse Smith > I have removed the "-f" flag for formatting (and the custom string > substitution patch). It has been replaced by the patch from KatolaZ > which allows for a custom field separator. This has been applied > upstream in the 2.95 branch. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#923373: devscripts: unshare as root-gaining program
[2019-03-20 16:53] Mattia Rizzolo > On Wed, Feb 27, 2019 at 03:02:00AM +0000, Dmitry Bogatov wrote: > > as far as I know, `unshare -r' can provide functionality, equal to > > fakeroot. Please consider making it one of root-gaining option, and > > probably downgrade dependency on fakeroot. > > I'm assuming you are talking about debuild here. > As a matter of fact, debuild doesn't do anything anymore with regards of > the -r option, it just passes it on dpkg-buildpackage. > > What actual issue are you facing? You can pass whatever you want to -r, > as long as the interface provided is the same (which means you may need > to write a wrapper). Hard dependency on `fakeroot' is not warranted, at on Linux, I think. What about * providing wrapper around `unshare' in bin:devscripts * documenting that wrapper in debuild(1) * downgrading fakeroot dependency to recommends * (optional) make debuild use unshare wrapper if fakeroot is not installed. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#925281: debhelper: please document $DH_AUTOSCRIPTDIR
Package: debhelper Version: 12.1.1 Severity: wishlist Tags: patch Dear Maintainer, please document $DH_AUTOSCRIPTDIR in doc/PROGRAMMING. I needed this feature when working on dh addon. Prelimitary patch is included. diff --git a/doc/PROGRAMMING b/doc/PROGRAMMING index af4fedeb..89ce6f9d 100644 --- a/doc/PROGRAMMING +++ b/doc/PROGRAMMING @@ -248,7 +248,8 @@ autoscript($package, $scriptname, $snippetname, $substparam) Pass parameters: - binary package to be affected - script to add to -- filename of snippet +- filename of snippet. Snippet is searched in $DH_AUTOSCRIPTDIR + and in /usr/share/debhelper/autoscripts. - (optional) A substitution parameter, which is one of 3 times: * sed commands to run on the snippet. E.g. s/#PACKAGE#/$PACKAGE/ Note: Passed to the shell inside double quotes. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction -- pgpKlOkZgLqv_.pgp Description: PGP signature
Bug#924957: remove flag "-f" in pidof
[2019-03-19 07:38] KatolaZ > Package: sysvinit-utils > Version: 2.93-8 > Severity: normal > > I am opening this bug because I think the recently added flag '-f' in > pidof should be removed. It was intended to be used as a way to format > the PIDs according to printf-style formatters, but accepting > unsanitised input from the user is quite dangerous, as shown in > #924792. The proposed solution to #924792 was to let pidof -f > interpret only '%d' and '\n'. > > This is at least an unnecessary complication. pidof is already > printing the PIDs as integers (!), and any formatting can (but I would > say should/must) be done downstream by sed/awk/whatever. We can't add > a formatter to any single CLI command :\ > > Please remove the unneded '-f' flag. Unix is much much better than > that. Somehow I missed this addition. For what is worth, I totally support this request. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction -- pgpwBeKyJ88l7.pgp Description: PGP signature
Bug#924504: release.debian.org: unblock runit
control: tags -1 -moreinfo [2019-03-17 16:37] Jonathan Wiltshire > On Wed, Mar 13, 2019 at 05:17:40PM +0000, Dmitry Bogatov wrote: > > Please, unblock src:runit=2.1.2-26 to fix following bugs: > > > > * 924038: failure to invoke emergency shell > > * 923957: cascading failure of init scripts, can be critical to > >remote-only systems. > > > > Version in unstable is 2.1.2-25, which did not made to testing; version > > in testing is 2.1.2-22. I ask for permission to upload 2.1.2-26 with > > following changes: > > I don't think I understand. Why do you need approval for -26, is unblocking > -25 not sufficient? > > #924038 is claimed fixed in your -25 upload and #923957 is claimed fixed in > your -24 upload. What is the difference between these and your proposed -26? I prepared -26 since -25 also contains, in particular, fix for 916697, which is wishlist. Difference between -22 (in testing) and -26 is less, then difference between -22 and -25. Just for your convenience. If you are okay with unblocking -25, it is the most straightforward thing to do. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction -- pgp64Dt9zw1Zp.pgp Description: PGP signature
Bug#924792: pidof: unsanitized user input makes pidof crash
[2019-03-19 16:15] KatolaZ > On Tue, Mar 19, 2019 at 03:36:41PM +0100, Matteo Croce wrote: > > Hi all, > > > > I have an idea: implement an option to specify the default separator as > > in propcs-ng: > > > > https://gitlab.com/procps-ng/procps/commit/73492b182dc60c1605d1b0d62de651fad97807af Please do not do it. This is what $ tr ' ' ',' for. Please, keep things simple and orthogonal. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction -- pgpRcV1ndC3EP.pgp Description: PGP signature
Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'
[2019-03-16 00:41] Lorenzo Puliti > >Bogatov wrote: > >Dear git maintainer, you could plug this bug by adding > >`/var/lib/supervise/git-daemon' into `debian/git-daemon-run.dirs'. > > Dmitry, are you sure? runsv can create the 'git-daemon' directory if > it's not there, and a dangling symlink won't stop it. > You can do a test: > # update-service --remove /etc/sv/git-daemon > # rm -r /var/lib/supervise/git-daemon > # update-service --add /etc/sv/git-daemon > wait at least 5 seconds, than do > # sv term git-daemon You are right. Not sure why creating directory fixed issue for me, but probably I should do less of testing on live system and do more of clean-room testing. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#501481: [Pkg-sysvinit-devel] Bug#501481: drop logsave from checkroot.sh and checkfs.sh please?
[2019-03-16 16:29] Harald Dunkel
> I am running ext4 instead of reiserfs today, but logging fsck has still
> a *severe* impact on boot time performance. We have a few Debian file
> servers in the office, e.g. providing /home/* via NFS. They are managed
> remotely using some serial-over-line technology instead of a vga console.
>
> A few months ago such a server went down without a clean umount. On the
> next boot it was busy for >2h to show billions of lines about some tiny
> repairs it has performed. Mo end was in sight. Then I gave up, interrupted
> fsck, booted the host in single user mode, and rerun fsck writing to a log
> file instead of the serial line. It was completed within 15 minutes. No
> serious problems.
I see. How fine grained control you need? Do you need separate controls
to enable/disable logsave for `checkroot.sh' and `checkfs.sh'?
I consider two possible implementations for current feature request --
either make FSCK_LOGFILE variable configurable via
/etc/default/{checkfs,checkroot} or add variable `WANT_LOGSAVE' there.
Not sure, which is better. Opinions?
Just in case. Dear submitter, you are aware, that init.d scripts are
conffiles, aren't you?
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)
[2019-03-13 18:20] Thorsten Glaser > On Wed, 13 Mar 2019, Dmitry Bogatov wrote: > > > Sorry, I am totally confused. Mind to make a patch? > > Eh, just donât drop support, and at best document that > people should use the new tune2fs option for ext[234]. > > No sense in making a patch, weâve frozen. We are warm in experimental :) -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#924688: runit: Supervise path not consistent with dh-runit
Control: tags -1 +pending [2019-03-15 22:15] Lorenzo Puliti > Package: runit > Version: 2.1.2-25helpers1 > Severity: normal > Tags: patch > > Hi, > > I've just find out about #919296, so I realised that runit's update-service > (used in git-daemon maint scripts) is using a different path for supervise > directory. > In the attached patch i'm changing that path to be consistent with the one > used by dh-runit (both service and log). Thank you. Applied. > But also I spot another difference: > a directory inside supervise created by dh-runit has mode 755 while the one > created by runsv (with update-service) has mode 700. > For example: > # ls -l /var/lib/supervise/ | grep elogind > drwx-- 2 root root 4096 Mar 15 19:11 elogind > drwx-- 2 root root 4096 Mar 15 19:11 elogind.log > > # ls -l /var/lib/runit/supervise/ | grep getty-tty2 > drwxr-xr-x 2 root root 4096 Mar 15 19:11 getty-tty2 > > With mode 755 both the pid file and the stat file are world readable.. > Maybe mode 700 is safer? While I do not see how it is dangerous, since pid files under /run are world-readable: $ cat /run/*.pid 1961 25505 25561 2437514 2475 25495 9699 $ whoami iu ... I agree, that 700 feels better. Mind to file separate bug against dh_runit? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#924116: lintian: false positive of package-uses-dh-runit-...
[2019-03-15 00:10] "Chris Lamb" > Dmitry Bogatov wrote: > > > > Can you be more specific? That would appear to catch runit itself, at > > > the very least. How about if a package ships a file matching the > > > following scheme? > > > > > >/etc/sv/foo/run > > > > Well, package can ship /etc/sv/foo/run without dh_runit. > > Of course, but those won't --with runit or have a manual call to > dh_runit, right? Probably not. None I am aware about. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#924327: directfb FTBFS for armel,armhf: error: implicit declaration of function 'makedev'
[2019-03-11 17:55] Helmut Grohne > directfb has build failures. A cross build for armel fails: > > | mknod( C64X_DEVICE, 0666 | S_IFCHR, makedev( 400, 0 ) ); I encountered similar error on one of my packages recently (can't remember which one). It was due upgrade to glibc-2.28 and missing #include Sorry, can't check on arm* architectures. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#924769: runit: invoke-run should handle init.d instance
Package: runit Version: 2.1.2-23 Severity: normal Dear Maintainer, currently, when user upgrades package to version, providing runscript, when service is already running (started before by init.d script), runsv will keep trying to start second instance, as prescribed by /etc/service//run runscript. It is required, that in this situation either runscript should `down' itself, either stop init.d instance with `/etc/init.d/ stop'. -- System Information: Debian Release: 10 APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=eo.utf8, LC_CTYPE=eo.utf8 (charmap=UTF-8), LANGUAGE=eo.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: runit (via /run/runit.stopit) Versions of packages runit depends on: ii libc6 2.28-8 ii runit-helper2.8.8 ii sysuser-helper 1.3.3 Versions of packages runit recommends: ii runit-init 2.1.2-23 runit suggests no packages. -- no debconf information pgpaqsHimLxJf.pgp Description: PGP signature
Bug#703844: proposed wording
[2019-03-13 07:56] Pierre Ynard > > part text/plain 407 > > +# Bring networking down before halting/rebooting system. Set to "yes" or > > "no". > > +NETDOWN=yes > > I'm worried that people might get confused and wrongly think that they > need this otherwise `/etc/init.d/networking stop` won't be called. > Perhaps change "before" to "right before" and add something like: "You > should only need this to handle issues with Wake-on-LAN or network > filesystems." Fine. Updated wip/bug/703844 branch. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#924504: release.debian.org: unblock runit
Package: release.debian.org
Severity: wishlist
Please, unblock src:runit=2.1.2-26 to fix following bugs:
* 924038: failure to invoke emergency shell
* 923957: cascading failure of init scripts, can be critical to
remote-only systems.
Version in unstable is 2.1.2-25, which did not made to testing; version
in testing is 2.1.2-22. I ask for permission to upload 2.1.2-26 with
following changes:
diff --git a/debian/changelog b/debian/changelog
index 22639a4..e357e55 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+runit (2.1.2-26) unstable; urgency=medium
+
+ * Use full path when executing emergency shell. (Closes: #924038)
++ Thanks: Lorenzo Puliti
+ * Remove `set -e' from `run_sysv_scripts' to ensure behaviour
+similar to `/etc/init.d/rc' -- failure of one script in `/etc/rcS.d'
+does not prevent other from running. (Closes: #923957)
+
+ -- Dmitry Bogatov Fri, 08 Mar 2019 15:29:32 +
+
runit (2.1.2-22) unstable; urgency=medium
* Do not create symlinks between bin:runit and bin:runit-init
diff --git a/debian/contrib/2 b/debian/contrib/2
index 8569963..31da5e9 100755
--- a/debian/contrib/2
+++ b/debian/contrib/2
@@ -9,7 +9,7 @@ SVDIR=/etc/service
if [ -f /run/runit.stopit ] ; then
# single mode
if grep -q -w -i 'single' /proc/cmdline ; then
- chpst -P sulogin -p /dev/tty1
+ chpst -P /sbin/sulogin -p /dev/tty1
fi
diff --git a/debian/contrib/lib/run_sysv_scripts
b/debian/contrib/lib/run_sysv_scripts
index 7ab2486..12b72f8 100755
--- a/debian/contrib/lib/run_sysv_scripts
+++ b/debian/contrib/lib/run_sysv_scripts
@@ -1,4 +1,5 @@
-#!/bin/sh -eu
+#!/bin/sh -u
+# Deliberately NO `set -e'. See #923957.
initdir="${1}"
for script in "$initdir/S"* ; do
path=$(realpath "$script")
pgpOU6yjbzXnP.pgp
Description: PGP signature
Bug#924505: bash: set shell to /bin/sh on removal
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).
Please, consider applying.
diff -Nru bash-5.0/debian/bash.prerm bash-5.0/debian/bash.prerm
--- bash-5.0/debian/bash.prerm 2013-10-23 12:41:22.0 +
+++ bash-5.0/debian/bash.prerm 2019-03-13 17:07:54.0 +
@@ -9,6 +9,10 @@
;;
remove|deconfigure)
+ 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)
diff -Nru bash-5.0/debian/changelog bash-5.0/debian/changelog
--- bash-5.0/debian/changelog 2019-01-24 10:01:16.0 +
+++ bash-5.0/debian/changelog 2019-03-13 17:08:11.0 +
@@ -1,3 +1,9 @@
+bash (5.0-3) UNRELEASED; urgency=medium
+
+ * Set shell of all users, whose shell was /bin/bash to /bin/sh.
+
+ -- Dmitry Bogatov Wed, 13 Mar 2019 17:08:11 +
+
bash (5.0-2) unstable; urgency=medium
* Apply upstream patches 001 and 002. Closes: #919439.
pgpDpZ9w7gLA6.pgp
Description: PGP signature
Bug#923924: Please review and apply attached patch to support shutdown on SIGPWR
control: tags -1 +patch +pending [2019-03-11 20:51] Andras Korn > This is entirely in line with The Unix Way: making one program a > drop-in replacement for another such that other programs interfacing > with them don't see a difference unless they need to. It's why bzip2 > and gzip take most of the same switches etc. Well, this sounds convincingly. Added three more lines, using SIGUSR2 instead of SIGPWR if latter is not available, as sysvinit do. > Since you apparently don't agree that this is a good idea, should I > take the patch to Gerrit instead? Not sure it will help, his activity seems dormant for quite a long time, but good luck. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
