Bug#822753: /lib/init/init-d-script: exit 0 at end of script prevents all other exit codes
[2018-11-20 21:25] Michael Biebl > fwiw, this is why I suggested to provide a C implementation of > init-d-script which can be used as an interpreter > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913247 > > I consider the usage of /usr/bin/env only a kludge and hope the > maintainers of /lib/init/init-d-script do reconsider, i.e. I don't > consider #913247 to be solved. I consider extra 13 chars in shebang to be less sacrifice for kFreeBSD compatibility then need to write and maintain extra C program. Line added, line spent. By the way, what is your resolution about changes I proposed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913247#45 in regard systemctl forwarding?
Bug#914788: Please don't enable getty services for tty devices that don't exist
[2018-11-27 11:14] Andras Korn
> Ideally, I wouldn't even have to install the getty-run package, but I
> understand it's there to help avoid people shooting themselves in the
> foot by installing runit and then not having any way to log in.
True. I too do not like hard dependency, but Debian users expect things
to work out-of-box.
> However, whenever the getty-run package is installed in a vserver, I have to
> manually remove the /service/getty-tty* symlinks.
>
> Can you please modify the postinst script so it only installs getty services
> for /dev/tty* devices that are actually there?
I do not like maintainer scripts. They are pain to get right. I can
propose you to pre-provision your servers with
`/etc/sv/getty{1-6}-run/down' file. See runsv(8).
> Or can we come up with a way to help people avoid shooting themselves in the
> foot while not requiring me to install getty-run in vservers? For example,
> runit-init could depend on "getty-run | some-way-to-log-in-interactively",
> and "some-way-to-log-in-interactively" could be provided by an empty
> "runit-no-getty" package as well as an "ssh-run" package that sets up a
> runit service for ssh.
If it would help you, I can add dependency on 'getty-run | access-run'.
You are free to provide `access-run' in whatever way you like.
I am fine with `bin:unsafe-no-tty-run' package too, but not now. I do not
want to get stuck in NEW before freeze.
Bug#768939: startpar: obsolete conffiles /etc/init/startpar-bridge.conf
[2018-11-27 17:33] Ivan Shmakov > I’m not going to claim I’m that familiar with Debian packaging > practices, but wouldn’t .postinst alone be enough? .postrm > isn’t going to do anything if .postinst has already removed the > file, and there seem to be nothing to warrant a .preinst, either. Manual page of dpkg-maintscript-helper suggests so: Many of those tasks require coordinated actions from several maintainer scripts (preinst, postinst, prerm, postrm). To avoid mistakes the same call simply needs to be put in all scripts and the program will automatically adapt its behaviour based on the environment variable DPKG_MAINTSCRIPT_NAME and on the maintainer scripts arguments that you have to forward after a double hyphen.
Bug#838480: Next revision, suggestion accounted
[2018-11-16 18:55] Martin Pitt > Hello Dmitry, > > Dmitry Bogatov [2016-10-20 13:33 +0300]: > > runit_2.1.2-9 in testing, and it: > > > > - Depends on getty-run, which means that user end up without tty > > Not sure what "getty-run" is, but indeed I don't get a TTY. But I don't even > get that far. This is my current experience: > > * Standard vmdebootstrap install of sid. > * Install runit-init, "do as I say!", reboot (that works) Hi! Maybe you could export VM image or something like this? I am worried: freeze is coming, and nothing is happening. I am not going to miss another release.
Bug#912201: RFS: manticore/2.7.3 [ITP]
[ Top posting is discouraged ] [2018-11-27 21:11] Adrian Nuta > * Since this package is not debian-specific, and have its own release >process, package must be foreign (with -1 revision), not native. > changed to 1.0, not sure if this is correct No. Source format 1.0 is long deprecated. You want to use 3.0 (quilt). And, by the way, where is the source of debianization? While not strictly mandatory, Vcs-* fields are very useful. I suggest git, obliviously.
Bug#914943: libbg-dev: Please provide diet-libc version of library
Package: libbg-dev Version: 2.04+dfsg-1 Severity: wishlist Dear Maintainer, please provide static version of library, linked with diet libc.
Bug#891538: installed hook fails completely
[2018-02-26 09:05] Antoine Beaupre
> part text/plain1568
> Package: gitlint
> Version: 0.9.0-2
> Severity: important
>
> The hook installed with `gitlint install-hook` fails completely when
> called through a commit:
>
> gitlint: checking commit message...
> /usr/bin/python: No module named gitlint
Dear maintainer, I prepared patch that fix this issue.
If you do not object, I will NMU it in a week or so.
diff -Nru gitlint-0.9.0/debian/changelog gitlint-0.9.0/debian/changelog
--- gitlint-0.9.0/debian/changelog 2018-02-18 21:48:41.0 +
+++ gitlint-0.9.0/debian/changelog 2018-11-25 18:57:11.0 +
@@ -1,3 +1,10 @@
+gitlint (0.9.0-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Make sure gitlint is correctly called from commit hook (Closes: #891538)
+
+ -- Dmitry Bogatov Sun, 25 Nov 2018 18:57:11 +
+
gitlint (0.9.0-2) unstable; urgency=medium
* Add missing dependency python3-sh (Closes: #887789)
diff -Nru gitlint-0.9.0/debian/patches/Fix-gitlint-invocation-in-git-hook
gitlint-0.9.0/debian/patches/Fix-gitlint-invocation-in-git-hook
--- gitlint-0.9.0/debian/patches/Fix-gitlint-invocation-in-git-hook
1970-01-01 00:00:00.0 +
+++ gitlint-0.9.0/debian/patches/Fix-gitlint-invocation-in-git-hook
2018-11-25 18:57:11.0 +
@@ -0,0 +1,15 @@
+Description: Make sure gitlint is correctly called from commit hook
+Author: Dmitry Bogatov
+Bug-Debian: https://bugs.debian.org/891538
+
+--- gitlint-0.9.0.orig/gitlint/files/commit-msg
gitlint-0.9.0/gitlint/files/commit-msg
+@@ -26,7 +26,7 @@ fi
+
+ run_gitlint(){
+echo "gitlint: checking commit message..."
+- cat "$1" | python -m gitlint.cli
++ cat "$1" | python3
+gitlint_exit_code=$?
+ }
+
diff -Nru gitlint-0.9.0/debian/patches/series
gitlint-0.9.0/debian/patches/series
--- gitlint-0.9.0/debian/patches/series 2018-02-18 21:48:41.0 +
+++ gitlint-0.9.0/debian/patches/series 2018-11-25 18:57:11.0 +
@@ -2,3 +2,4 @@
0002-Change-get_sample-and-get_expected-to-context.patch
0003-Fix-regexp-matching-in-tests.patch
0004-Remove-duplicate-line.patch
+Fix-gitlint-invocation-in-git-hook
Bug#538334: initscripts: /etc/init.d/bootlogd oddities
[2018-11-16 14:10] Cristian Ionescu-Idbohrn > [...] > > I agree, after reading the code again. The exit status is saved in > the ES variable and shown if $VERBOSE != no. Still, as the last > command in the script is ':', the script returns exit status success, > which might be a lie. We are discussing it: #822753
Bug#838480: Next revision, suggestion accounted
[2018-11-16 18:55] Martin Pitt > Not sure what "getty-run" is, but indeed I don't get a TTY. But I don't even > get that far. This is my current experience: > > * Standard vmdebootstrap install of sid. > * Install runit-init, "do as I say!", reboot (that works) > * Boot does that: > [...] > And from here on, nothing. I can't log in through sshd, and there's no VT > either. Okay, let us debug. $ sudo vmdebootstrap --image debian-838480.img --size 15G --distribution sid Warning: The image may fail to boot with ext4 and extlinux unless vmdebootstrap is running on Jessie. Use grub or ext3 and see the docs. $ sudo chown $USER:$USER debian-838480.img $ /usr/share/vmdebootstrap/qemu-wrapper.sh debian-838480.img amd64 VNC server running on ::1:5900 ## Now I get on VM 'Booting from Hard Disk...', things do not move ## further. I believe here I hit this warning. I do not have Jessie box. So let me go another way. I will make fresh installation. $ qemu-img create -fqcow2 img/debian-838480.qcow2 15G Formatting 'debian-838480.qcow2', fmt=qcow2 size=16106127360 cluster_size=65536 lazy_refco unts=off refcount_bits=16 $ qemu-system-x86_64 -m256 -enable-kvm -hda img/debian-838480.qcow2 \ -cdrom iso/debian-9.5.0-amd 64-netinst.iso ## The most basic installation. Guided partition, no seperate ## partitions for /home,/var/,/tmp ## ## Only "standard system utilities" are installed. ## Now on virtual machine. # -- enable sid -- # apt-get update # apt-get dist-upgrade # apt-get install runit-init=2.1.2-18 # reboot `dbus' starts slowly, otherwise things are fine. After some stracing, I discovered that dbus was trying to recvmsg(1) from /run/dbus/system_bus_socket. Resource was not available, so dbus tried to poll with 90 sec timeout. After purging `systemd', this issue with dbus is gone. I think somewhere `dbus' makes wrong assumption, `systemd' is installed => `systemd' is init system So far, I still insist on adding `runit-init' into Pre-Depends of `init'. I works for me, it works for bug reporters of src:runit, and it would be great for it to have better visibility.
Bug#867747: reopening 867747, reassign 867747 to initscripts ...
[2017-07-11 03:35] Michael Biebl > reopen 867747 > reassign 867747 initscripts > retitle 867747 /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1 > thanks Interesting. On my system `/var/log/dmesg' is 640, root:adm, which is quite restrictive. If I run `/etc/init.d/bootlogs' again, it stays so. But if I remove `/var/log/dmesg' and re-run `/etc/init.d/bootlogs', `/var/log/dmesg' becomes 644. I believe adjustment to `/etc/init.d/bootlogs' to check `kernel.dmesg_restrict' is needed. By the way, any ideas how could I have 640 `/var/log/dmesg' in first place?
Bug#901289: Bug#910289 closed by Dmitry Bogatov (Bug#910289: fixed in sysvinit 2.93-3)
control: close 901289 [2019-01-05 11:37] Antoine Beaupré > On 2019-01-05 11:36:22, Debian Bug Tracking System wrote: > > This is an automatic notification regarding your Bug report > > which was filed against the wnpp package: > > > > #910289: RFP: webext-ghosttext -- Use your text editor to write in your > > browser > > > > It has been closed by Dmitry Bogatov . > > [...] > > > Source: sysvinit > > Source-Version: 2.93-3 > > I believe you might have closed this bug report by mistake and I have > reopened it. But you might want to close the correct one instead... My apologies. Closing correct bug now.
Bug#713905: mention that there is nothing wrong with one's system upon warning
reassign -1 insserv [2013-06-24 01:11] jida...@jidanni.org > Package: sysv-rc > Version: 2.88dsf-41+jessie1 > Severity: wishlist > File: /usr/sbin/update-rc.d > > This > > update-rc.d: warning: default start runlevel arguments (2 3 4 5) do not match > alsa-utils Default-Start values > (S) > > Should instead be > > update-rc.d: warning: system-wide Default-Start runlevel arguments > (2 3 4 5) do not match alsa-utils Default-Start values (S). > > And also add a line saying that there is nothing that the user has done > wrong and needs to be cleaned up. It's just that the package contains > special Default-Start values. > > Also mention which ones are now being used. > "Using the latter anyway." Jesse, could you please take a look at this. This message is generated by insserv. Probably we could use more gentle tone, like 'info: default start runlevel arguments (2 3 4 5) differs from default (S). Proceeding as requested'.
Bug#573550: affects squeeze, package has only been updated in testing
[2019-01-01 22:38] Dmitry Bogatov > [2018-12-29 19:51] Michael Biebl > > Am 29.12.18 um 19:34 schrieb Dmitry Bogatov: > > > control: reassign -1 init-system-helpers > > > > How should we handle bugs that are really sysvinit specific, even if > > they affect update-rc.d/invoke-rc.d (i.e. init-system-helpers) > > > > No one of the current init-system-helpers is using sysvinit anymore, so > > bug reports like this one are bound to get forgotten/ignored. > > Quite unfortunate situation. Okay, I will take a look at it myself. > > > Should we usertag them somehow so those sysvinit specific issues are > > on the radar on the sysvinit maintainers? This really needs a > > fix/patch from someone actively using sysvinit. > > Just added usertag. Okay. I believe this bug could be closed on timeout, and both 'start' and 'stop' sub-actions could be dropped, together with `sysv_plain' (pre-boot-dependency) part. What worries me is that `update-rc.d defaults' do not seems to work (insserv=1.18.0): # update-rc.d cron disable 3 insserv: warning: current start runlevel(s) (2 4 5) of script `cron' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (3) of script `cron' overrides LSB defaults (empty). # update-rc.d cron defaults insserv: warning: current start runlevel(s) (2 4 5) of script `cron' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (3) of script `cron' overrides LSB defaults (empty). # insserv cron insserv: warning: current start runlevel(s) (2 4 5) of script `cron' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (3) of script `cron' overrides LSB defaults (empty). # insserv cron -f insserv: warning: current start runlevel(s) (2 4 5) of script `cron' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (3) of script `cron' overrides LSB defaults (empty). # update-rc.d cron enable 3 As can be seen, neither `update-rc.d defaults' nor direct invocation of /sbin/insserv do not restore runlevels, prescribed by LSB header. Jesse, am I doing it wrong?
Bug#701863: invoke-rc.d: report service when policy-rc.d prevents execution.
control: tags -1 +patch
[2013-02-28 18:48] "Trent W. Buck"
> When doing "dpkg-reconfigure -a" in a chroot where everything is
> denied by policy-rc.d, I see a sequence like this:
>
> live-boot: core filesystems devices utils udev blockdev.
> update-initramfs: deferring update (trigger activated)
> invoke-rc.d: policy-rc.d denied execution of stop.
> invoke-rc.d: policy-rc.d denied execution of start.
> invoke-rc.d: policy-rc.d denied execution of restart.
> invoke-rc.d: policy-rc.d denied execution of stop.
> invoke-rc.d: policy-rc.d denied execution of start.
> invoke-rc.d: policy-rc.d denied execution of restart.
> Not restarting sysvinit
>
> I can't tell which services weren't restarted.
> How do you feel about including the service name in that output?
Here I propose patch to implement request:
From aaf747cf7e2a0256f62a25fd69b720b466bfaee2 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Thu, 10 Jan 2019 16:50:13 +
Subject: [PATCH] update-rc.d: make policy deny message more informative
If action on service was denied by policy-rc.d, include name of the
service in error message. (Closes: #701863)
---
script/invoke-rc.d | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/script/invoke-rc.d b/script/invoke-rc.d
index d4ac2c6..cda56db 100755
--- a/script/invoke-rc.d
+++ b/script/invoke-rc.d
@@ -145,10 +145,10 @@ if test "x${POLICYHELPER}" != x && test -x
"${POLICYHELPER}" ; then
1) RC=105
;;
101) if test x${FORCE} != x ; then
- printerror Overriding policy-rc.d denied execution of
${printaction}.
+ printerror "Overriding policy-rc.d denied execution of
${printaction} for ${INITSCRIPTID}."
RC=104
else
- printerror policy-rc.d denied execution of ${printaction}.
+ printerror "policy-rc.d denied execution of ${printaction} for
${INITSCRIPTID}."
fi
;;
esac
Bug#444980: udev not restarted after exiting runlevel 1
[2019-01-08 14:32] Michael Biebl > Am 08.01.19 um 13:37 schrieb Dmitry Bogatov: > > > > control: tags -1 +moreinfo > > > > Seems old discussion did not ended in solution. Let us try again. > > > > Dear udev maintainers, did anything changed? Are there still problems > > running /etc/init.d/udev from runlevel 1 (when udev daemon was killed) > > manually by sysadmin to restart it? > > > > That's not what this bug report is about. > > It's about udev being killed when switching to runlevel 1 and not being > restarted automatically when switching back to say runlevel 2. > > That issue is still valid today. I understand. Perfect solution would be move udev script (or part, that actually starts process/es) to stages (2 3 4 5)? Is it feasible today?
Bug#680293: update-rc.d manual: `update-rc.d remove name` works when `/etc/init.d/name` exists
control: tags -1 +patch
[2012-07-04 22:17] Paul Menzel
> Dear Debian folks,
>
>
> the manual of `update-rc.d` contains the following paragraph.
>
> $ man update-rc.d
> […]
> When invoked with the remove option, update-rc.d removes any
> links in the /etc/rcrunlevel.d directories to the
> script /etc/init.d/name. The script must have been deleted
> already. If the script is still present then update-rc.d aborts
> with an error message.
> […]
>
> It looks like `update-rc.d remove name` still works though when the
> script in `/etc/init.d/name` is not removed beforehand.
>
> $ sudo update-rc.d pulseaudio remove
> update-rc.d: using dependency based boot sequencing
> $ ls -l /etc/init.d/pulseaudio
> -rwxr-xr-x 1 root root 2227 1. Okt 2011 /etc/init.d/pulseaudio
> $ ls -l /etc/rc*.d/*audio
> ls: Zugriff auf /etc/rc*.d/*audio nicht möglich: Datei oder
> Verzeichnis nicht gefunden
> $ sudo service pulseaudio stop
> PulseAudio configured for per-user sessions ... (warning).
>
> I guess the bug has been present for a longer time, so please update the
> version information accordingly.
Dear maintainers of init-system-helpers, please consider following
patch, that adjust behaviour of update-rc.d to match manpage.
From 46c7069cf9253399540cb0a75c51e164293e8689 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Thu, 10 Jan 2019 15:57:35 +
Subject: [PATCH] update-rc.d: refuse to remove links to present script
Fix behaviour of update-rc.d to match manual page: throw error on
attemps to remove links to script, that is not removed.
(Closes: #680293)
---
script/update-rc.d | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/script/update-rc.d b/script/update-rc.d
index 71fb1a6..870af0e 100755
--- a/script/update-rc.d
+++ b/script/update-rc.d
@@ -193,7 +193,7 @@ sub create_sequence {
$sysv_insserv->{remove} = sub {
my ($scriptname) = @_;
if ( -f "/etc/init.d/$scriptname" ) {
-return system($insserv, @opts, "-r", $scriptname) >> 8;
+error("/etc/init.d$scriptname exists, refusing `remove' action.");
} else {
# insserv removes all dangling symlinks, no need to tell it
# what to look for.
Bug#659955: update-rc.d: add option to specify alternative root (like insserv -p)
[ I believe this bug should be reassigned to bin:insserv, if current maintainer of bin:init-system-helpers agree. ] [2012-02-15 11:33] Peter Eisentraut > part text/plain 238 > Package: sysv-rc > Version: 2.88dsf-22 > Severity: wishlist > > Please add an option like insserv -p or chkconfig --root to specify an > alternative root for the init scripts. This would be useful for > testing and for fixing other file systems. According to insserv(8), it must be possible (insserv=1.18.0): [[/]path/to/init.d/] Relative or absolute path to the init scripts base directory. This defaults to /etc/init.d/ in compliance with the LSB speci‐ fication. In this case insserv does not add or remove a script to the runlevels declared in the script headers, but may re-order the runlevels if the order of the currently enabled scripts has changed (see option -d). Note that if a relative path is used insserv has to be called from the root directory. but I failed to make use of it: $ mkdir /tmp/temp-1 $ cp -r /etc/init.d . $ /sbin/insserv init.d $ ls init.d rc0.d rc1.d rc2.d rc3.d rc4.d rc5.d rc6.d rcS.d $ find -empty ./rcS.d ./rc6.d ./rc5.d ./rc4.d ./rc3.d ./rc2.d ./rc1.d ./rc0.d Jesse, am I holding it wrong?
Bug#545448: [Pkg-sysvinit-devel] Bug#545448: invoke-rc.d should indicate whats wrong when not starting services
[2009-09-07 13:44] Henrique de Moraes Holschuh
> > > Which is also correct, invoke-rc.d is to be used in maintainer scripts,
> > > its
> > > result codes in default mode of operation are optimized for that usage.
> >
> > Yeah, I know that. And that is okay. However if it does not start a
> > service (for whatever reason) it should say WHY. It does so for
>
> Well, I am not oposed to that at all, it would be useful to add a "verbose"
> or even better, a very verbose "debug" mode to invoke-rc.d.
I believe I located place, where invoke-rc.d decides aganist starting
service in case, described by submitter.
From f548e3474b404e264fe9439b7543139f5b74a160 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Thu, 10 Jan 2019 14:35:32 +
Subject: [PATCH] invoke-rc.d: warn about unmatching service and runlevel
Print warning, when `invoke-rc.d' refuses to start
service at current runlevel. (Closes: #545448)
---
script/invoke-rc.d | 4
1 file changed, 4 insertions(+)
diff --git a/script/invoke-rc.d b/script/invoke-rc.d
index 27c045e..80e8401 100755
--- a/script/invoke-rc.d
+++ b/script/invoke-rc.d
@@ -406,10 +406,14 @@ else
if testexec ${SLINK} ; then
RC=104
elif testexec ${KLINK} ; then
+ printerror "${INITSCRIPTID} is supposed to be stopped on current
runlevel (${RL})"
+ test x${FORCE} != x && printerror "proceeding anyway due --force"
RC=101
elif testexec ${SSLINK} ; then
RC=104
else
+ printerror "${INITSCRIPTID} is not supposed to be started on
current runlevel (${RL})"
+ test x${FORCE} != x && printerror "proceeding anyway due --force"
RC=101
fi
;;
Bug#551555: mountnfs.sh: start should declare dependency on name resolver
[2019-01-08 16:32] Petter Reinholdtsen > [Dmitry Bogatov] > >> Unfortunately $named can not be listed as a dependency for > >> mountnfs.sh, as it would generate a dependency loop. First of all, > >> all known implementations of $named start in rc2.d, while mountnfs.sh > >> need to happen in rcS.d/ if /usr/ is an NFS volume. > > > > Correct me if I am wrong, but on modern installations /usr is mounted by > > initramfs (note usrmerge initiative), so I believe we could move > > mountnfs.sh from S to (2 3 4 5) (with some modifications to not try > > mount multiple times). > > > > Objections? > > No objections, but note there used to be several scripts in rcS.d/ > depending on /usr/ being mounted, and these need to be moved from S to > (2 3 4 5) first. As far as I can tell, we can assume /usr being mounted (if it is separate from /) at time /sbin/init is launched. Another issue is that definition of $remote_fs is *all* file systems are mounted. And there is some scripts, which 'Default-Start: S', depending on $remote_fs. Seems to get this issue resolved, we need to get following list of packages to get rid of dependency on $remote_fs or move to (2 3 4 5) runlevels. Correct? alsa-utils arno-iptables-firewall auto6to4 dpdk eeepc-acpi-scripts espeakup fcoe-utils ferm initscripts ipsec-tools lm-sensors netfilter-persistent oss4-base pidentd policycoreutils prads pyroman quota racoon screen setserial shorewall shorewall-init shorewall-lite shorewall6 shorewall6-lite switchconf x11-common zfs-fuse zvbi It results in 25 maintainers affected. Sounds like MBF. > Also, I do not believe any initrd will NFS mount /usr/, so the use case > described do not really match your description. When /usr/ is NFS > mounted (for example because of size constraints), it is not possible to > merge / and /usr/. True. initramfs knows only two modes of operation -- either remote root (nfs mode) or local root (local mode). It does not know, what to do, if root is local and /usr is remote. Given upcoming `usrmerge', I do not consider this limitation serious. But if for some reason you prefer to have local root and remote /usr, you could do this -- just modify your initramfs. I just conjured following kludge for specific case of two virtual machines, 10.0.0.2 as nfs-server and 10.0.0.3 as local-root,remote-usr: ip link set up dev ens3 ip addr add 10.0.0.3/16 dev ens3 nfsmount 10.0.0.2:/usr /root/usr This snippet is to be inserted into mountroot() function in /usr/share/initramfs-tools/scripts/local. Probably, proper hook could be written and installed.
Bug#629902: dh_installinit: should support LSB compliant scripts
control: tags -1 +patch
[2011-06-14 11:39] Joey Hess
>
> part 1 text/plain 618
> Helmut Grohne wrote:
> > A failure from the update-rc.d cannot make postinst fail, because the
> > exit code is not checked.
>
> Yes it is (set -x), but I meant invoke-rc.d anyway, obviously.
>
> > So in my view the reason for a postinst failure is unrelated to
> > update-rc.d. Can you explain your reasoning?
>
> Simple separation of concerns, invoke-rc.d is responsible for running
> the init script and determining if it fails and propigating a failing
> exit status. debhelper allows it to do do. The right way to make 6 be
> ignored is to get invoke-rc.d to ignore it, not add cruft to every
> postinst that calls it.
Here I propose patch to implement just that:
From 77c189d0f87a53a93f48b08594c8e7ee864b6e5e Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Thu, 10 Jan 2019 16:31:32 +
Subject: [PATCH] invoke-rc.d: exit value 6 from init script is fine
Consider exit value 6 from init script (service not configured) as
successful invocation (Closes: #629902)
---
script/invoke-rc.d | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/script/invoke-rc.d b/script/invoke-rc.d
index 80e8401..d4ac2c6 100755
--- a/script/invoke-rc.d
+++ b/script/invoke-rc.d
@@ -554,9 +554,11 @@ if test x${FORCE} != x || test ${RC} -eq 104 ; then
elif [ -n "$is_openrc" ]; then
rc-service "${INITSCRIPTID}" "${saction}" && exit 0
else
- "${INITDPREFIX}${INITSCRIPTID}" "${saction}" "$@" && exit 0
+ "${INITDPREFIX}${INITSCRIPTID}" "${saction}" "$@"
fi
RC=$?
+ [ "${RC}" = 0 ] && exit 0
+ [ "${RC}" = 6 ] && exit 0 # service not configured. See #629902
if test ! -z "${ACTION}" ; then
printerror action \"${saction}\" failed, trying next action...
Bug#656081: retitle 656081 to service: document that /usr/sbin/service disrespects policy-rc.d intentionally ...
control: tags -1 +patch [2016-07-17 17:52] Michael Biebl > part text/plain 144 > retitle 656081 service: document that /usr/sbin/service disrespects > policy-rc.d intentionally > reassign 656081 init-system-helpers 1.25 > thanks What about this wording: From 5e080c989579dc268fe985a566e3ccb3fdf1ebe3 Mon Sep 17 00:00:00 2001 From: Dmitry Bogatov Date: Thu, 10 Jan 2019 16:41:00 + Subject: [PATCH] Document that `service' it does not check /usr/sbin/policy-rc.d --- man8/service.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/man8/service.rst b/man8/service.rst index cd90bc3..de2d65a 100644 --- a/man8/service.rst +++ b/man8/service.rst @@ -50,7 +50,8 @@ systemctl/initctl equivalents. All scripts should support at least the ``start`` and ``stop`` commands. As a special case, if *COMMAND* is ``--full-restart``, the script is run twice, first with the ``stop`` command, then with the ``start`` -command. +command. Note, that unlike ``update-rc.d``\(8\), ``service`` does not +check ``/usr/sbin/policy-rc.d``. ``service --status-all`` runs all init scripts, in alphabetical order, with the ``status`` command. The status is [ + ] for running services, [ - ] for
Bug#680293: update-rc.d manual: `update-rc.d remove name` works when `/etc/init.d/name` exists
[2018-07-19 23:47] Richard Laager > On 07/14/2018 08:34 PM, Richard Laager wrote: > > Purging ntp after installing ntpsec seems to be fairly common with > > users. Accordingly, I'm raising the severity of this bug to important. > > My current intention is to rename the service from ntp.service to > ntpsec.service. Accordingly, I'm undoing my severity change here. For what it worth, you may be interested virtual facilities (/etc/insserv.conf). We could introduce new virtual dependency $ntp, provided by either ntp or ntpsec package.
Bug#918966: new(?) backlight brightness script
[2019-01-11 08:40] Thorsten Glaser > On Fri, 11 Jan 2019, Aleksi Suhonen wrote: > > > if [ -d /sys/class/backlight/acpi_video0 ]; then > > readonly SYS_CONTROL=/sys/class/backlight/acpi_video0/brightness > > readonly SYS_MAXIMUM=/sys/class/backlight/acpi_video0/max_brightness > > else > > readonly SYS_CONTROL=/dev/null > > readonly SYS_MAXIMUM=/dev/null > > fi > > My Thinkpad has yet different paths, but I don't have them > at hand right now. Will have to dig them out from /etc/rc.local > when I have it again (it's at work and I'm not). Sure. Your contribution would be welcome.
Bug#851427: sysvinit makes /dev/shm a symlink to /run/shm, should be other way round
[ Please, next time attach patch, not whole file. Much more convenient
for review ]
[2019-01-10 10:54] Dolphin Oracle
> the buster version of sysvinit initscripts still mounts the with /run/shm
> as the mount point for the tmpfs and /dev/shm as a symlink.
>
> just adding on to the discussion...the situation actually prevents running
> certain flatpak applications.
>
> modifying mount-functions.sh per the attached will reverse the situation,
Works fine to me, I intend to accept it. Dear co-maintainers,
any objections?
> although there is still some migration code in there that strictly speaking
> isn't necessary.
Further patches are welcome. Just remember, that not only fresh installs
must work fine, but also upgrade from stable must be smooth and painless.
Here is patch for convenience of other developers:
diff --git a/debian/src/initscripts/lib/init/mount-functions.sh
b/debian/src/initscripts/lib/init/mount-functions.sh
index 7511761c..98f53a86 100644
--- a/debian/src/initscripts/lib/init/mount-functions.sh
+++ b/debian/src/initscripts/lib/init/mount-functions.sh
@@ -436,7 +436,7 @@ post_mountall ()
# directory. The migration logic will then take care of the
# rest. Note that it will take a second boot to fully
# migrate; it should only ever be needed on broken systems.
- RAMSHM_ON_DEV_SHM="no"
+ RAMSHM_ON_DEV_SHM="yes"
if read_fstab_entry "/dev/shm"; then
RAMSHM_ON_DEV_SHM="yes"
fi
@@ -559,8 +559,8 @@ mount_shm ()
{
MNTMODE="$1"
- RAMSHM_ON_DEV_SHM="no"
- SHMDIR="/run/shm"
+ RAMSHM_ON_DEV_SHM="yes"
+ SHMDIR="/dev/shm"
if read_fstab_entry "/dev/shm"; then
if [ "$MNTMODE" = "mount_noupdate" ]; then
log_warning_msg "Warning: fstab entry for /dev/shm;
should probably be for /run/shm unless working around a bug in the Oracle
database"
@@ -706,13 +706,3 @@ is_fastboot_active() {
done
return 1
}
Bug#918966: new(?) backlight brightness script
[2019-01-11 07:41] Aleksi Suhonen
> part text/plain 828
> Package: initscripts
> Severity: wishlist
> Version: 2.93-3
>
> After upgrading and rebooting a virtual machine that has only a virtual
> serial console, I get this message:
>
> /etc/init.d/brightness: 36: /etc/init.d/brightness: cannot create
> /sys/class/backlight/acpi_video0/brightness: Directory nonexistent
> It's not critical, but I'm wondering if desktop features could be
> separated from this package. Or if there was a debconf knob to turn them
> all on and off easily?
I understand your concern about desktop feature, but since it quite
simple shell script, I believe, there is no better place for it. If you
have idea, where `brightness' script suits better to, you are welcome!
> Also, the error message could be avoided with some more checking:
>
> if [ -d /sys/class/backlight/acpi_video0 ]; then
> readonly SYS_CONTROL=/sys/class/backlight/acpi_video0/brightness
> readonly SYS_MAXIMUM=/sys/class/backlight/acpi_video0/max_brightness
> else
> readonly SYS_CONTROL=/dev/null
> readonly SYS_MAXIMUM=/dev/null
> fi
I like this approach the best. Here is pending patch. Feedback is
welcome, in wording in particular.
From 97e33ff24c857bf20f6d73a2d75c2d200acd0693 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Fri, 11 Jan 2019 13:31:21 +
Subject: [PATCH] Check in `brightness' initscript for backlight presence
Check for presence of backlight-related virtual files in `brightness'
initscript before trying to set values in them, since they can be
missing on systems with only a serial console. (Closes: #918966)
---
debian/changelog | 2 ++
debian/src/initscripts/etc/init.d/brightness | 9 +++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index a8336299..db5b0443 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,8 @@ sysvinit (2.93-4) UNRELEASED; urgency=medium
* Drop unneeded `40_multiarch_libcrypt.patch': upstream Makefile
correctly supplies -lcrypt flag by itself.
* Make debian/upstream/signing-key.asc minimal
+ * Check for presence of backlight-related virtual files in `brightness'
+initscript (Closes: #918966)
-- Dmitry Bogatov Thu, 10 Jan 2019 19:45:28 +
diff --git a/debian/src/initscripts/etc/init.d/brightness
b/debian/src/initscripts/etc/init.d/brightness
index 3e22bff8..93c1cb8a 100755
--- a/debian/src/initscripts/etc/init.d/brightness
+++ b/debian/src/initscripts/etc/init.d/brightness
@@ -9,13 +9,18 @@
# Description: This script saves the brightness level between restarts.
#It is called from the boot, halt and reboot scripts.
### END INIT INFO
+. /lib/init/vars.sh
+. /lib/lsb/init-functions
+
readonly SAVEDFILE=/var/lib/initscripts/brightness
readonly DEFAULT_LEVEL=4
readonly SYS_CONTROL=/sys/class/backlight/acpi_video0/brightness
readonly SYS_MAXIMUM=/sys/class/backlight/acpi_video0/max_brightness
-. /lib/init/vars.sh
-. /lib/lsb/init-functions
+if ! test -f "${SYS_CONTROL}" ; then
+ log_success_msg "Brightness control not supported: no backlight"
+ exit 0
+fi
do_status () {
MSG="Current brightness level is $(cat ${SYS_CONTROL})"
Bug#919063: dillo: undocumented dipd and dpidc binaries
Package: dillo Version: 3.0.5-4 Severity: wishlist Dear Maintainer, dillo provides several binaries, whose purpose is not easy to understand for enduser: /usr/bin/dillo-install-hyphenation /usr/bin/dpid /usr/bin/dpidc I believe the only user-facing command should be only /usr/bin/dillo, while rest binaries should be hidden from user into /usr/libexec/dillo/ pgpAdmgFXBc7C.pgp Description: PGP signature
Bug#919179: dh-make: generate dependency on `debhelper-compat'
Package: dh-make Version: 2.201802 Severity: wishlist Dear Maintainer, please generate build dependency on `debhelper-compat (= 11)' instead of `debian/compat'. pgpGECFjFXmiJ.pgp Description: PGP signature
Bug#919181: ITP: laminar -- lightweight and modular continuous integration service
Package: wnpp Severity: wishlist Owner: Dmitry Bogatov * Package name : laminar Version : 0.6+46.g31c6498-1 Upstream Author : Oliver Giles * Url : https://laminar.ohwg.net * Licenses : GPL-3+ Programming Lang : C++, Javascript Section : devel The Laminar is a system to automate the compile/test cycle required by most software projects to validate code changes. By automatically rebuilding and testing the tree each time something has changed, build problems are pinpointed quickly, before other developers are inconvenienced by the failure.
Bug#919180: libcapnp-dev: missing libkj-http
Package: libcapnp-dev Version: 0.7.0-1 Severity: normal Dear Maintainer, your package provides kj-http.pc pkg-config file, which provides following instructions to link with kj-http: $ pkg-config --libs kj-http -lkj-http -lkj-async -lkj On other hand, there is no kj-http.so file, so linker complains. I believe you forgot to install kj-http.so. And seems kj-test.so, too. pgpbTQshuosa7.pgp Description: PGP signature
Bug#573550: affects squeeze, package has only been updated in testing
[2019-01-11 14:51] Felipe Sateler > On Fri, Jan 11, 2019 at 9:39 AM Dmitry Bogatov wrote: > > > > > [2019-01-01 22:38] Dmitry Bogatov > > > [2018-12-29 19:51] Michael Biebl > > > > Am 29.12.18 um 19:34 schrieb Dmitry Bogatov: > > > > > control: reassign -1 init-system-helpers > > > > > > > > How should we handle bugs that are really sysvinit specific, even if > > > > they affect update-rc.d/invoke-rc.d (i.e. init-system-helpers) > > > > > > > > No one of the current init-system-helpers is using sysvinit anymore, so > > > > bug reports like this one are bound to get forgotten/ignored. > > > > > > Quite unfortunate situation. Okay, I will take a look at it myself. > > > > > > > Should we usertag them somehow so those sysvinit specific issues are > > > > on the radar on the sysvinit maintainers? This really needs a > > > > fix/patch from someone actively using sysvinit. > > > > > > Just added usertag. > > > > Okay. I believe this bug could be closed on timeout, and both 'start' > > and 'stop' sub-actions could be dropped, together with `sysv_plain' > > (pre-boot-dependency) part. > > > > They are already mapped to `defaults`. I know. Would you be interested in patch, that removes these aliases at all? And what about removing sysv_plain? > > What worries me is that `update-rc.d defaults' do not seems to > > work (insserv=1.18.0): > > [...] > To preserve admin modifications, `update-rc.d defaults` must not touch any > existing links. That's documented in the manpage: > > If any files named /etc/rcrunlevel.d/[SK]??name already exist then > update-rc.d does nothing. Thank you for explanation. I believe this bug should be closed, but leaving it to owner's maintainer.
Bug#629902: dh_installinit: should support LSB compliant scripts
[ Do you want me to re-submit this patch as merge request? ]
[2019-01-11 14:58] Felipe Sateler
> > [2011-06-14 11:39] Joey Hess
> > >
> > > part 1 text/plain 618
> > > Helmut Grohne wrote:
> > > > A failure from the update-rc.d cannot make postinst fail, because the
> > > > exit code is not checked.
> > >
> > > Yes it is (set -x), but I meant invoke-rc.d anyway, obviously.
> > >
> > > > So in my view the reason for a postinst failure is unrelated to
> > > > update-rc.d. Can you explain your reasoning?
> > >
> > > Simple separation of concerns, invoke-rc.d is responsible for running
> > > the init script and determining if it fails and propigating a failing
> > > exit status. debhelper allows it to do do. The right way to make 6 be
> > > ignored is to get invoke-rc.d to ignore it, not add cruft to every
> > > postinst that calls it.
> >
> > Here I propose patch to implement just that:
> > [...]
> I'm wary of unintended consequences here. Do we have services that return
> exit code 6 but as a failure code?
Seems there is nobody, who use exit code 6 for another purposes. You can
make sure by checking is output of 'grep -R "exit 6" -C6' in directory
with all init scripts unpacked:
munin-node-
munin-node-if [ ! -x $DAEMON ]; then
munin-node- log_failure_msg "Munin-Node appears to be uninstalled."
munin-node- exit 5
munin-node-elif [ ! -e $CONFFILE ]; then
munin-node- log_failure_msg "Munin-Node appears to be unconfigured."
munin-node: exit 6
munin-node-fi
munin-node-
munin-node-# Figure out if the pid file is in a non-standard location
munin-node-while read line; do
munin-node- line=${line%%\#*} # get rid of comments
munin-node- set -f
--
globus-gatekeeper-fi
globus-gatekeeper-
globus-gatekeeper-
cert="${GLOBUS_GATEKEEPER_CERT_FILE:-/etc/grid-security/hostcert.pem}"
globus-gatekeeper-if [ ! -f $cert ]; then
globus-gatekeeper-echo "Error: Gatekeeper's certificate file ($cert) is
missing."
globus-gatekeeper-echo "Failed to start globus-gatekeeper"
globus-gatekeeper:exit 6
globus-gatekeeper-fi
globus-gatekeeper-
globus-gatekeeper-
key="${GLOBUS_GATEKEEPER_KEY_FILE:-/etc/grid-security/hostkey.pem}"
globus-gatekeeper-if [ ! -f $key ]; then
globus-gatekeeper-echo "Error: Gatekeeper's private key file is ($key)
is missing."
globus-gatekeeper-echo "Failed to start globus-gatekeeper"
globus-gatekeeper:exit 6
globus-gatekeeper-fi
globus-gatekeeper-
globus-gatekeeper-if [ "${GLOBUS_GATEKEEPER_KERBEROS_ENABLED:-false}" =
"true" ]; then
globus-gatekeeper-kflag="-k"
globus-gatekeeper-else
globus-gatekeeper-kflag=""
--
clamav-milter- log_failure_msg "'invoke-rc.d clamav-milter start'"
clamav-milter- if [ "$1" = "status" ]; then
clamav-milter-# program or service status is unknown
clamav-milter-exit 4;
clamav-milter- else
clamav-milter-# program is not configured
clamav-milter:exit 6;
clamav-milter- fi
clamav-milter-fi
clamav-milter-
clamav-milter-slurp_config "$CLAMAVCONF"
clamav-milter-[ -n "$User" ] || User=clamav
clamav-milter-
--
clamav-milter- log_failure_msg "Please edit $CLAMAVCONF and run 'invoke-rc.d
clamav-milter start'"
clamav-milter- if [ "$1" = "status" ]; then
clamav-milter-# program or service status is unknown
clamav-milter-exit 4;
clamav-milter- else
clamav-milter-# program is not configured
clamav-milter:exit 6;
clamav-milter- fi
clamav-milter-fi
clamav-milter-
clamav-milter-if is_true "$Foreground"; then
clamav-milter- if [ ! -x "$SUPERVISOR" ] ; then
clamav-milter-log_failure_msg "Foreground specified, but $SUPERVISOR not
found"
clamav-milter-if [ "$1" = "status" ]; then
clamav-milter- # program or service status is unknown
clamav-milter- exit 4;
clamav-milter-else
clamav-milter- # program is not configured correctly
clamav-milter: exit 6;
clamav-milter-fi
clamav-milter- else
clamav-milter- RUN_SUPERVISED=1
clamav-milter- fi
clamav-milter-fi
clamav-milter-
--
clamav-milter- log_failure_msg "$NAME: Can not continue with PidFile not set"
clamav-milter- if [ "$1" = "status" ]; then
clamav-milter-# program or service status is unknown
clamav-milter-exit 4;
clamav-milter- else
clamav-milter-# program is not configured correctly
clamav-milter:exit 6;
clamav-milter- fi
clamav-milter-fi
clamav-milter-
clamav-milter-if [ -z "$MilterSocket" ]
clamav-milter-then
clamav-milter- log_failure_msg "$NAME: Can not continue with MilterSocket not
set"
clamav-milter- if [ "$1" = "status" ]; then
clamav-milter-# program or service status is unknown
clamav-milter-exit 4;
clamav-milter- else
clamav-milter-# program is not configured correctly
clamav-milter:exit 6;
clamav-milter- fi
clamav-milter-fi
clamav-milter-
clamav-milter-if [ ! -f "$THEPIDFILE" ]
clamav-milter-then
clamav-milter- touch "$THEPIDFILE"
--
spampd-
spampd-case "$1" in
spampd- start)
Bug#838480: summary of disagreement
[2018-12-21 18:54] Dmitry Bogatov > I drafted following text, expressing my vision of problem. You may wish > to extend it with your vision. > [...] I politely remind about my intention to call for Technical Comitete, and invite you to state your opinion on proposed summary of disagreement.
Bug#551555: mountnfs.sh: start should declare dependency on name resolver
[2019-01-11 20:35] Petter Reinholdtsen > [Dmitry Bogatov] > >> No objections, but note there used to be several scripts in rcS.d/ > >> depending on /usr/ being mounted, and these need to be moved from S to > >> (2 3 4 5) first. > > > > As far as I can tell, we can assume /usr being mounted (if it is > > separate from /) at time /sbin/init is launched. > > Even on diskless workstations and thin clients using LTSP? It is the > use case I know about, but it is years since I tracked its status, so I > do not know if it is still an issue there. According to description of LTSP, it all depends on initramfs provided. So, again, if you insist that / and /usr both remote and separate, you'd have to slightly adjust your initramfs. 1. Thin-clients boot via a protocol called PXE (Pre-eXecution Environment) 2. PXE requests an IP address from a local DHCP server. 3. The DHCP server passes additional parameters to the thin-client and downloads a Linux initramfs filesystem image via TFTP into a RAM disk on the client itself. 4. The thin-client then boots the downloaded Linux initramfs image, detects hardware, and connects to the LTSP server's X session (normally handled by ldm). > > Another issue is that definition of $remote_fs is *all* file systems are > > mounted. And there is some scripts, which 'Default-Start: S', depending > > on $remote_fs. Seems to get this issue resolved, we need to get > > following list of packages to get rid of dependency on $remote_fs or > > move to (2 3 4 5) runlevels. Correct? > > I can not confirm the list, but yes, every script in rcS.d/ depending on > $remote_fs will have to move to (2 3 4 5). Traditionally (as in > Solaris/SysV systems) mounting /usr/ was done in rc[2345].d/, but this > was for some strange reason never done in Debian. I tried to move > $remote_fs there, but ran out of steem before I managed to convince > enough maintainers to do the switch. Okay. I will initate discussion on debian-devel@ in preparation of mass bug filling.
Bug#444980: udev not restarted after exiting runlevel 1
[2019-01-11 14:34] KatolaZ > On Fri, Jan 11, 2019 at 12:36:36PM +0000, Dmitry Bogatov wrote: > > > > [2019-01-08 14:32] Michael Biebl > > > Am 08.01.19 um 13:37 schrieb Dmitry Bogatov: > > > > > > > > control: tags -1 +moreinfo > > > > > > > > Seems old discussion did not ended in solution. Let us try again. > > > > > > > > Dear udev maintainers, did anything changed? Are there still problems > > > > running /etc/init.d/udev from runlevel 1 (when udev daemon was killed) > > > > manually by sysadmin to restart it? > > > > > > > > > > That's not what this bug report is about. > > > > > > It's about udev being killed when switching to runlevel 1 and not being > > > restarted automatically when switching back to say runlevel 2. > > > > > > That issue is still valid today. > > > > I understand. Perfect solution would be move udev script (or part, that > > actually starts process/es) to stages (2 3 4 5)? Is it feasible today? > > > > I don't think it is possible, since udev gets started in early boot, > before filesystems are mounted, but I might be wrong. Yes, I see, that `mountdefsubsys', `procps' and number of other declare soft dependency (Should-Start:) on udev. Any idea, where can I find reasoning, why it is so?
Bug#917624: RFS: ncurses-hexedit/0.9.7+orig-6
control: owner -1 kact...@debian.org [2018-12-29 23:48] Carlos Maddela > Dear mentors, > > I am looking for a sponsor for my package "ncurses-hexedit" > > * Package name: ncurses-hexedit >Version : 0.9.7+orig-6 >Upstream Author : Adam Rogoyski > * URL : http://www.rogoyski.com/adam/programs/hexedit/ > * License : GPL-2.0+ >Section : editors > > It builds this binary package: > > ncurses-hexedit - Edit files/disks in hex, ASCII and EBCDIC > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/ncurses-hexedit > > > Alternatively, one can download the package with dget using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/n/ncurses-hexedit/ncurses-hexedit_0.9.7+orig-6.dsc I believe it should be `dget -ux'. In general, sponsor does not have sponsoree's key in his keyring. Could you please file bug aganist mentors.debian.net about it and add me in CC? > Changes since the last upload: > > * Set "Rules-Requires-Root: no". > * Simplify process by which mutable files are backed up and restored. I like this idea. Thank you. > * Allow build to be as verbose as possible. > * Fix spelling errors detected by lintian and mwic. > * Indicate compliance with Debian Policy 4.3.0. Looks fine. Uploaded. But what does +orig means in version?
Bug#917566: lintian: please warn about non-supported previous versions
[2018-12-28 19:42] Chris Lamb > Dmitry, > > > As far as I know [citation needed], Debian only supports upgrades of > > consequenced releases -- it means that maintainer is not obliged to make > > sure that Debian 8 -> Debian 10 (skipping Debian 9) works smoothly. > [..] > > As of implementation side, given that Lintian by design do not use > > network, it is possible to assume that Debian release happens once a 2.5 > > year (or so), so versions older then 5.5 years (possible to lookup in > > d/changelog) are below threhold. > > Alas, unless we can think of a more-reliable way of doing this I fear this > will be far too full of false-positives or will simply not detect enough > cases to be prioritised. :( Well, we could hardcode dates of Debian releases in Lintian. It is just 10 dates. Any reference to version, older then two releases ago would be warrant low-severity moderate-certanity notification. After all, how often do we have something like 2.76-4 in code is not version?
Bug#917566: lintian: please warn about non-supported previous versions
Package: lintian Version: 2.5.117 Severity: wishlist Dear Maintainer, please add information tag about references to ancient package version in maintainer scripts. As far as I know [citation needed], Debian only supports upgrades of consequenced releases -- it means that maintainer is not obliged to make sure that Debian 8 -> Debian 10 (skipping Debian 9) works smoothly. As such, comprasions with versions, older then oldstable in maintainer script (dpkg --compare-versions "$2" '<<' "when-world-was-young") could be dropped. I'd argue, that they should be dropped, since it is not going to be tested. As of implementation side, given that Lintian by design do not use network, it is possible to assume that Debian release happens once a 2.5 year (or so), so versions older then 5.5 years (possible to lookup in d/changelog) are below threhold. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8) Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) Versions of packages lintian depends on: ii binutils 2.31.1-11 ii bzip2 1.0.6-9 ii diffstat 1.62-1 ii dpkg 1.19.2 ii dpkg-dev 1.19.2 ii file 1:5.34-2 ii gettext0.19.8.1-9 ii gpg2.2.12-1 ii intltool-debian0.35.0+20060710.4 ii libapt-pkg-perl0.1.34+b1 ii libarchive-zip-perl1.64-1 ii libcgi-pm-perl 4.40-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.41-1+b1 pn libdigest-sha-perl ii libdpkg-perl 1.19.2 ii libemail-valid-perl1.202-1 pn libfile-basedir-perl ii libipc-run-perl20180523.0-1 ii liblist-moreutils-perl 0.416-1+b4 ii libparse-debianchangelog-perl 1.2.0-13 pn libtext-levenshtein-perl pn libtimedate-perl ii liburi-perl1.74-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.75+repack-1 ii man-db 2.8.4-3 ii patchutils 0.3.4-2 ii perl 5.28.1-3 ii t1utils1.41-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: pn libperlio-gzip-perl Versions of packages lintian suggests: pn binutils-multiarch ii libhtml-parser-perl3.72-3+b3 pn libtext-template-perl -- no debconf information -- debsums errors found: debsums: changed file /usr/share/lintian/checks/cruft.pm (from lintian package) pgpGgTj4SUysO.pgp Description: PGP signature
Bug#917568: stterm: incorrect termname
Package: stterm Version: 0.8.1-1 Severity: normal Dear Maintainer, It seems, that using st-256color TERM name for st=0.8 is incorrect. Note, that ncurses-term provides several versions of `st' terminfo database: /usr/share/terminfo/s/st /usr/share/terminfo/s/st-0.6 /usr/share/terminfo/s/st-0.7 /usr/share/terminfo/s/st-16color /usr/share/terminfo/s/st-256color /usr/share/terminfo/s/st-direct /usr/share/terminfo/s/stterm-16color I am no terminfo expert, but seems last update broke my dvtm setup. st=0.8-1 with TERM=st-256color looks bad, while with TERM=st-0.7 looks okay. I attach compressed screencast (created with bin:termrec) for demonstration. Download it and play like following: $ termplay out.rec -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8) Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) Versions of packages stterm depends on: ii libc6 2.28-3 ii libfontconfig1 2.13.1-2 ii libfreetype62.9.1-3 ii libx11-62:1.6.7-1 ii libxft2 2.3.2-2 ii ncurses-term6.1+20181013-1 stterm recommends no packages. stterm suggests no packages. -- no debconf information out.rec.xz Description: out.rec.xz pgpXCvb7KnAvn.pgp Description: PGP signature
Bug#917567: lintian: warn about manual calls to dpkg-maintscript-helper
Package: lintian Version: 2.5.117 Severity: wishlist Dear Maintainer, please warn about manual calls to dpkg-maintscript-helper in maintainer script. It is quite repetive task, automated by debhelper (see dh_debinstall(1)). -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8) Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) Versions of packages lintian depends on: ii binutils 2.31.1-11 ii bzip2 1.0.6-9 ii diffstat 1.62-1 ii dpkg 1.19.2 ii dpkg-dev 1.19.2 ii file 1:5.34-2 ii gettext0.19.8.1-9 ii gpg2.2.12-1 ii intltool-debian0.35.0+20060710.4 ii libapt-pkg-perl0.1.34+b1 ii libarchive-zip-perl1.64-1 ii libcgi-pm-perl 4.40-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.41-1+b1 pn libdigest-sha-perl ii libdpkg-perl 1.19.2 ii libemail-valid-perl1.202-1 pn libfile-basedir-perl ii libipc-run-perl20180523.0-1 ii liblist-moreutils-perl 0.416-1+b4 ii libparse-debianchangelog-perl 1.2.0-13 pn libtext-levenshtein-perl pn libtimedate-perl ii liburi-perl1.74-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.75+repack-1 ii man-db 2.8.4-3 ii patchutils 0.3.4-2 ii perl 5.28.1-3 ii t1utils1.41-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: pn libperlio-gzip-perl Versions of packages lintian suggests: pn binutils-multiarch ii libhtml-parser-perl3.72-3+b3 pn libtext-template-perl -- no debconf information -- debsums errors found: debsums: changed file /usr/share/lintian/checks/cruft.pm (from lintian package) pgpEmLczaHjyQ.pgp Description: PGP signature
Bug#749559: sysvinit: Can't power off jessie from gnome poweroff menu
[2019-01-02 09:59] Mark Hindley > control: reassign -1 systemd-shim > > On Tue, Jan 01, 2019 at 10:38:24PM +0000, Dmitry Bogatov wrote: > > Reassigning to elogind, that, as I understand it should provide required > > compatibility layer. > > Dmitry, > > elogind can provide this functionality now. However, isn't wasn't even present > in the archive for Jessie! > > I agree with Simon that, for the subitter, this seems likely to be a > systemd-shim bug. systemd-shim is no longer in Debian, as far as I can tell.
Bug#917568: stterm: incorrect termname
[2019-01-02 18:43] Paride Legovini > Dmitry Bogatov wrote on 28/12/2018: > > It seems, that using st-256color TERM name for st=0.8 is incorrect. > > > > I am no terminfo expert, but seems last update broke my dvtm setup. > > st=0.8-1 with TERM=st-256color looks bad, while with TERM=st-0.7 looks > > okay. > > Hello Dmitry, sorry for the late reply, I was on vacation. > > TERM=st-256color is what upstream uses by default. I can reproduce the > issue you describe with dvtm 0.15-5 and stterm 0.8.1-1 but also with > xterm with TERM=xterm-256color, so I am prone to think that the problem > is with dvtm. Sorry, can not reproduce bug with xterm. > Since dvtm 0.15 has been released I see that a few color handling > patches were merged, and indeed I can't reproduce the issue with the > latest git version. Could you please give it a try? Confirmed. Git HEAD (g311a8c0) works fine. I will upload this version of dvtm.
Bug#918689: debbugs: cannot stat '/usr/share/doc/debbugs/examples/text'
Source: debbugs Severity: wishlist Dear Maintainer, today I tried to install debbugs and first command I was suggested to run by README.Debian was `debbugsconf', which outputs error: cp: cannot stat '/usr/share/doc/debbugs/examples/text': No such file or directory No such file or directory at /usr/sbin/debbugsconf line 82. It is true, but /usr/share/doc/debbugs/examples/text.gz exists instead. My wild guess is that dh_compress(1) did it. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) pgpAoprBt9Gli.pgp Description: PGP signature
Bug#551555: mountnfs.sh: start should declare dependency on name resolver
control: tags -1 +moreinfo [2009-10-19 08:02] Petter Reinholdtsen > [Ben Finney] > > When mounting NFS volumes, the ???mountnfs.sh??? script needs the > > name resolver to be started in order to resolve the NFS server's > > name. The init script should have a ???Required-Start??? field > > declaring a dependency on the name resolver service. > > I agree. Which name resolver service did you have in mind. > > Unfortunately $named can not be listed as a dependency for > mountnfs.sh, as it would generate a dependency loop. First of all, > all known implementations of $named start in rc2.d, while mountnfs.sh > need to happen in rcS.d/ if /usr/ is an NFS volume. Correct me if I am wrong, but on modern installations /usr is mounted by initramfs (note usrmerge initiative), so I believe we could move mountnfs.sh from S to (2 3 4 5) (with some modifications to not try mount multiple times). Objections?
Bug#917566: lintian: please warn about non-supported previous versions
[2019-01-06 23:10] Chris Lamb > Hi Dmitry, > > > Probably I missing something oblivious, but still: if you know that > > version X is latest > > […] > > I think it was me who was missing oblivious; your pseudocode helped > clarify what you were after so thanks for persevering. > > > grep -v '#' $maintscript | grep -F "$v" ; then > > Can we make this bit smarter? Or rather; can we? I'm wondering if > we might be grepping for "1.2-3" but the script uses "dpkg -- > compare-versions $X -gte 1.2" or something like that.. As far as I can tell, scrolling several pages on codesearch, maintainers usually compare either with 1.2-3 or 1.2~. On other hand, I have nothing to support idea, that bare 1.2 would decrease accuracity. > > But issue is not sysvinit-specific. I have number of packages, that have > > code in maintainer scripts, that deals with upgrades from specific > > versions > Can you link to some concrete examples on this bug report if you > have a moment? Sure. There is 180 pages of checks on codesearch[^1]. I did not dig, how much of them are pre-oldstable, but at least following are: * vim-common * openssh * xorg-server [^1] https://codesearch.debian.net/search/?q=--compare-versions
Bug#444980: udev not restarted after exiting runlevel 1
control: tags -1 +moreinfo Seems old discussion did not ended in solution. Let us try again. Dear udev maintainers, did anything changed? Are there still problems running /etc/init.d/udev from runlevel 1 (when udev daemon was killed) manually by sysadmin to restart it? [2010-06-05 09:05] Petter Reinholdtsen > [Henrique de Moraes Holschuh] > > Trying to track that is a losing proposition. You'd also need to add > > dhclient and other dhcp clients, wpa supplicant helpers, pppoe > > helpers... > > My idea is to implement some omitpid feature like the one we use for > shutdown in the killprocs script, to allow udev to survive runlevel 1. > With it in place, the other daemons that want to keep running can > register their pid there. > > > Our S runlevel does way too much, which obviously screws up runlevel > > 1 a great deal. > > Yeah. There is a lot of work left before single user and runlevel 1 > on Debian is working properly, and allow one to enter runlevel 1 and > return to runlevel 2. At the moment a reboot is needed after > switching to runlevel 1 to be sure to recover the machine state. > > But udev should probably keep running also in runlevel 1, so such > mechanism is probably smart to implement anyway. > > Happy hacking, > -- > Petter Reinholdtsen
Bug#915978: devscripts: salsa error Unknown command fork
Package: devscripts
Version: 2.18.11
Severity: normal
Dear Maintainer,
I installed devscripts/experimental to get `salsa' script and did
following:
$ salsa fork lintian/lintian --verbose
and got this:
salsa error Unknown command fork
salsa info: Can't locate Devscripts/Salsa/chechout.pm in @INC (you may need to
install the Devscripts::Salsa::chechout module) (@INC contains: /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.28.1 /usr/local/share/perl/5.28.1
/usr/lib/x86_64-linux-gnu/perl5/5.28 /usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl/5.28 /usr/share/perl/5.28
/usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at
/usr/share/perl5/Module/Runtime.pm line 314.
at /usr/share/perl5/Devscripts/Salsa/fork.pm line 9.
Compilation failed in require at /usr/share/perl5/Module/Runtime.pm line 314.
According to salsa(1) it is valid:
fork
Forks a project in group/user repository and set "upstream" to
original project. Example:
$ salsa fork js-team/node-mongodb --verbose
...
salsa.pl info: node-mongodb ready in node-mongodb/
$ cd node-mongodb
$ git remote --verbose show
origin g...@salsa.debian.org:me/node-mongodb (fetch)
origin g...@salsa.debian.org:me/node-mongodb (push)
upstreamg...@salsa.debian.org:js-team/node-mongodb (fetch)
upstreamg...@salsa.debian.org:js-team/node-mongodb (push)
For a group:
salsa fork --group js-team user/node-foo
Oh, and by the way, it is quite unfortunate, that reportbug by default
insert content of ~/.devscripts into bugreport. It could contain quite
sensible SALSA_TOKEN. Not sure, whether it is bug in devscripts or
reportbub.
-- Package-specific info:
--- /etc/devscripts.conf ---
--- ~/.devscripts ---
SALSA_TOKEN=$(pass access/git/salsa.debian.org/kaction | awk 'NR == 2 { print
$2 }')
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to
C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled
Versions of packages devscripts depends on:
ii dpkg-dev 1.19.2
ii fakeroot 1.23-1
ii file 1:5.34-2
ii gnupg 2.2.11-1
ii gnupg22.2.11-1
ii gpgv 2.2.11-1
ii libc6 2.28-2
ii libfile-homedir-perl 1.004-1
ii libfile-which-perl1.22-1
ii libipc-run-perl 20180523.0-1
ii libmoo-perl 2.003004-2
ii libwww-perl 6.36-1
ii patchutils0.3.4-2
ii perl 5.28.1-3
ii python3 3.7.1-2
ii sensible-utils0.0.12
ii wdiff 1.2.2-2+b1
Versions of packages devscripts recommends:
ii apt 1.8.0~alpha2
pn at
ii curl7.62.0-1
ii dctrl-tools 2.24-3
pn debian-keyring
ii dput1.0.2
ii equivs 2.2.0
ii libdistro-info-perl 0.20
ii libdpkg-perl1.19.2
ii libencode-locale-perl 1.05-1
ii libgit-wrapper-perl 0.048-1
ii libgitlab-api-v4-perl 0.13-1
ii liblist-compare-perl0.53-1
ii liblwp-protocol-https-perl 6.07-2
pn libsoap-lite-perl
ii libstring-shellquote-perl 1.04-1
ii libtry-tiny-perl0.30-1
ii liburi-perl 1.74-1
pn licensecheck
ii lintian 2.5.116
ii man-db 2.8.4-3
ii patch 2.7.6-3
ii python3-apt 1.7.0
ii python3-debian 0.1.33
ii python3-magic 2:0.4.15-2
ii python3-requests2.20.0-2
ii python3-unidiff 0.5.4-1
ii python3-xdg 0.25-4
ii strace 4.21-1
ii unzip 6.0-21
ii wget1.19.5-2
ii xz-utils5.2.2-1.3
Versions of packages devscripts suggests:
pn adequate
pn autopkgtest
pn bls-standalone
ii bsd-mailx [mailx]8.1.2-0.20180807cvs-1
ii build-essential 12.5
pn check-all-the-things
pn cvs-buildpackage
pn devscripts-el
ii diffoscope 107
pn disorderfs
pn dose-extra
pn duck
ii faketime 0.9.7-3
pn gnuplot
pn how-can-i-help
pn libauthen-sasl-perl
pn libdbd-pg-perl
ii libfile-desktopentry-perl0.22-1
pn libnet-smtps-perl
Bug#916021: lintian: Please check for references to build directory
Package: lintian
Version: 2.5.116
Severity: wishlist
Dear Maintainer,
please add check, that files in binary packages do not refer to build
directory. See (#915511) for example.
I believe the following strings should raise warning:
/build/{name}
/build/{name}-{version}
$PWD
Bug#916023: lintian: Please check if architecture could be "all" instead of "any"
Package: lintian Version: 2.5.116 Severity: wishlist Dear Maintainer, please add check, that binary package could have "Architecture: all" instead of "any". See #915976 for example. I believe checking that none of files in package have ELF magic is quite reliable.
Bug#725970: sysv-rc: Disable "concurrency" boot via boot parameter
control: tags -1 +moreinfo [2013-10-10 21:34] Steven Shiau > It would be great if the "concurrency" boot could be disabled via a > boot parameter (e.g. none-concurrency). This will be easier for > debugging and customization. Attached please find a patch about this. Looks good to me. I'd rename flag to concurrency=none and applied patch. Dear co-maintainers, objections?
Bug#810704: reassign
control: reassign -1 init-system-helpers update-rc.d belongs to bin:init-system-helpers. Reassigning. [2016-01-24 16:05] Salvo 'LtWorf' Tomaselli > > part text/plain 268 > reassign 810704 sysv-rc > thanks > > The file is not created by xinetd. > > Upon removing, /usr/sbin/update-rc.d gets called to > disable xinetd and that is where the file is created. > > See line 107 in /usr/sbin/update-rc.d > > Thus, I don't think this bug is specific for xinetd.
Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile
control: tags -1 +moreinfo
[2015-12-01 23:07] Petter Reinholdtsen
> In my view, /etc/init.d/rc and /etc/init.d/rcS should not be
> conffiles. They should be moved to /lib/init/ instead.
Dear co-maintainers, what about actually moving /etc/init.d/{rc,rcS}
into /lib/init and adding symbolic links?
Any objections to this approach?
Bug#789008: At least on Debian testing it upgraded without an issue.
control: tags -1 +moreinfo [2018-12-18 12:10] shirish शिरीष > > Dear all, > > At least here it updated without any issues - > > $ sudo aptitude install insserv -y > The following packages will be upgraded: > insserv > [...] Thank you for help with bug triage, shirish. Dear submitter, can you reproduce issue? Note, that insserv=1.16 is no longer relevant, since now insserv=1.18 in sid and insserv=1.14 in stable.
Bug#661314: insserv: script is not an executable regular file, skipped!
control: reassign -1 insserv control: tags -1 +moreinfo > update-rc.d: using dependency based boot sequencing > insserv: script vsftpd is not an executable regular file, skipped! > > However vsftpd was not skipped --- the "update-rc.d vsftpd disable" > command behaves exactly the way I'd have wanted, even after the init > script is marked executable again. > > What is this message intended to convey? Could it be reworded? > > The non-executable script gets ignored, then later when insserv updates the > symlink farm based on the overall dependency graph (which doesn't include the > skipped script), symlinks to scripts which do not exist or are invalid are > removed. > Ok, so that is what the message wants to say. How about: > insserv: script vsftpd is not executable, will be skipped in boot sequence! > insserv: script vsftpd is not a regular file, will be skipped in boot > sequence! Jesse, what do you think about proposed rewording? If you agree, please tag as +fixed-upstream, otherwise tag as +wontfix and close. Thank you.
Bug#694986: flash-kernel: postinst modifies /etc/default/rcS
control: tag -1 +moreinfo [2014-11-11 20:32] Petter Reinholdtsen > Control: severity -1 important > > I'm not sure this is fixable, but I am sure it isn't release critical. > Reduce the severity to important to reflect this fact. Dear co-maintainers and maintainers of flash-kernel, what is current state of issue? * Does FSCKFIX=yes still wanted by `flash-kernel' package? * What will break if FSCKFIX=yes will be set on by default? One part of code, affected by value of FSCKFIX is checkroot.sh:213: if [ "$FSCKFIX" = yes ] then fix="-y" else fix="-a" fi This `fix' variable is used as argument at checkroot.sh:234: logsave -s $FSCK_LOGFILE fsck $spinner $force $fix -t $roottype $rootdev By the way neither -a nor -y mentioned in fsck(8) (but mentioned in fsck.ext4(8)). Is it okay?
Bug#717358: Incorrect comments in rc script
control: tags -1 +moreinfo [2013-07-19 22:41] Алексей Шилин > Dear maintainers, > > There are comments in /etc/init.d/rc script, which say, that init scipts are > being run in parallel [1] [2]. > However, the code flow suggests exactly the opposite: they both occur in > sections, which are executed only if > $CONCURRENCY value is *not* "makefile", and therefore the non-parallel > `startup' function variant is being > used. > > [1] > http://sources.debian.net/src/sysvinit/2.88dsf-43/debian/src/sysv-rc/etc/init.d/rc#L151 > [2] > http://sources.debian.net/src/sysvinit/2.88dsf-43/debian/src/sysv-rc/etc/init.d/rc#L200 I can confirm issue, but I am not that familiar with code to fix these misleading commends. What about just removing them for now? Opinions?
Bug#547608: better URLs for policy doc
control: tags -1 +moreinfo [2009-09-21 10:15] jida...@jidanni.org > > For Debian, this information is contained in the policy manual, chapter > > "System run levels and init.d scripts". The Debian Policy Manual is > > available at: > > OK, then I would just say > +file:///usr/share/doc/debian-policy/policy.html/index.html#contents > +file://localhost/usr/share/doc/debian-policy/index.html#contents > +http://www.debian.org/doc/debian-policy/index.html#contents > instead of all the below > -http://www.debian.org/doc/debian-policy/#contents > - > -The Debian Policy Manual is also available in the Debian package > -"debian-policy". When this package is installed, the policy manual can be > -found in directory /usr/share/doc/debian-policy. If you have a browser > -installed you can probably read it at Not sure it is good thing. You propose to remove information, that bin:debian-policy must be installed for local reading of Debian Policy. It might be valuable for admins, not proficent with Debian. Dear co-maintainers, opinions?
Bug#496708: libpam0g: postinst starts kdm despite being in single-user mode
control: reassign -1 init-system-helpers Reassigning to init-system-helpers, currently providing update-rc.d(8) [2008-08-26 15:22] Steve Langasek > pam is using the standard invoke-rc.d interface which all maintainer scripts > are supposed to use. This is a bug in sysv-rc for not implementing a > correct policy in single-user mode, and has previously been reported; > reassigning to sysv-rc and merging with that report.
Bug#538304: Clarifying a few things
[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? While in this particular case submitter (Petter Reinholdtsen) is subscribed to list, in general you may want to add NNN-submitter address to make sure, that initial submitter read your email. Thank you for your work, Jesse. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#914788: Please don't enable getty services for tty devices that don't exist
[2019-01-25 10:34] Andras Korn
> I believe instead of
>
> rm /etc/service/getty-@TTY@
>
> you should do
>
> rm "$(pwd)"
>
> because then it won't matter what the service is called and where the
> runsvdir root is (/etc/service or somewhere else).
I find it unsafe. Explicit is better implicit.
> Also, this seems redundant:
>
> #!/usr/bin/env /lib/runit/invoke-run
>
> why not just "#!/lib/runit/invoke-run"?
Because kFreeBSD kernel requires script interpreter to be compiled.
Portability.
> While invoke-run, as an interpreter, is an original idea, I'd make it a
> scriptlet a run script can source via ". /lib/runit/invoke-run". Then it
> wouldn't be necessary to export all variables the configuration sets and
> thereby clutter the environment of the daemon.
>
> The envdir bit could be handled by a construct like
>
> if [ -z "$1" ]; then
> SVDIR="$(dirname $(readlink -f "$0")"
> if [ -e "$SVDIR/conf" ]; then
> exec chpst -e "$SVDIR/conf" -- "$0" "envdir-done"
> fi
Complicated. And depends on $0 trickery. We, at sysvinit team, had
problems with $0 trickery.
What is so bad about cluttering environment of daemon?
> (But then /etc/default/foo would have to take precedence over sv/foo/conf,
> because the /etc/default/foo variables would be lost during the exec since
> we want to avoid exporting them.)
This too. I want daemontools-style take precedence over sysvinit style.
> > Please,
> >
> > * build it (it will build runit-2.1.2-22, sorry for version havoc)
> > * install bin:runit
> > * install bin:getty-run
> > * write "yes" into /etc/getty-tty1/conf/GIVE_UP_ON_MISSING_TTY file
>
> While this would work, it doesn't improve my situation: you're making me
> jump through hoops to get sensible behaviour. Creating these files isn't
> less effort than deleting the getty services on installation, so it just
> adds complexity and abstraction with no real benefit.
Not exactly. You mentioned that option to pre-seed debconf would help
you. I provide you with way to pre-provision system -- create
/etc/default/getty-tty{1..6} before installing runit.
After installing getty-run, you would get behaviour you want. Or I
missed the point?
> I still think the postinst modification I suggested (not installing
> getty services for non-existing tty devices) would be the cleanest
> solution.
And what if there were no tty on installation time, and after that they
appeared? (No idea, why, never dealt with devices without tty.)
As you can understand, I am wary about defaulting on behavior, that can
leave user without means to login.
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#914788: Please don't enable getty services for tty devices that don't exist
[2019-01-18 20:27] Andras Korn
> sorry, didn't look at bug mail for a while.
>
> > > However, whenever the getty-run package is installed in a vserver, I have
> > > to
> > > manually remove the /service/getty-tty* symlinks.
> > >
> > > Can you please modify the postinst script so it only installs getty
> > > services
> > > for /dev/tty* devices that are actually there?
> >
> > I do not like maintainer scripts. They are pain to get right. I can
> > propose you to pre-provision your servers with
> > `/etc/sv/getty{1-6}-run/down' file. See runsv(8).
>
> That would still leave the runsv processes around and clutter the output of
> "sv status /service/*".
>
> The following postinst snippet should work:
>
> export NAME='getty-tty1'
> if [ -c /dev/tty1 ]; then
> export ENABLE='yes'
> else
> export ENABLE='no'
> fi
>
> # Unlike postrm, I can be sure, that runit-helper is present on
> # postinst.
> /lib/runit-helper/runit-helper postinst "$@"
>
> ... and so on for the other ttys. (A lesser man would have used a for loop. :)
>
> (Alternatively, the getty run scripts could start with something like this:
>
> [ -c /dev/ttyX ] || rm /etc/service/getty-ttyX
>
> and /etc/runit/1 could re-create these symlinks, just to be absolutely sure.
>
> I don't like this approach; there is too much going on automatically.)
>
> Or, you could add a debconf question with low priority, defaulting to "yes",
> on whether to add the getty service symlinks. I could pre-seed debconf in
> vservers with "no".
I believe I found quite decent solution. Take a look at `bugfix/914788'
branch.
Please,
* build it (it will build runit-2.1.2-22, sorry for version havoc)
* install bin:runit
* install bin:getty-run
* write "yes" into /etc/getty-tty1/conf/GIVE_UP_ON_MISSING_TTY file
* did it help?
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#785687: Duplicate bug
control: tags -1 +fixed-upstream control: forcemerge 573571 -1 [2019-01-20 18:10] Jesse Smith > This report is a duplicate of bug #573571. > > It has been fixed upstream and the fix will appear in insserv-1.19.0.
Bug#920618: initscripts: errors with /dev/shm on Hurd
Package: initscripts Version: 2.93-5 Severity: wishlist [ Originally reported by Svante Signell ] Hi, we have some problems with the latest fixes of sysvinit for GNU/Hurd. * Make /run/shm symlink to /dev/shm, not other way around (Closes: #851427) Boot messages: mkdir: Cannot create directory /dev/shm: File exists Mount point '/dev/shm' does not exist. Skipping mount. touch: cannot touch '/dev/shm/.tmpfs': Too many levels of symbolic links. Cleaning up temporary files... failed! startpar: service(s) returned failure: checkroot-bootclean.sh mountall- bootclean.sh mountnfs.sh ... failed! /run/shm is created by the hurd package, causing a conflict with initscripts. rgrep /run/shm /etc/hurd /etc/hurd/rc:mkdir -p /run/lock /run/shm dpkg -S /etc/hurd/rc hurd: /etc/hurd/rc - Either the creation of /run/shm in hurd should be removed or creation of the symbolic link /run/shm in initscripts should be removed for Hurd. /dev/shm is already a symbolic link to /run/shm: file /dev/shm /dev/shm: symbolic link to /run/shm ls -l /dev/shm lrwxr-xr-x 1 root root 8 Jan 20 2017 /dev/shm -> /run/shm pgpMQXXRcfh6Z.pgp Description: PGP signature
Bug#920658: RFP: sedsed -- sed script debugger
Package: wnpp Severity: wishlist * Package name: sedsed Version : 1.0 Upstream Author : Aurelio Jargas * URL : http://aurelio.net/projects/sedsed * License : MIT Programming Lang: Python2 Description : sed script debugger sedsed can debug, indent, tokenize and HTMLize your sed scripts. In debug mode it reads your script and add extra commands to it. When executed you can see the data flow between the commands, revealing all the magic sed does on its internal buffers. In indent mode your script is reformatted with standard spacing. In tokenize mode you can see the elements of every command you use. In HTMLize mode your script is converted to a beautiful colored HTML file, with all the commands and parameters identified for your viewing pleasure. With sedsed you can master ANY sed script. No more secrets, no more hidden buffers.
Bug#920699: lintian: check for .pc files without matching .so
Package: lintian Version: 2.5.123 Severity: wishlist Dear Maintainer, please consider implementing check for packages, that have pkg-config files, but do not provide associated shared libraries. This suggestion is inspired by #919180: package libcapnp-dev installs `kj-http.pc', with $ pkg-config --libs kj-http.pc -lkj-http -lkj-async -lkj but shared library kj-http is not installed. Format of pkg-config files seems to be rather simple, so something as crude, as $ grep '^Libs:' foo.pc | tr ' ' '\n' | grep -- '^-l' might give list of libraries that must be present. -- System Information: Debian Release: buster/sid 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-1-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 lintian depends on: ii binutils 2.31.1-11 ii bzip2 1.0.6-9 ii diffstat 1.62-1 ii dpkg 1.19.2 ii dpkg-dev 1.19.2 ii file 1:5.35-2 ii gettext0.19.8.1-9 ii gpg2.2.12-1 ii intltool-debian0.35.0+20060710.4 ii libapt-pkg-perl0.1.34+b1 ii libarchive-zip-perl1.64-1 ii libcgi-pm-perl 4.40-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.41-1+b1 pn libdigest-sha-perl ii libdpkg-perl 1.19.2 ii libemail-valid-perl1.202-1 pn libfile-basedir-perl ii libio-async-perl 0.72-1 ii libipc-run-perl20180523.0-1 ii liblist-moreutils-perl 0.416-1+b4 ii libparse-debianchangelog-perl 1.2.0-13 pn libtext-levenshtein-perl pn libtimedate-perl ii liburi-perl1.76-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.76+repack-1 ii man-db 2.8.5-1 ii patchutils 0.3.4-2 ii perl 5.28.1-3 ii t1utils1.41-3 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: pn libperlio-gzip-perl Versions of packages lintian suggests: pn binutils-multiarch ii libhtml-parser-perl3.72-3+b3 pn libtext-template-perl -- no debconf information pgpm94FOMd1Oa.pgp Description: PGP signature
Bug#920323: initscripts: /dev/shm mounting failure on stale static /dev
control: tags -1 +pending [2019-01-24 07:42] Pierre Ynard > part 1 text/plain1633 > Package: initscripts > Version: 2.93-5 > Severity: normal > Tags: patch > > I haven't actually confirmed the bug, but just reading the code I > think there's a problem. After 2.93-4 resolved #851427 by reversing > the /dev/shm -> /run/shm symlink to /run/shm -> /dev/shm, on a system > running a static /dev, the following /lib/init/mount-functions.sh > mount_shm() code should hit the previous /dev/shm symlink: > [...] I agree with your reasoning. Any other considerations, collegues? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#920558: RFS: liboauth/1.0.3-2 [QA]
[2019-01-27 10:59] Carlos Maddela > > part text/plain1706 > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "liboauth" > > * Package name: liboauth >Version : 1.0.3-2 >Upstream Author : Robin Gareus > * URL : http://liboauth.sourceforge.net/ > * License : Expat >Section : libs > > It builds these binary packages: > > liboauth-dev - C library implementing OAuth Core 1.0a API (development files) > liboauth0 - C library implementing OAuth Core 1.0a API (runtime) > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/liboauth > > > Alternatively, one can download the package with dget using this command: > > dget -ux > https://mentors.debian.net/debian/pool/main/libo/liboauth/liboauth_1.0.3-2.dsc Uploaded. By the way, what is the purpose of dh_autoreconf --as-needed? PS. Thank you, I learnt about future=+lfs. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#867747: rsyslog: /var/log/dmesg world-readable despite kernel.dmesg_restrict = 1
control: tags -1 +moreinfo control: forcemerge -1 570358 [2019-01-24 10:17] Pierre Ynard > > part text/plain 742 > > Interesting. On my system `/var/log/dmesg' is 640, root:adm, which is > > quite restrictive. If I run `/etc/init.d/bootlogs' again, it stays so. > > > > But if I remove `/var/log/dmesg' and re-run `/etc/init.d/bootlogs', > > `/var/log/dmesg' becomes 644. > > > > I believe adjustment to `/etc/init.d/bootlogs' to check > > `kernel.dmesg_restrict' is needed. By the way, any ideas how could I > > have 640 `/var/log/dmesg' in first place? > > initscripts's postinst script sets the permissions to 640 if the file > doesn't exist. > > Setting /var/log/dmesg permissions according to kernel.dmesg_restrict > seems to make sense but I'm a bit skeptical. I suppose that the way it > keeps permissions set on it by the admin is both a bug and a feature. Why are you skeptical? I do not see, how syncing /var/log/dmesg permissions with kernel.dmesg_restrict could break things. Or am I missing something? Merging with #570358, since resolution to this bug would imply resolution to #570358. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#920698: mosh-server not found
Package: mosh Version: 1.3.2-2.1+b1 Severity: wishlist Dear Maintainer, maybe I am doing it wrong, but I fail to make mosh do anything. Any attempt to connect host results in: $ mosh kact...@people.debian.org bash: mosh-server: Komando ne trovita Connection to people.debian.org closed. /usr/bin/mosh: Did not find mosh server startup message. (Have you installed mosh on your server?) Isn't it the idea, that mosh-server gets installed automatically? Obliviously, I do not have permission to do `apt-get install mosh' on remote host. -- System Information: Debian Release: buster/sid 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-1-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 mosh depends on: ii dpkg1.19.2 ii libc6 2.28-5 ii libgcc1 1:8.2.0-14 ii libprotobuf17 3.6.1.3-1 ii libssl1.1 1.1.1a-1 ii libstdc++6 8.2.0-14 ii libtinfo6 6.1+20181013-1 ii libutempter01.1.6-3 ii openssh-client 1:7.9p1-5 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages mosh recommends: pn libio-socket-ip-perl mosh suggests no packages. -- no debconf information pgp7zuu24SBHK.pgp Description: PGP signature
Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'
[2019-01-23 12:41] Jonathan Nieder > Dmitry Bogatov wrote: > >> Jonathan Nieder wrote: > > >>> + * git-daemon-run: pre-create supervise directory so that postinst > >>> +can start the service (thx Celejar and Dmitry Bogatov; closes: > >>> +#919296). > [...] > > Wierd. It should work. /etc/sv/git-daemon/supervise is not dangling, is > > it? Tell me which git commit I should build and test, in effort to help > > debugging? > > It's not dangling. > > I tested with the debian-sid branch, with the patch in the message I > sent applied on top. That said: > > [...] > > It is my fault. I dropped /var/lib/supervise directory in runit=2.1.2-4, > > which was expected by git-daemon-run. > > > > Today runit packaging underwent quite a rework, and packages, providing > > runscripts are encouraged to use dh_runit(1). It manages creation of > > apporiate directories and symbolic links. If you have any issues, do not > > hezitate to ask -- runit is my top priority. > > Thanks, these are two good starting points. I'll take a look at the > 2.1.2-4 changes and into whether it's simple to use dh_runit. Hopefully > the latter will take care of everything. :) As promised, I applied patch over debian-sid branch and rebuilt package. It worked out-of-box, except on on postinst, it output warning about missing 'supervision/control', originating from this line: sv -v term git-daemon || : but it is harmless. You observe another, more buggy behaviour, don'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#920618: initscripts: errors with /dev/shm on Hurd
[2019-01-27 15:03] Samuel Thibault > Dmitry Bogatov, le dim. 27 janv. 2019 13:52:59 +, a ecrit: > > /run/shm is created by the hurd package, causing a conflict with > > initscripts. > > rgrep /run/shm /etc/hurd > > /etc/hurd/rc:mkdir -p /run/lock /run/shm > > > > dpkg -S /etc/hurd/rc > > hurd: /etc/hurd/rc > > > > - Either the creation of /run/shm in hurd should be removed or creation > > of the > > symbolic link /run/shm in initscripts should be removed for Hurd. > > I guess the shm part of debian/patches/run.patch can now be dropped > indeed. Anybody up to test that it boots fine and the issue goes away? Do you mean, that you plan to resolve current bug via changes in src:hurd? > The same patch creates /run/lock and /run/utmp, I guess initscripts > handles that too? Yes, initscripts handle them too. See /etc/init.d/bootmisc.sh -- 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#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#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#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#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#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#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#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#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#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#922915: initscripts: Please do not enable tmpfs-based shm on Hurd
[2019-02-21 21:33] Samuel Thibault > Hello, > > Please do not enable tmpfs-based shm by default on the Hurd yet, the > tmpfs implementation is not ready for that yet and triggers runtime > issues. > > The attached patch makes the default per-kernel, could you apply it? Well, yes; but I'd like not to keep it indefinitely. Please add comment with apporiate number of hurd bug. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#567071: what is the purpose of fstab-decode
control: tags -1 +fixed-upstream [2019-02-21 15:08] Jesse Smith > I agree, the manual page for fstab-decode is vague, at best. I will add > a paragraph explaining what it does. The updated manual page will be > included in sysvinit-2.94. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#905244: fstab-decode.8: Some formatting fixes in the manual
Jesse, what do you think?
[2018-08-02 01:07] Bjarni Ingi Gislason
> Package: sysvinit-utils
> Version: 2.88dsf-59.10
> Severity: minor
> Tags: patch
>
> Summary:
>
> Separate an ellipsis from the preceding string with a space.
>
> Add a missing italic correction or use a macro.
>
> Make a '"' being an argument to a macro
>
>
>
> Details:
>
> Input file is fstab-decode.8
>
> Test nr. 10:
>
> Separate an ellipsis from the preceding string with a space
> character, if it does not mean a continuation of it.
>
> See a manual of style about the difference between "abc..." and
> "abc ...".
>
> 25:\fB fstab-decode\fR \fICOMMAND\fR [\fIARGUMENT\fR]...
>
> #
>
>
> Test nr. 21:
>
> Use a macro to change to the italic font, instead of \fI [1], if
> possible.
> The macros have the italic corrections, but "\c" removes them.
>
> Or
>
> add the italic corrections.
> [1] man-pages(7) [package "manpages"]
>
> 25:\fB fstab-decode\fR \fICOMMAND\fR [\fIARGUMENT\fR]...
> 29:decodes escapes in the specified \fIARGUMENT\fRs
> 30:and uses them to run \fICOMMAND\fR.
> 41:Otherwise it exits with the status returned by \fICOMMAND\fR.
>
> #
>
> Make a quotation mark (") to be an argument to a macro.
>
> This fixes bug #567071
>
> ###
>
> Patch:
>
> --- fstab-decode.82017-09-08 19:18:37.0 +
> +++ fstab-decode.8.new2018-08-01 23:51:30.0 +
> @@ -22,11 +22,11 @@
> fstab-decode \- run a command with fstab-encoded arguments
>
> .SH SYNOPSIS
> -\fB fstab-decode\fR \fICOMMAND\fR [\fIARGUMENT\fR]...
> +\fB fstab-decode\fR \fICOMMAND\fR [\,\fIARGUMENT\fR \&.\|.\|.\&]
>
> .SH DESCRIPTION
> .B fstab-decode
> -decodes escapes in the specified \fIARGUMENT\fRs
> +decodes escapes in the specified \fIARGUMENT\/\fRs
> and uses them to run \fICOMMAND\fR.
> The argument escaping uses the same rules as path escaping in
> \fB/etc/fstab\fR,
> @@ -42,4 +42,4 @@ Otherwise it exits with the status retur
>
> .SH EXAMPLES
>
> -.B fstab-decode umount $(awk '$3 == "vfat" { print $2 }' /etc/fstab)
> +.B fstab-decode umount $(awk '$3 == """vfat""" { print $2 }' /etc/fstab)
>
>
> -- System Information:
> Debian Release: buster/sid
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500,
> 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.17.8-3 (SMP w/2 CPU cores)
> Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1),
> LANGUAGE=is_IS.iso88591 (charmap=IS
> O-8859-1)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
>
> Versions of packages sysvinit-utils depends on:
> ii init-system-helpers 1.51
> ii libc62.27-5
> ii util-linux 2.32-0.1
>
> sysvinit-utils recommends no packages.
>
> sysvinit-utils suggests no packages.
>
> -- no debconf information
>
> --
> Bjarni I. Gislason
>
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#843419: init-d-script: please provide a way to not use the --name option of start-stop-daemon
control: tags -1 +moreinfo [2016-11-06 16:04] Ferenc Wágner > Package: sysvinit-utils > Version: 2.88dsf-59 > Severity: wishlist > > Dear Maintainer, > > start-stop-daemon --name=name-longer-than-15-characters fails on Linux, > because of the 15-character limit on process names. Other kernels have > similar but different limits, see the conditionals starting at > https://anonscm.debian.org/cgit/dpkg/dpkg.git/tree/utils/start-stop-daemon.c#n134 > Looks like executable names longer than 14 characters are incompatible > with the --name option. (15 works, but can be mistaken for truncated > longer names.) Currently the only solution is overriding do_start_cmd() > and do_stop_cmd(). Please proide an easier one. Sorry, I do not understand. You, as init script writer, choose value of argument to $NAME. Why can't you limit it to required length? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#761511: misleading message about mount points in /etc/fstab
control: merge -1 818442 [2019-02-19 03:55] Pierre Ynard > > Seems so. This string is still present. I will take a look why it is > > there, and under what circumstances this suggestion is printed. > > This message can be wrongly printed because of at least #818442 > (read-only /dev). In fact it gets printed only if `rm -fr /dev/shm` > fails, and there aren't too many possible causes for that apart from > genuine mount mishaps and #818442, so it might just be a variation of > it, involving some NFS code path apparently. Then merging. Thank you for triaging. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#692559: RAMTMP is missing too
control: retitle -1 Document CONCURRENCY variable of rcS [2019-02-22 09:48] Pierre Ynard > > part text/plain 689 > > No, no, I do not plan to remove it. Probably, at least comment in > > /etc/default/tmpfs regarding it should be added. > > RAMTMP is already documented in both /etc/default/tmpfs and the tmpfs(5) > man page. Okay, so we only miss CONCURRENCY. Actually, we would have not only documentation, but also code change, since rcS does not respect CONCURRENCY from /etc/default/rcS: * on line 55 `/etc/default/rcS' is sources * on line 72 CONCURRENCY is uncoditionally set to 'makefile' Maybe support for option concurrency=none already in place is enough? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#444980: udev not restarted after exiting runlevel 1
control: reassign -1 udev [2019-02-19 15:01] Pierre Ynard > As said in the history of the thread, this isn't a problem particular > to udev. portmap was mentioned. On my system I also have that issue > with rdnssd: it is started in runlevel S before networking, and isn't > restarted when leaving runlevel 1. Then there are all the network > processes such as at least dhclient, and worse than not being restarted, > the interfaces are not even marked as brought down when going into > runlevel 1. > > I tried to fiddle with LSB headers and rc symlinks to get udev and > rdnssd to restart in runlevel 2, but I guess I don't know how sysv-rc > works anymore because I couldn't get anywhere, and anyway I don't > want to mess with it too much. In the end I added restart logic in > /etc/rc.local and it seems to work fine; and I switch in and out of > runlevel 1 all the time. > > I don't see why we couldn't properly fix this to have each of them shut > down cleanly in runlevel 1 and then restart in runlevel 2. When I look > at udev's initscript, it seems like it must be much better in that > regard now than what was described 10 years ago. Probably we can, just nobody did it. Sorry, I am not up to this. Reassigned to udev, since /etc/init.d/udev belongs to bin:udev. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#922815: insserv FATAL while updating as mountkernfs has to be enabled to use service udev
[2019-02-22 15:30] shirish शिरीष > > > > > > Setting up udev (240-6) ... > > > update-initramfs: deferring update (trigger activated) > > > insserv: FATAL: service mountkernfs has to be enabled to use service udev > > > > > > maybe it just needs mountkernfs to be added in the interactive bit at > > > the bottom or somewhere else ? > > [Dmitry Bogatov] > > Maybe. But I updated recently, and I did not encountered this problem. > > Please test my wild guess: > > > > $ find /etc/rcS.d|grep mountkernfs > > > Dear Dmitry, > > The output is empty or zero - > > shirish@debian:~$ find /etc/rcS.d|grep mountkernfs > shirish@debian:~$ Interesting, you seems somehow got mountkernfs.sh script removed from runlevel S. Can you please invoke as root # update-rc.d mountkernfs.sh enable S and then retry your upgrade. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#768555: bootlogd apparantly runs but /var/log/bootlog* files are from 2013
[2019-02-23 03:13] Pierre Ynard > > /etc/init.d/bootlogd [Errno 2] No such file or directory: > > u'/etc/init.d/bootlogd' > > /etc/init.d/stop-bootlogd [Errno 2] No such file or directory: > > u'/etc/init.d/stop-bootlogd' > > /etc/init.d/stop-bootlogd-single [Errno 2] No such file or directory: > > u'/etc/init.d/stop-bootlogd-single' > > Other reports featuring missing init scripts can be found in #663587 and > #689992, both originally about different issues. Reports in #689992 only > miss /etc/init.d/stop-bootlogd and /etc/init.d/stop-bootlogd-single, not > /etc/init.d/bootlogd We can forcemerge them and close on timeout, correct? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
