Bug#545311: insserv: provide a way to ignore a script when a file is not installed
control: tags -1 +wontfix control: close -1 [2009-09-06 13:46] Michael Schutte > Package: insserv > Version: 1.12.0-11 > Severity: wishlist > > Hi, Hi. Sorry for late response. > Most init scripts in Debian start with a line like > > [ -x /usr/sbin/some-daemon ] || exit 0 > > to handle the common situation when a package has been removed, but not > purged. It would be nice if insserv could provide a way to ignore a > script altogether when a file isn’t there, for example via a new header > in the INIT INFO block: > > # X-If-Exists: /usr/sbin/some-daemon Currently, this line in hidden inside init-d-script(5), so repetition is gone. > This line usually isn’t needed because the scripts exit gracefully > anyway. Still, such a header would make it possible for mutually > exclusive init scripts from conflicting packages to provide the same > facility name. For example, /etc/init.d/some-daemon from the > some-daemon package could say > > # Provides: some-daemon > # X-If-Exists: /usr/sbin/some-daemon > > while /etc/init.d/better-daemon states > > # Provides: some-daemon > # X-If-Exists: /usr/sbin/better-daemon This is handled by virtual facilities (/etc/insserv.conf), like: $named +named +dnsmasq +lwresd +bind9 +unbound $network -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#590892: not honored on shutdown, sindsigs not interactive
control: tags -1 +moreinfo [2011-08-17 20:57] Adi Kriegisch > That is why I think it is futile to register the pid of 'umount -a -t > ocfs2' within an omit file. And that is why I still (at least partly) think > that there should be some kind of 'X-Exclusive' for system shutdown in > insserv: because sendsigs might kill commands executed by other init > scripts that might run a little longer for some reaon. I thing we already have everything needed. Essentially, insserv impements topological sorting, both on start sequence and stop sequence. On start, if "foo" has "Should-Start: bar", it means that "foo" will be started /after/ "bar". On start, if "foo" has "X-Start-Before: bar", it means that "foo" will be started /before/ "bar". On stop, if "foo" has "Should-Stop: bar", then "foo" is stopped /before/ "bar". On stop, if "foo" has "X-Stop-After: bar", then "foo" is stoppend /after/ "bar" So, any init script can specify arbitrary relations (before, after, irrelevant) with any other script. So, to make sure that your script is never executed parallel to some other, you have to use one of first two relations and one of last two. On other hand, we already have X-Interactive, which, strictly speaking, is not in basis (it can be expressed in terms of Should-Start and X-Start-Before). Jess, how much complexity would it be to implement X-Exclusive (or reusing X-Interactive for stop sequence)? -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#738585: loop between system-udev-trigger systemd-sysctl
control: tags -1 +moreinfo [ Ferdinand Thommes ] > While testing the support for systemd in insserv 1.16.0-1, I tried to install > the package ddclient, that relies on a sysvinit script. The install was > interupterd by an error: > update-rc.d: warning: start and stop actions are no longer supported; falling > back to defaults > insserv: Loop detected during expanding system facilities in the insserv.conf > file(s): systemd-udev-trigger systemd-sysctl > update-rc.d: error: insserv rejected the script header > > A similar error is already filed under #695751 for insserv 1.14.0-5, which > has > no systemd support. [2014-04-07 13:04] Lachlan > just want to add that i got this error with insserv 1.16 > > downgrading to 1.14.0-5fixed the errors with initscripts Do you still have this problem with insserv=1.18 (unstable) and insserv=1.20 (experimental)? -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#931658: runit-init: Boot hangs with QEMU if openssh-server is installed
[ Added autopkgtest maintainers to thread ] [2019-07-09 15:11] Lorenz > Il giorno mar 9 lug 2019 alle ore 01:52 Colin Watson > ha scritto: > >Is this just another instance of problems with your virtual machine not > >having enough entropy (#912616 etc.)? > > It looks you are right, thanks for the tip! > > Dmitry, I can pass the test that include openssh-server with a command like > (see #912087 message 118) > > $ autopkgtest ./runit-init_2.1.2-32_all.deb ./runit_2.1.2-32_amd64.deb > ./runit \ > -- qemu --qemu-options='-object rng-random,filename=/dev/urandom,id=rng0 > -device virtio-rng-pci,rng=rng0' \ > ./debian-unstable.img Confirmed. Your solution works. Btw, I tried adding `haveged` and/or `rng-tools` to test build dependency, and it does not work. > This rely on the host having enough entropy and i'm not sure how to pass > those options to salsa CI Is it possible to run Qemu on Salsa at all? As my experiments show¹, it is possible to create image with `autopkgtest-qemu-build' with Salsa CI. It still complains somewhat: ERROR: [Errno 2] No such file or directory: '/proc/mounts' ERROR: [Errno 2] No such file or directory: '/proc/mounts' ERROR: Command failed: kpartx -dsv ../autopkgtest.img.raw b'' b'/proc/devices: fopen failed: No such file or directory\nFailed to set up list of device-mapper major numbers\nIncompatible libdevmapper 1.02.155 (2018-12-18) and kernel driver (unknown version).\ndevice mapper prerequisites not met\n' But actually running `autopkgtest` fails with following error: qemu-system-x86_64: terminating on signal 15 from pid 27862 () : failure: timed out on client shared directory setup The only reference to such failure I found was #916428 (autopkgtest-qemu worked with python-3.6, but not 3.7). Bug closed in autopkgtest=5.8; current version is 5.10. Just running /usr/bin/kvm fails, complaining about missing "kvm" module³. Running with just software emulation is terribly slow. As I see it, the best we can do is script creation of image and invoking autopkgtest(1) with apporiate options and run this script from time to time manually. Or I missed something better? ¹ https://salsa.debian.org/debian/runit/-/jobs/219656 ² https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916428 ³ https://salsa.debian.org/kaction/push-limits/-/jobs/219676 -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#922815: insserv FATAL while updating as mountkernfs has to be enabled to use service udev
control: tags -1 +moreinfo control: user kact...@debian.org control: usertags -1 +objections [2019-03-07 14:45] Dmitry Bogatov > [2019-03-05 23:41] Michael Biebl > > Control: reassign -1 insserv > > > I think insserv should depend on initscripts. It requires that to > > > actually do anything. > > > > > > Adding Conflicts will likely make switching inits much more difficult. > > > > Nod, reassigning back to insserv. > > Bug is in incorrect usage of insserv, not within insserv. You may want to > add check, that /etc/init.d/mountkernfs.sh exists. > > If it will help you, I can add 'Recommends' (not Depends) on > bin:initscripts into insserv. > > If if you disagree, please close + wontfix this bug. On second thought, maybe it is okay to add dependency of insserv on initscripts? After all, we already have initscripts installed, and systemd users are unlikely to complain about bloat... Opinions? -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#931814: RFS: daggy/1.1.2-1 [ITP]
[2019-07-10 22:17] Михаил Миловидов > > part 2 text/plain1010 > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "daggy": > > * Package name : daggy > Version : 1.1.2-1 > Upstream Author : Mikhail Milovidov milovidovmikh...@gmail.com > * URL : https://daggy.dev > * License : Expat > Section : net > > It builds those binary packages: > > daggy - run multiple commands on remote servers and save output locally How does it compare with heap of ssh multiplexers already in Archive? For example, $ apt-cache search ssh multiplex [... filtered a bit ...] sslh - Applicative protocol multiplexer taktuk - efficient, large scale, parallel remote execution of commands -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#931977: startpar: uninitialized variable
Package: startpar
Version: 0.61-1
Severity: normal
X-Debbugs-Cc: Jesse Smith
Dear Maintainer,
GCC complains about uninialized variable
proc.c: In function ‘detect_consoles’:
proc.c:180:16: warning: ‘tail’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
tail->tty = name;
and it seems it is right:
struct console *restrict tail;
[...]
if (posix_memalign((void*), sizeof(void*), alignof(typeof(struct
console))) != 0)
perror("memory allocation");
tail->next = (struct console*)0;
tail->tty = name;
According to posix_memalign(3), if posix_memalign functions fails, it
does not alter first argument "tail", which is not initialized otherwise, and
dereference "tail" anyway: perror() just prints error, it does not
affect control flow.
Also, second argument is "sizeof(void*)" which is no bigger then 8,
while malloc(3) guarantees alignment of 8.
So, this quite complicated-looking call to posix_memalign(3) can be
simplified to:
tail = malloc(sizeof(*tail));
if (!tail) {
panic_and_run_in_circles();
}
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
pgpO2UVMKxwWK.pgp
Description: PGP signature
Bug#540866: insserv might not remove all
[2009-08-11 00:18] Ralph Ulrich
> Am 10.08.2009 20:55, schrieb Petter Reinholdtsen:
> > Hm. I am trying to reproduce this in a test case, but am unable to
> > replicate your problem. This is the test case I wrote. Any idea
> > where I fail to understand the problem you are experiencing?
> >
> > test_override_remove() {
> > ...
>
> Excuse me, I do not understand your functions. Therefore I have made
> this script insservtest:
> [...]
Jesse, can you please take a look at this bug?
This bug seems to provide quite detailed information: what was done,
what happend, what was expected and script to reproduce.
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Bug#931976: startpar: does testsuite of startpar actually test anything?
Package: startpar Version: 0.61-1 Severity: normal X-Debbugs-Cc: Jesse Smith Hi! I just noticed that we have wrong value of STARTPAR in our autopkgtests: debian/tests/testuite: #!/bin/sh set -e # Run test suite using the installed startpar binary make -C testsuite STARTPAR=/lib/startpar/startpar check And still, all Gitlab CI is happy. Actually, even during build log is suspicious: $ make check make STARTPAR=/home/iu/devel/salsa/debian/startpar/startpar -C testsuite check make[1]: Entering directory '/home/iu/devel/salsa/debian/startpar/testsuite' STARTPAR=/home/iu/devel/salsa/debian/startpar/startpar ./runtests error: the test init.d was not running success: the ls command was running make[1]: Leaving directory '/home/iu/devel/salsa/debian/startpar/testsuite' It is quite confusing, that is says both "error" and "success". Also, following snippet is suspitious: cat > etc/init.d/test < pgpRsq8HJt_IH.pgp Description: PGP signature
Bug#931576: RFS: blackbox-themes/0.6
[2019-07-07 22:38] Juhani Numminen > Alternatively, one can download the package with dget using this command: > dget -x > https://mentors.debian.net/debian/pool/main/b/blackbox-themes/blackbox-themes_0.6.dsc 404. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#931658: runit-init: Boot hangs with QEMU if openssh-server is installed
[2019-07-09 00:51] Colin Watson > On Tue, Jul 09, 2019 at 12:20:50AM +0200, Lorenzo Puliti wrote: > > Dear runit and openssh maintainers, > > > > when rebooting a QEMU image (debian Sid, from autopkgtest) with runit-init, > > if ssh server > > is installed and enabled, the system hangs at boot because the ssh server > > is stuck and unresponsive > > (see bug 930758 message 50). > > Also, I suspect that the same problem can happen with Virtualbox (see > > 838480 message 49). > > I'm not sure if this is a bug with runit or openssh-server and it's not > > easy for me to > > understand what triggers this bug; for example in my system i have ssh > > server > > and runit as init and all is working as expected.. > > Is this just another instance of problems with your virtual machine not > having enough entropy (#912616 etc.)? You might well not see the same > thing on bare metal due to a hardware RNG. Thank you for suggestion. I found interesting [^1] article on how to create (fake?) more entropy, but did not checked whether it helps in our case yet. [^1] http://giovannitorres.me/increasing-entropy-on-virtual-machines.html -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#931593: gdbm-l10n should not be Important
control: tags -1 confirmed help [2019-07-07 18:36] Mike Bird > part text/plain 503 > Package: gdbm-l10n > Version: 1.18.1-4 > Severity: normal > > I suspect the "Priority: important" for gdbm-l10n/buster is a mistake. Definitely. Funny thing is that I have no idea where does it come from, the only priority declaration I have in source package is Priority: optional in first paragraph. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#930487: lintian: speed up test suite CI
@Felix I think, that your proposal of caching test binary package separately from test output would be improvement. Maybe it would even be "good enough". I will take a look (no promises made) into this direction. But ideally... [2019-07-04 18:00] "Chris Lamb" > I think the most common use-case is that I make some change — possibly > extremely minor — in, say, checks/foo.pm and I want to re-run the > testsuite to check that I've fixed whatever false-positive or edge-case > in a tag that I am in the process of implementing. We should optimise > for kind of pattern. What do you think? Ideally, I want test suite automatically detect: * new test directory created, test.deb needs to be built * test directory edited, test.deb needs to be rebuilt * this configuration was already checked, nothing to do + I do not want re-run perl-critic and perltidy checks aganist files, that were not changed + ... In short, I want test suite to be dependable build system from source files and test files into tarball of test logs. (~950 files or so) Right now it feels like build system written in Make -- undercontrained in one cases (you can easily get stalled results), overconstrained in another cases (you build more then necessary -- perlcritic tests, for example). To get feeling what is perfect (in sense of dependencies correctness) build system, take a look at `tup'[1]. Read the tutorial, it is worthy reading. Unfortunately for our case, `tup' only supports static dependencies and outputs (applicative), so you can't do following with it: * foo.txt contains list of files * foo.tar contains files, listed in foo.txt * foo.tar perfectly depends on foo.txt and files, listed in it. That is why I talk about Shake -- it is more complicated, compared to tup, but it supports dynamic (monadic) rules, so previous example with `foo.tar' is basic example of Shake. In theory, it is possible to implement all features I mentioned with ad-hoc Perl code, but I wouldn't volonteer to do so. @Felix: As to question of maturity, Shake is Haskell library, implemented and maintainer by well-known and well-esteemed developer. I do not expect it disappear anytime soon. Of course, I do not plan (or propose) to re-implement `dpkg-buildpackage', I just want it to be called when and only when it is necessary. [1] http://gittup.org/tup -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#931426: lintian: check that runscript directory has "run" script
Package: lintian Version: 2.15.0 Severity: wishlist Dear Maintainer, please add check, that if package provides runscript directory (/etc/sv/), then /etc/sv//run is present and executable. Usually this is handled by dh-runit, but recently I discovered bug in dh-runit, that under some circumstances creates /etc/sv///run instead. It would be nice to add additional safety check via Lintian. -- System Information: Debian Release: 10.0 APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-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) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.31.1-16 ii bzip2 1.0.6-9.1 ii diffstat 1.62-1 ii dpkg 1.19.7 ii dpkg-dev 1.19.7 ii file 1:5.35-4 ii gettext0.19.8.1-9 ii gpg2.2.13-2 ii intltool-debian0.35.0+20060710.5 ii libapt-pkg-perl0.1.36+b1 ii libarchive-zip-perl1.64-1 ii libcapture-tiny-perl 0.48-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.7 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 ii libpath-tiny-perl 0.108-1 pn libtext-levenshtein-perl pn libtimedate-perl ii libtry-tiny-perl 0.30-1 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-2 ii patchutils 0.3.4-2 ii perl 5.28.1-6 ii t1utils1.41-3 ii xz-utils 5.2.4-1 Versions of packages lintian recommends: pn libperlio-gzip-perl Versions of packages lintian suggests: pn binutils-multiarch ii libhtml-parser-perl3.72-3+b3 ii libtext-template-perl 1.55-1 -- no debconf information pgpUwXW1mLvex.pgp Description: PGP signature
Bug#930758: runit: Add a test for switching init (systemd-->runit)
[2019-07-03 02:36] Lorenz > Dmitry, > sorry it took so long to send the patches, No need to be sorry :) You are doing awesome job at tasks I do not dare to tackle. > but while updating the test i run into several issues i'm not able to > solve by myself: > * I try to include openssh into the test but it makes the test fail because > ssh get stuck >at boot (same issue as reported by Martin Pitt in #838480 message #49) I confirm addition of `openssh-server' into test dependency indeed makes it hang (my log is at bottom). I will take a look and try to reproduce bug interactively (over VNC). > * then i try a Vbox VM and i failed to reproduce the ssh issue, but i run > into several other issues, see #931356 Can't we just conflict with libnss-systemd? > Althought the test as it is now in the patches pass, we should deal > with the above issues as they are likely hitting users that attempt > the switch Not sure about libnss, but I agree -- ssh server is extremely important. Can you please file separate bug about hang boot? autopkgtest [01:18:34]: version 5.10 autopkgtest [01:18:34]: host neophite.local; command line: /usr/bin/autopkgtest ../runit-init_2.1.2-32_all.deb ../runit_2.1.2-32_amd64.deb ../getty-run_2.1.2-32_all.deb ../runit_2.1.2-32_amd64.deb . -- qemu ../autopkgtest.img qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] autopkgtest [01:18:52]: testbed dpkg architecture: amd64 autopkgtest [01:18:55]: testbed running kernel: Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) autopkgtest [01:18:56]: built-tree . autopkgtest [01:18:56]: testing package runit version 2.1.2-32 autopkgtest [01:18:56]: test init-switch: preparing testbed Get:1 file:/tmp/autopkgtest.zHJCWY/binaries InRelease Ign:1 file:/tmp/autopkgtest.zHJCWY/binaries InRelease Get:2 file:/tmp/autopkgtest.zHJCWY/binaries Release [816 B] Get:2 file:/tmp/autopkgtest.zHJCWY/binaries Release [816 B] Get:3 file:/tmp/autopkgtest.zHJCWY/binaries Release.gpg Ign:3 file:/tmp/autopkgtest.zHJCWY/binaries Release.gpg Get:4 file:/tmp/autopkgtest.zHJCWY/binaries Packages [3921 B] Reading package lists... Reading package lists... Building dependency tree... Reading state information... Correcting dependencies...Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done Done Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done The following additional packages will be installed: libedit2 libgssapi-krb5-2 libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 libwrap0 openssh-client openssh-server openssh-sftp-server runit runit-helper sysuser-helper Suggested packages: krb5-doc krb5-user keychain libpam-ssh monkeysphere ssh-askpass molly-guard rssh ufw Recommended packages: krb5-locales xauth ncurses-term runit-sysv | runit-init | runit-systemd The following NEW packages will be installed: libedit2 libgssapi-krb5-2 libk5crypto3 libkeyutils1 libkrb5-3 libkrb5support0 libwrap0 openssh-client openssh-server openssh-sftp-server runit runit-helper sysuser-helper 0 upgraded, 13 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 2070 kB/2194 kB of archives. After this operation, 8259 kB of additional disk space will be used. Get:1 file:/tmp/autopkgtest.zHJCWY/binaries runit 2.1.2-32 [124 kB] Get:2 http://deb.debian.org/debian unstable/main amd64 runit-helper all 2.8.6 [4900 B] Get:3 http://deb.debian.org/debian unstable/main amd64 sysuser-helper all 1.3.3 [3844 B] Get:4 http://deb.debian.org/debian unstable/main amd64 libedit2 amd64 3.1-20181209-1 [94.0 kB] Get:5 http://deb.debian.org/debian unstable/main amd64 libkeyutils1 amd64 1.6-6 [15.0 kB] Get:6 http://deb.debian.org/debian unstable/main amd64 libkrb5support0 amd64 1.17-3 [65.6 kB] Get:7 http://deb.debian.org/debian unstable/main amd64 libk5crypto3 amd64 1.17-3 [121 kB] Get:8 http://deb.debian.org/debian unstable/main amd64 libkrb5-3 amd64 1.17-3 [370 kB] Get:9 http://deb.debian.org/debian unstable/main amd64 libgssapi-krb5-2 amd64 1.17-3 [158 kB] Get:10 http://deb.debian.org/debian unstable/main amd64 openssh-client amd64 1:7.9p1-10 [782 kB] Get:11 http://deb.debian.org/debian unstable/main amd64 openssh-sftp-server amd64 1:7.9p1-10 [44.6 kB] Get:12 http://deb.debian.org/debian unstable/main amd64 libwrap0 amd64 7.6.q-28 [58.7 kB] Get:13 http://deb.debian.org/debian unstable/main amd64 openssh-server amd64 1:7.9p1-10 [352 kB] Preconfiguring packages ... Fetched 2070 kB in 0s (21.3 MB/s) Selecting previously unselected package runit-helper. (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55%
Bug#930487: lintian: speed up test suite CI
[2019-06-13 21:29] "Chris Lamb" > Gitlab has a support for saving various parts of a successful build > for the next one. I believe the idea is that we would build the test > packages and then push them to this cache re-using them on any subsequent > test runs. People often use this to cache "pip" Python dependencies > but I don't see any obvious reason why we can't use it here. What is Lintian policy on usage of languages other then Perl? It feels that build system for test suite is overconstrained now (rebuilds more then necessary), and I consider to make some experiments with Shake[1]. Should the experiments succeed, will they be accepted? [1] https://shakebuild.com -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#930758: runit: Add a test for switching init (systemd-->runit)
control: tags -1 +pending [2019-07-03 01:27] Lorenzo Puliti > Package: runit > Version: 2.1.2-31 > Followup-For: Bug #930758 > > Hi, > it looks like init-system-helpers 1.57 breaks the test (it removes runit-init > from > the list of supported init). > Anyway the following patches should work Wonderful. Yes, it works. I slightly reformatted code and merged. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#931427: RFP: diff-so-fancy - make your diffs human readable
Package: wnpp Severity: wishlist Name: diff-so-fancy URL: https://github.com/so-fancy/diff-so-fancy Language: Perl Description: diff-so-fancy strives to make your diffs human readable instead of machine readable. This helps improve code quality and helps you spot defects faster. The difference between stock git diff hightlighting and diff-so-fancy is best shown by screenshot on project website. pgpFEAXVoeQmF.pgp Description: PGP signature
Bug#931425: dh-runit: creates /etc/sv/foo/foo
Package: dh-runit Version: 2.8.12 Severity: important Dear Maintainer, following content of .runit file (took from djbdns package) debian/service/djbdns disable,logscript where debian/service/djbdns is directory causes creation of malformed runscript: /etc/sv/dnscache/dnscache/run /etc/sv/dnscache/dnscache/... Interestingly, 2.8.8 seems to work fine. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients. pgpa7q1BEiMDS.pgp Description: PGP signature
Bug#930758: runit: Add a test for switching init (systemd-->runit)
[2019-06-22 19:53] Lorenz > As for other observations you made, i will have a look and send new patches > soon In mean time I managed to create qemu image with `autopkgtest-qemu-build`. On my machine test fails with error about removing "init". Any ideas how to fix it (apart to manually tweaking image)? autopkgtest [19:57:58]: version 5.10 autopkgtest [19:57:58]: host neophite.local; command line: /usr/bin/autopkgtest ../runit-init_2.1.2-32_all.deb ../runit_2.1.2-32_amd64.deb ../getty-run_2.1.2-32_all.deb . -- qemu ../autopkgtest.img qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] autopkgtest [19:58:16]: testbed dpkg architecture: amd64 autopkgtest [19:58:19]: testbed running kernel: Linux 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) autopkgtest [19:58:19]: built-tree . autopkgtest [19:58:19]: testing package runit version 2.1.2-32 autopkgtest [19:58:19]: test init-switch: preparing testbed Get:1 file:/tmp/autopkgtest.kRENL9/binaries InRelease Ign:1 file:/tmp/autopkgtest.kRENL9/binaries InRelease Get:2 file:/tmp/autopkgtest.kRENL9/binaries Release [816 B] Get:2 file:/tmp/autopkgtest.kRENL9/binaries Release [816 B] Get:3 file:/tmp/autopkgtest.kRENL9/binaries Release.gpg Ign:3 file:/tmp/autopkgtest.kRENL9/binaries Release.gpg Get:4 file:/tmp/autopkgtest.kRENL9/binaries Packages [3921 B] Reading package lists... Reading package lists... Building dependency tree... Reading state information... Correcting dependencies...Starting pkgProblemResolver with broken count: 2 Starting 2 pkgProblemResolver with broken count: 2 Investigating (0) init:amd64 < 1.57 @ii mK Ib > Broken init:amd64 PreDepends on systemd-sysv:amd64 < 241-5 @ii mR > Considering systemd-sysv:amd64 3 as a solution to init:amd64 5103 Added systemd-sysv:amd64 to the remove list Broken init:amd64 PreDepends on sysvinit-core:amd64 < none | 2.93-8 @un uH > Considering sysvinit-core:amd64 0 as a solution to init:amd64 5103 Try Installing sysvinit-core:amd64 < none | 2.93-8 @un uH > before changing init:amd64 Fixing init:amd64 via keep of systemd-sysv:amd64 Investigating (0) systemd-sysv:amd64 < 241-5 @ii mK Ib > Broken systemd-sysv:amd64 Conflicts on sysvinit-core:amd64 < none -> 2.93-8 @un uN Ib > Considering sysvinit-core:amd64 0 as a solution to systemd-sysv:amd64 3 Added sysvinit-core:amd64 to the remove list Fixing systemd-sysv:amd64 via keep of sysvinit-core:amd64 Investigating (0) runit-init:amd64 < none -> 2.1.2-32 @un uN Ib > Broken runit-init:amd64 Conflicts on systemd-sysv:amd64 < 241-5 @ii mK > Considering systemd-sysv:amd64 3 as a solution to runit-init:amd64 2 Holding Back runit-init:amd64 rather than change systemd-sysv:amd64 Investigating (0) autopkgtest-satdep:amd64 < 0 @iU mK Nb Ib > Broken autopkgtest-satdep:amd64 Depends on runit-init:amd64 < none | 2.1.2-32 @un uH > Considering runit-init:amd64 2 as a solution to autopkgtest-satdep:amd64 -2 Removing autopkgtest-satdep:amd64 rather than change runit-init:amd64 Done Done Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done The following additional packages will be installed: psmisc The following packages will be REMOVED: autopkgtest-satdep The following NEW packages will be installed: psmisc 0 upgraded, 1 newly installed, 1 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 126 kB of archives. After this operation, 652 kB of additional disk space will be used. Get:1 http://deb.debian.org/debian unstable/main amd64 psmisc amd64 23.2-1 [126 kB] Fetched 126 kB in 0s (0 B/s) (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 18668 files and directories currently installed.) Removing autopkgtest-satdep (0) ... Selecting previously unselected package psmisc. (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 18668 files and directories currently installed.) Preparing to unpack
Bug#930856: autopkgtest-build-qemu: captures something from host
control: close -1 [2019-06-30 10:13] Bastian Blank > > part text/plain 687 > On Sat, Jun 29, 2019 at 04:44:32PM +0200, Bastian Blank wrote: > > On Sat, Jun 29, 2019 at 02:25:55PM +, Dmitry Bogatov wrote: > > > Note that APT tries to use Devuan keyring to validate Debian release and > > > fail. How does `debootstrap' decides, which keyring to use? > > "dpkg -s debootstrap"? How did that keyring get on the system in the > > first place? > > Devuan includes a patched version of debootstrap. See > https://pkginfo.devuan.org/stage/ascii/ascii/debootstrap_1.0.89+devuan2.1.html That was the cause. My mistake, I forgot to check version of debootstrap. Sorry for noise. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#930856: autopkgtest-build-qemu: captures something from host
[ After futher investigation, this command fails with same error directly, without autopkgtest, so reassigning ] control: reassing -1 debootstrap control: retitle -1 debootstrap uses wrong keyring Dear maintainer of debootstrap, I can't create chroot due following error: # debootstrap --variant - unstable /tmp/foo.dir http://deb.debian.org I: Checking Release signature E: Release signed by unknown key (key id 04EE7237B7D453EC) The specified keyring /usr/share/keyrings/devuan-archive-keyring.gpg may be incorrect or out of date. You can find the latest Debian release key at https://ftp-master.debian.org/keys.html Note that APT tries to use Devuan keyring to validate Debian release and fail. How does `debootstrap' decides, which keyring to use? I am aware about --keyring option, original bug was about `autopkgtest-build-qemu', which invokes debootstrap through several layers and does not allow passing additional arguments to `debootstrap'. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#931257: dh-runit: overly lax dependency on runit-helper
Package: dh-runit Version: 2.8.11 Severity: wishlist Dear Maintainer, dh-runit=2.8.8 introduced new option: "since", but this option actually work (symlinks correctly created in /etc/runit/runsvdir/default) only with matching version of "runit-helper", but it is not enforced: runit:Depends contains much weaker dependency on runit-helper >= 2.8.1~ -- System Information: Debian Release: 10.0 APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-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) LSM: AppArmor: enabled Versions of packages dh-runit depends on: ii debhelper12.1.1 ii libfile-copy-recursive-perl 0.44-1 ii libfile-slurp-perl .27-1 ii libtext-hogan-perl 2.01-1 dh-runit recommends no packages. dh-runit suggests no packages. -- no debconf information pgpVYRIxt3WzQ.pgp Description: PGP signature
Bug#930700: Re: Bug#930700: Re: Bug#930700: lintian: support "suppress-tags-from-file" in configuration file
[2019-06-24 13:53] "Chris Lamb" > > Some of tags have too much false-positive rate, and some of them are not > > worth spending time. Here is incomplete list: > > Neat. So, I think there are three categories here. Well, I would divide only into two categories: "don't care" and "false-positive". Most (all?) "don't care" tags are pedantic, but not all pedantic are "don't care". For example, currently "debian-watch-does-not-check-gpg-signature" is pedantic, but I consider it error, unless it is false-positive. I'd prefer opt-out approach to opt-in, to not miss something useful. This bug is about making it simplier. > Lastly, there are ones with too many false-positives. These seem the > easy ones to address actually -- if you have a concrete example of > false-positives, please file away. Just filed. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#931113: cflow: wierd Info node with emacs
Package: cflow Version: 1:1.6-1 Severity: normal Dear Maintainer, under Emacs Info reader (C-h i) I have two cflow-related nodes: one under Programming section, which works fine Programming * AutoGen: (autogen). The Automated Program Generator * cflow: (cflow). Create a graph of control flow within a program. and one under Emacs section: Emacs [...] * IDN Library: (libidn)Emacs API. Emacs API for IDN functions. * cflow mode: (cflow)cflow mode. Major mode for visiting cflow charts. ^^^ Underlined symbols are marked as link, but attempt to follow link (place a point and press ) results in "No such node or archor: cflow mode" error in minibuffer. Emacs version is 1:26.1+1-3.2 -- System Information: Debian Release: 10.0 APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-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) LSM: AppArmor: enabled Versions of packages cflow depends on: ii libc6 2.28-10 cflow recommends no packages. cflow suggests no packages. -- no debconf information pgp3A7j4GbtJQ.pgp Description: PGP signature
Bug#931112: lintian: false-positives of harndening-no-fortify-functions
Package: lintian Version: 2.15.0 Severity: wishlist Dear Maintainer, "hardening-no-fortify-functions" has extermely high false-positive rate. From reading of its description, I can see two groups of packages. First group of false-positives consists of packages that use little or none of standard library /directly/: - bcron - ftpcopy - runit - djbdns - ... You can check, these packages use CFLAGS/CPPFLAGS/LDFLAGS, provided by dpkg-buildflags via /usr/share/dpkg/default.mk (While I was writing this bug, I notices that in "runit" package I forgot LDFLAGS, but fix to include them changes nothing.) Secondly, even "gdbm" library (but not binary), which is conventional user of libc as whole and stdio in particular, triggers this tag. I believe, blhc(1) does everything this tag was supposed to do. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients. pgpcnPVyNHP32.pgp Description: PGP signature
Bug#930758: runit: Add a test for switching init (systemd-->runit)
[2019-06-22 19:53] Lorenz > Hi, Hi! > > Why are these 'service' calls? Do 'service' support runit already? > > No, not yet. I'm using 'service' script to test if those services, started > as sysv scripts, > are up. According to my testing, rsyslog, cron, udev and dbus are > installed and running in > the systemd testbed, so it make sense to me to test if they are running > after the switch. Ah, understood. Maybe it worth adding them into dependies of test to not rely on undocumented content of image, generated by of autopkgtest-build-qemu? > Anyway, i'm not sure what to test to decide if the init switch is > successful, ideas are welcome. Probably, check that halt/reboot works? Not sure how to test halt, but one more reboot does not seems to add much of complexity, and may be useful to reveal services, that does not shutdown cleanly. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#923871: [Pkg-acpi-devel] Bug#923871: acpid: please provide runscript file
[2019-06-21 20:02] Michael Meskes > On Fri, 2019-06-21 at 10:17 +0000, Dmitry Bogatov wrote: > > [ You replied in private, I took liberty to put BTS back into CC ] > > And what or who gave you the right to put my private comments into the > public BTS? At the very least this is very rude, especially given that > you did it on purpose. I apologize. I thought it wasn't deliberate decision to drop BTS. Sometimes I forget to put bug into thread, and it causes troubles, but I have never had problems with my Debian-related messages being public -- they all are intended to. Sure, I should have erred on side of your privacy. Sorry. -- Note, that I send and fetch email in batch, once in a few days. Please, mention in body of your reply when you add or remove recepients.
Bug#930934: gdb-doc: contradiction in manual about numeric argument
Package: gdb-doc Version: 8.2.1-1 Severity: wishlist Tags: upstream Dear Maintainer, In section 2.1 of manual there is following text: You can, instead, specify a process ID as a second argument, if you want to debug a running process: gdb PROGRAM 1234 would attach GDB to process '1234' (unless you also have a file named '1234'; GDB does check for a core file first). while in section 2.1.1 there is following text: If the second argument begins with a decimal digit, GDB will first attempt to attach to it as a process, and if that fails, attempt to open it as a corefile. If you have a corefile whose name begins with a digit, you can prevent GDB from treating it as a pid by prefixing it with './', e.g. './12345'. They contradict about what will happen with invocation gdb ./prog 1234 when file ./1234 exists. As far as I can tell, actual behaviour favours processes identifier to filename (behaviour suggested by section 2.1.1). -- System Information: Debian Release: 10.0 APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-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) LSM: AppArmor: enabled -- no debconf information pgpGspRzSJ4ev.pgp Description: PGP signature
Bug#930758: runit: Add a test for switching init (systemd-->runit)
[2019-06-20 02:07] Lorenzo Puliti > Hi, Hi! > while experimenting with autopkgtest i manage to write a small test > that, starting from a systemd qemu machine, installs runit-init and reboot > into > it, checking if there is a working getty to login with and if essential > services (syslog, udev ..) are up. > While the test is very simple it could be useful to have something like > this around to make sure that the compat layer in /run/initctl will not > get broken (by systemd) and that some future development in stage1/2 will not > break the runit-init boot. > I have tested it on my pc, the last attach is the output of the test Sounds good, let's see. > Subject: [PATCH 1/3] Provide a service for a getty on serial tty > > diff --git a/debian/getty-ttyS0/run b/debian/getty-ttyS0/run > new file mode 100755 > index 000..31dccf6 > --- /dev/null > +++ b/debian/getty-ttyS0/run > @@ -0,0 +1,8 @@ > +#!/bin/sh > +NAME=getty-ttyS0 > +if pgrep -x agetty -t ttyS0; then > +sv d getty-ttyS0 > +echo "already another getty on ttyS0" > +fi > +exec 2>&1 > +exec chpst -P fgetty /dev/ttyS0 As I understand it, you assume that fgetty is present. Currently, runit does not have hard dependency of 'fgetty'. Can this runscript be made to fallback on "getty" from util-linux? > >From 374b79ae1c811b668668f22f57e77a6d352670a4 Mon Sep 17 00:00:00 2001 > From: Lorenzo Puliti > Date: Mon, 17 Jun 2019 14:43:55 +0200 > Subject: [PATCH 2/3] Prepare source for autopkgtest > > Add a stanza in debian/control and a debian/tests directory > needed for autopkgtest > --- > debian/control | 1 + > debian/tests/control | 1 + > 2 files changed, 2 insertions(+) > create mode 100644 debian/tests/control > > diff --git a/debian/control b/debian/control > index 23300e5..0764231 100644 > --- a/debian/control > +++ b/debian/control > @@ -13,6 +13,7 @@ Build-Depends: bash-completion, > doc-base, > Vcs-Browser: https://salsa.debian.org/debian/runit > Vcs-Git: https://salsa.debian.org/debian/runit.git > +Testsuite: autopkgtest > > Package: runit > Architecture: any > diff --git a/debian/tests/control b/debian/tests/control > new file mode 100644 > index 000..8d1c8b6 > --- /dev/null > +++ b/debian/tests/control > @@ -0,0 +1 @@ Are you sure this is needed? I believe autopkgtest tests are run without "Testsuite" field in debian/control. In my "gdbm" package, they do. > Subject: [PATCH 3/3] add a test for switching to runit-init > > Add a smoke test for the switch systemd --> runit-init > --- > --- a/debian/tests/control > +++ b/debian/tests/control > @@ -1 +1,7 @@ > - > +Tests: init-switch > +Depends: runit, > + runit-init, > + getty-run, > + fgetty, > + psmisc, > +Restrictions: needs-root, isolation-machine, breaks-testbed I am positive that runit-init implies getty-run. Maybe this list could be shinked even futher? > diff --git a/debian/tests/init-switch b/debian/tests/init-switch > new file mode 100755 > index 000..1e09238 > --- /dev/null > +++ b/debian/tests/init-switch > @@ -0,0 +1,60 @@ > + #!/bin/sh > + set -e > + > + > + if [ -z "$AUTOPKGTEST_REBOOT_MARK" ]; then > +if [ -d /run/systemd/system ]; then > +init=systemd > +elif [ -e /run/initctl ]; then > +init=sysv > +else > +init=unknown-init > +fi > +echo "testbed is running with $init" > + > +if [ -e /tmp/autopkgtest-reboot ]; then > +echo "enabling the serial getty" > +ln -s /etc/sv/getty-ttyS0 /etc/service/ > +echo "Done" > +/tmp/autopkgtest-reboot-prepare runit > +echo "reboot" > +reboot > +else > +echo "testbed does not support reboot" > +echo "can't perform this test" > +exit 1 > +fi > + else > +echo "detecting runit-init" > +if [ -e /run/runit.stopit ]; then > +echo "OK" > +else > +echo "init is not runit" && exit 1 > +fi > +# searching for runsvdir is pointless, since autopkgtest use serial getty > +#to connect with the qemu-system, and getty-S0 starts only after > runsvdir.. > +#echo "detecting runsvdir" > +#if pidof runsvdir; then > +#echo "OK" > +#else > +#echo "stage 2 failed to start runsvdir" && exit 1 > +#fi Can we remove this commented code? > +echo "detecting gettys" > +if pidof fgetty; then > +echo "OK" > +else > +echo " no getty to perform login with " && exit 1 > +fi > +echo "Detecting active services.." > +sv status /etc/service/* > +service udev status > +service rsyslog status > +service cron status > +service dbus status Why are these 'service' calls? Do 'service' support runit already? > +# service --status-all # not usable since some services will exit > nonzero with [?] > +# we can test also ssh-server here if runit-init will recommend it Not going to happen. Many users install all recommends; pulling ssh server without user
Bug#930856: autopkgtest-build-qemu: captures something from host
Package: autopkgtest Version: 5.10 Severity: normal Dear Maintainer, I fail to create qemu image: (ins).. sudo autopkgtest-build-qemu unstable debian-unstable Load spec file /tmp/tmp.MVjau2ZRda Exec: ['qemu-img', 'create', '-f', 'raw', 'debian-unstable.raw', '20G'] Exec: ['parted', '-s', 'debian-unstable.raw', 'mklabel', 'msdos'] Exec: ['parted', '-m', 'debian-unstable.raw', 'print'] Exec: ['parted', '-s', 'debian-unstable.raw', 'mkpart', 'primary', 'ext2', '0%', '100%'] Exec: ['kpartx', '-asv', 'debian-unstable.raw'] remembering /dev/mapper/loop0p1 as root Exec: ['/sbin/mkfs', '-t', 'ext4', '/dev/mapper/loop0p1'] Exec: ['mount', '/dev/mapper/loop0p1', '/tmp/tmpybhuhyix'] Exec: ['debootstrap', '--variant', '-', 'unstable', '/tmp/tmpybhuhyix', 'http://deb.debian.org/debian'] ERROR: Command failed: debootstrap --variant - unstable /tmp/tmpybhuhyix http://deb.debian.org/debian b"W: Cannot check Release signature; keyring file not available /usr/share/keyrings/devuan-archive-keyring.gpg\nI : Retrieving InRelease \nI: Retrieving Packages \nI: Validating Packages \nI: Resolving dependencies of required packages...\nI: Resolving dependencies of base packages...\nI: Checking component main on http://deb.debian.org/d ebian...\nE: Couldn't find these debs: devuan-keyring devuan-baseconf\n" b'' Something went wrong, cleaning up! Exec: ['umount', '/tmp/tmpybhuhyix'] Exec: ['kpartx', '-dsv', 'debian-unstable.raw'] The host system actually uses Devuan repostiories and actually have "devuan-keyring" package installed (alongside with "debian-keyring"), but why debootstrap tries to validate Debian release with Devuan keyring and how could I override this? -- Note, that I send and fetch email in batch, once in a few days. pgplOCZ5xx8Dd.pgp Description: PGP signature
Bug#930700: Re: Bug#930700: lintian: support "suppress-tags-from-file" in configuration file
[2019-06-18 22:30] "Chris Lamb" > > part text/plain 414 > Chris Lamb wrote: > > > It seems reasonable that this option could be allowed so I am > > therefore retitling (etc.) this bug to match. > > On the other hand, I would be curious to know why you wish to suppress > *so* many tags. It sounds like there is a deeper, more fundamental, > issue at play here. Some of tags have too much false-positive rate, and some of them are not worth spending time. Here is incomplete list: - hardening-no-fortify-functions: terrible false-positive rate. Most packages I maintain/QA trigger this tag despite blhc(1) verifying that all recommended C/CPP/LD-FLAGS are included. Your mileage may vary, but for me, blhc(1) superseded this tag. - *systemd*: my personaly policy is to ship upstream service file verbatim (okay, ocassional s/bin/sbin), if any. These tags are pure noise. - *upstream-metadata*: I am not convinced of usefulness of this proposal. Most of fields in upstream metadata file can be inferred from d/control, d/changelog (dep5) and d/watch, but I would not volonteer scripting this. - missing-debian/watch: `gbp import-orig --uscan' is essential to my workflow, so I need no reminder. But for finished software, this tag is noise. Probably, there are more. -- Note, that I send and fetch email in batch, once in a few days.
Bug#930702: lintian: warn about /usr/bin -> /usr/sbin mismatch
[2019-06-18 22:41] "Chris Lamb" > > part text/plain 453 > Dmitry Bogatov wrote: > > > * upstream build system incorrectly installs binary into $(prefix)/bin > > * package maintainer moves it into $(prefix)/sbin > > * there still may be files around, that refer to previous location of > >binary > > Interesting idea. This sounds like you are speaking from experience; > can you cite an example? Sure. 1. Ceni --- Ceni is ncurses interface for /etc/network/interfaces. Upstream build system installs it into /usr/bin and provides .desktop file, that refers to program as /usr/bin. Since running this program requires root privileges, it actually belongs to /sbin. I had similar case with Laminar CI server and its systemd unit file. 2. djbdns - djbdns is collection of DNS-related servers. Upstream build system is quite unconventional (if we consider autotools as unit of conventionality) and does not make distinction between /bin and /sbin. For every of five servers, it also builds *-conf program, which refers to server binary as /usr/bin/. Probably there were more, but double-checking five servers of djbdns prompted for something automatic. -- Note, that I send and fetch email in batch, once in a few days.
Bug#921433: RFP: ipify-cli -- Get your public IP address
[2019-02-05 14:40] Pierre Rudloff
> Package: wnpp
> Severity: wishlist
>
> * Package name: ipify-cli
> Version : 1.0.0
> Upstream Author : Sindre Sorhus
> * URL : https://github.com/sindresorhus/ipify-cli
> * License : MIT
> Programming Lang: JS
> Description : Get your public IP address
>
> This is a CLI client for the ipify API written in NodeJS.
> It can be useful on newly configured servers to get the public IP of the
> server.
Why not just:
wget -O- -q http://checkip.dyndns.org:8245 | grep -Eo
'([0-9]{2,3}\.?){4}'
I mean, task at hand can be easily done with /essential/ tools.
--
Note, that I send and fetch email in batch, once in a few days.
Bug#867869: ITP: beautify-bash -- Beautifier for Bash shell scripts written in Python
[2017-07-10 02:42] Mike Mestnik
> Package: wnpp
> Severity: wishlist
> Owner: Mike Mestnik
>
> * License : GPL
> Programming Lang: Python
> Description : Beautifier for Bash shell scripts written in Python
>
> Second Bash script beautifier by Paul Lutus — the first is pretty
> well-known. This rewrite cleans up some annoying inconsistencies.
I read description of program, and its first sentence is "I decided to
not recreate Bash parser". Hey, that is idea!
If "foo" is bash function, then "type foo" outputs its body,
pretty-printed. So, here is complex example from upstream website:
_fn () {
for arg ; do
done=3; echo done; done
}
Here is output of "type _fn":
_fn is a function
_fn ()
{
for arg in "$@";
do
done=3;
echo done;
done
}
So, we can put script into body of function, and bash would pretty-print
it. Unfortunately, it eats comments. Hope this idea could be of use to
somebody.
--
Note, that I send and fetch email in batch, once in a few days.
Bug#864834: [ITP] libpoly -- a C library for manipulating polynomials
[2017-06-15 08:38] Ian A Mason > > part text/plain 53 > Package: wnpp > Severity: wishlist > Control: owner -1 ! Any meta-information? Homepage, description? In current form, RFP with only project title is quite useless. -- Note, that I send and fetch email in batch, once in a few days.
Bug#923871: [Pkg-acpi-devel] Bug#923871: acpid: please provide runscript file
[ You replied in private, I took liberty to put BTS back into CC ] [2019-06-17 11:03] Michael Meskes > Dmitry, > > > But, after all, we all volonteers here. So hereby I inform you, > > following advice in Developer reference, section 5.11, that I plan to > > do non-maintainer upload in two weeks or so. > > > > Upload will be into DELAYED/15, so you still have plenty of time > > to make comments and take action. > > Feel free to upload directly, or if you want, fully take over the > package. As it stands the package is essentially orphaned as I have > neither the time not the usage for it anymore. I was thinking of > officially orphaning it after the release. Thank you for your response. If you are positive on orphaning package, probably filing Orphan bug right now would simplify some things: my upload would additionally reassign maintenance to QA group. I think it is very important for orphaned packages have QA group as maintainer, otherwise it could scare away prospective new maintainer. -- Note, that I send and fetch email in batch, once in a few days.
Bug#867869: ITP: beautify-bash -- Beautifier for Bash shell scripts written in Python
[2017-07-10 02:42] Mike Mestnik
> Package: wnpp
> Severity: wishlist
> Owner: Mike Mestnik
>
> * License : GPL
> Programming Lang: Python
> Description : Beautifier for Bash shell scripts written in Python
>
> Second Bash script beautifier by Paul Lutus — the first is pretty
> well-known. This rewrite cleans up some annoying inconsistencies.
I read description of program, and its first sentence is "I decided to
not recreate Bash parser". Hey, that is idea!
If "foo" is bash function, then "type foo" outputs its body,
pretty-printed. So, here is complex example from upstream website:
_fn () {
for arg ; do
done=3; echo done; done
}
Here is output of "type _fn":
_fn is a function
_fn ()
{
for arg in "$@";
do
done=3;
echo done;
done
}
So, we can put script into body of function, and bash would pretty-print
it. Unfortunately, it eats comments. Hope this idea could be of use to
somebody.
--
Note, that I send and fetch email in batch, once in a few days.
Bug#930703: ITP: djbdns -- collection of DNS tools and servers
Package: wnpp Severity: wishlist Owner: Dmitry Bogatov * Package name : djbdns Version : 1:1.05-9~exp2 Upstream Author : D. J. Bernstein * Url : http://cr.yp.to/djbdns.html * Licenses : public-domain Programming Lang : C Section : net This package was present in Debian, but removed due unresolved security-related issue (see #516394) in 2017. Here I intend to apply apporiate patches and provide following binary packages: axfrdns === axfrdns reads a zone-transfer request in DNS-over-TCP format from its standard input, and responds with locally configured information. dnscache When a browser wants to contact www.debian.org, it first asks a DNS cache, such as dnscache, to find the IP address of www.debian.org. . Internet service providers run dnscache to find IP addresses requested by their customers. If you're running a home computer or a workstation, you can run your own dnscache to speed up your web browsing. tinydns === tinydns is general-purpose DNS server that accepts iterative DNS queries from hosts around the Internet, and responds with locally configured information. . This program is used by network administrators to publish the IP addresses of their computers; this package is unlikely to be useful for regular workstation. rbldns == rbldns is a special-purplose DNS server, that provides information about blacklisted IP addresses. This information is typically used by email software in effort to stop spam. . For more information about this technique, see RFC 6471. walldns === walldns accepts iterative DNS queries for in-addr.arpa domains from hosts around the Internet, and supplies generic responses that avoid revealing local host information. I plan to maintain this package myself, keeping debianization in following Git repository: https://salsa.debian.org/debian/djbdns.git -- Note, that I send and fetch email in batch, once in a few days.
Bug#925545: busybox: please provide runscript file
control: user ru...@packages.debian.org control: usertags -1 freeze [2019-06-16 00:20] Bastian Blank > Hi Dmitry Hi, Bastian > On Sat, Jun 15, 2019 at 06:37:03PM +, Dmitry Bogatov wrote: > > But, after all, we all volonteers here. So hereby I inform you, > > following advice in Developer reference, section 5.11, that I plan to > > do non-maintainer upload in two weeks or so. > > As we are before a release, NACK. Yes, we are. Upload to experimental would be nice, though. But if you prefer to wait for thaw, no problem -- I will come back after release. -- Note, that I send and fetch email in batch, once in a few days.
Bug#930702: lintian: warn about /usr/bin -> /usr/sbin mismatch
Package: lintian Version: 2.15.0 Severity: wishlist Dear Maintainer, please consider following situation: * upstream build system incorrectly installs binary into $(prefix)/bin * package maintainer moves it into $(prefix)/sbin [ or via-verse, although it is more rare ] * there still may be files around, that refer to previous location of binary, like: + supplementary scripts + .desktop files + init-system integration files + hardcoded path in other binaries (yes, it happens) So here is my proposal: for each binary /usr/bin/foo and /usr/sbin/bar, scan all files for "/usr/sbin/foo" and "/usr/bin/bar" and report any occurence for possible mismatch. I believe, that if we exclude /usr/share/doc/ from examination, false positive should not happen very often. Still, obliviously, this check is to be of "wild-guess" category. Opinions? pgp3t14ETRaFw.pgp Description: PGP signature
Bug#930700: lintian: failed to set "suppress-tags-from-file"
Package: lintian Version: 2.15.0 Severity: normal Dear Maintainer, Somewhy, I fail to get "suppress-tags-from-file" option work from ~/.config/lintian/lintain. I keep receiving following error: Unknown configuration variable suppress-tags-from-file at line: 1. when config file is very simple: suppress-tags-from-file = ~/.config/lintian/suppressed-tags.txt But, if I inline list of suppressed tags myself into config file: suppress-tags = tag1, tag2, tag3 Unfortunatuly, it hits any reasonable line length limit quickly. I failed to find any hints in lintian(1), why and/or whether "suppress-tags-from-file" is unsupported in config file, nor I found any way to make line continuation. pgpAySj022nHX.pgp Description: PGP signature
Bug#930701: lintian: unusual-interpreter /lib/runit/invoke-run
Package: lintian Version: 2.15.0 Severity: wishlist Dear Maintainer, Lintian complains on runscripts (/etc/sv/*/run) with following shebang: #!/usr/bin/env /lib/runit/invoke-run This is correct shebang. /lib/runit/invoke-run invokes script with /bin/sh, with some additional checks and environment variables, not unlike /lib/init/init-d-script. Please, add this path to list of "usual" interpreters. pgpONiDojuML6.pgp Description: PGP signature
Bug#930487: lintian: speed up test suite CI
[2019-06-13 21:29] "Chris Lamb" > Felix Lechner wrote: > > > For Lintian, however, I would prefer to upload the test packages > > separately to Debian's regular build infrastructure. > > Hm, I think you are talking at cross-purposes to Dmitry here. Nobody > was suggesting we upload the test packages to Debian; that would > surely be impossible. > > > Gitlab has a support for saving various parts of a successful build > for the next one. I believe the idea is that we would build the test > packages and then push them to this cache re-using them on any subsequent > test runs. People often use this to cache "pip" Python dependencies > but I don't see any obvious reason why we can't use it here. Thank you. That is exactly what I meant. -- Note, that I send and fetch email in batch, once in a few days.
Bug#923871: acpid: please provide runscript file
control: retitle -1 acpid: please provide runscript file -- second call Hello, dear maintainer. This bug, requesting addition of runscript file into package was filed some time ago, and got no response. It is quite unfortunate, since your review of could have provided valuable advice how to improve proposed patch. But, after all, we all volonteers here. So hereby I inform you, following advice in Developer reference, section 5.11, that I plan to do non-maintainer upload in two weeks or so. Upload will be into DELAYED/15, so you still have plenty of time to make comments and take action. Thank you for your work on Debian. Best regards.
Bug#925545: busybox: please provide runscript file
control: reassign -1 src:busybox control: retitle -1 busybox: please provide runscript file -- second call Hello, dear maintainer. This bug, requesting addition of runscript file into package was filed some time ago, and got no response. It is quite unfortunate, since your review of could have provided valuable advice how to improve proposed patch. But, after all, we all volonteers here. So hereby I inform you, following advice in Developer reference, section 5.11, that I plan to do non-maintainer upload in two weeks or so. Upload will be into DELAYED/15, so you still have plenty of time to make comments and take action. Thank you for your work on Debian. Best regards. -- Note, that I send and fetch email in batch, once in a few days.
Bug#919181: fixes to WIP package
[2019-06-10 14:48] Paolo Greppi > > part text/plain1720 > Hi, thanks for working on this ! > > I set out to try and reproduce 927254, using the laminar debs built from the > WIP package here: > https://salsa.debian.org/debian/laminar Thank you. I applied patches you provided and pushed them: url: https://salsa.debian.org/debian/laminar master: 9a4c514af61f68b219b2f2f05258a64cd5e8ddaf Also, I encourage you send patches, generated by "git format-patch" or "git send-email". This way I have less work tracking attribution. -- Note, that I send and fetch email in batch, once in a few days.
Bug#930487: lintian: speed up test suite CI
Package: lintian Version: 2.15.0 Severity: wishlist Dear Maintainer, Gitlab CI jobs take very long to complete: around 1.5 hours. No wonder -- test suite builds generates and builds more then 900 source packages, and after that it runs Lintian in those source packages. As can be seen here[1], build of source packages takes quite significant portion of total run time: around 33 minutes. It would be great to use Gitlab caching to avoid rebuiling package at every job run. [1] https://salsa.debian.org/kaction/lintian/-/jobs/195835 pgppI_V0mukwe.pgp Description: PGP signature
Bug#930424: cflow: provide html version of cflow.info
Source: cflow Severity: wishlist Dear Maintainer, please provide html version of cflow.info. Possibly, it worth also splitting documentation (and localization data, too) into separate binary packages. -- System Information: Debian Release: 10.0 APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-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) LSM: AppArmor: enabled pgpEQs7bXQB_1.pgp Description: PGP signature
Bug#930423: chromium: crash when HOME points to non-directory
Package: chromium Version: 74.0.3729.108-1 Severity: wishlist Dear Maintainer, $ HOME=/dev/null PATH=/bin:/usr/bin /usr/bin/chromium *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 10.0 APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-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) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common 74.0.3729.108-1 ii libasound2 1.1.8-1 ii libatk-bridge2.0-0 2.30.0-5 ii libatk1.0-0 2.30.0-2 ii libatomic1 8.3.0-7 ii libatspi2.0-02.32.0-1 ii libavcodec58 7:4.1.3-1 ii libavformat587:4.1.3-1 ii libavutil56 7:4.1.3-1 ii libc62.28-10 ii libcairo-gobject21.16.0-4 ii libcairo21.16.0-4 ii libcups2 2.2.10-6 ii libdbus-1-3 1.12.14-1 ii libdrm2 2.4.97-1 ii libevent-2.1-6 2.1.8-stable-4 ii libexpat12.2.6-1 ii libflac8 1.3.2-3 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3 ii libgcc1 1:8.3.0-7 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2 ii libgtk-3-0 3.24.5-1 ii libharfbuzz0b2.3.1-1 ii libicu63 63.1-6 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libjsoncpp1 1.7.4-3 ii liblcms2-2 2.9-3 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.21-1 ii libnss3 2:3.44+really3.42.1-2 ii libopenjp2-7 2.3.0-2 ii libopus0 1.3-1 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpci3 1:3.5.2-5 ii libpng16-16 1.6.36-6 ii libpulse012.2-4 ii libre2-5 20190101+dfsg-2+b1 ii libsnappy1v5 1.1.7-1 ii libstdc++6 8.3.0-7 ii libva2 2.4.0-1 ii libvpx5 1.7.0-3 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb1 1.13.1-2 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.15-2 ii libxdamage1 1:1.1.4-3+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxml2 2.9.4+dfsg1-7+b3 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.32-2 ii libxss1 1:1.2.3-1 ii libxtst6 2:1.2.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages chromium recommends: pn chromium-sandbox Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii x11-utils 7.7+4 ii xdg-utils 1.1.3-1 Versions of packages chromium-common recommends: pn chromium-sandbox ii fonts-liberation 1:1.07.4-9 ii libgl1-mesa-dri 18.3.6-2 pn libu2f-udev pn notification-daemon pn upower -- no debconf information pgpwYWC4dfvOs.pgp Description: PGP signature
Bug#928969: stterm: incorrect rendering of cyrillic letters with Terminus
[2019-06-06 12:19] Paride Legovini > [...] > I tried to reproduce by compiling st directly from the upstream source > tree and I am able to reproduce the issue (as expected, as there are > currently no patches in the Debian package). My conclusions are: > > - This is an actual bug in st, not a configuration issue; > - The comparison with urxvt makes it apparent; > - The bug belongs to upstream. > > Do you think you can follow-up to d...@suckless.org? What do you mean to "follow-up"? Add me into CC as required, I will reply, but I'd rather not subscribe to mailing list. Actually, I doubt I can be of any use now. Virtual machine image is more eloquent, then hundred words :) Thank you for your effort maintaining stterm. -- Note, that I send and fetch email in batch, once in a few days.
Bug#919181: status of ITP: laminar
control: block -1 by 927254 [2019-06-05 21:26] meskio > Hello Dimitry, > > I see you submitted this ITP for laminar in January. I was wondering > what is the status of it and if I can help with it. > > Thanks for starting the process. Hello. Essentially, I stalled on #927254 (in libjs-vue-router dependency). Since I am not capable of resolving it myself, I patiently wait for someone (presumably, from JS team) to fix it. Your help would be very valuable. Current debianization of laminar in https://salsa.debian.org/debian/laminar. Patches (no pull-requests, please) are welcome. -- Note, that I send and fetch email in batch, once in a few days.
Bug#930113: tor: please provide runscript file
Source: tor
Version: 0.4.0.5-1
Severity: wishlist
Tags: patch
User: ru...@packages.debian.org
Usertags: runscript
Dear maintainer,
please include native script for runit init system into 'tor'.
Below is diff aganist latest package release (0.4.0.5-1).
Here are some links:
* http://smarden.org/runit -- more information about 'runit'
* https://bugs.debian.org/746715 -- technical committe position
on support of init systems, other then sysvinit.
From d7ca30748d31efaf37dbd37e9cf8f1e7464ed84f Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Thu, 6 Jun 2019 10:00:28 +
Subject: [PATCH] Add integration for runit init
---
debian/control| 3 ++-
debian/rules | 1 +
debian/tor.install| 2 ++
debian/tor.runit | 1 +
debian/tor.runscript/conf/MAX_FILEDESCRIPTORS | 1 +
debian/tor.runscript/run | 23 +++
6 files changed, 30 insertions(+), 1 deletion(-)
create mode 100644 debian/tor.runit
create mode 100644 debian/tor.runscript/conf/MAX_FILEDESCRIPTORS
create mode 100644 debian/tor.runscript/run
diff --git a/debian/control b/debian/control
index 74ba641..e240b05 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: tor
Section: net
Priority: optional
Maintainer: Peter Palfrader
-Build-Depends: debhelper (>= 9.20160114), quilt, libssl-dev, zlib1g-dev,
libevent-dev (>= 1.1), asciidoc (>= 8.2), docbook-xml, docbook-xsl, xmlto,
dh-apparmor, libseccomp-dev [amd64 i386], dh-systemd [linux-any],
libsystemd-dev [linux-any], pkg-config [linux-any], libcap-dev [linux-any],
dh-autoreconf, liblzma-dev, libzstd-dev
+Build-Depends: debhelper (>= 9.20160114), quilt, libssl-dev, zlib1g-dev,
libevent-dev (>= 1.1), asciidoc (>= 8.2), docbook-xml, docbook-xsl, xmlto,
dh-apparmor, libseccomp-dev [amd64 i386], dh-systemd [linux-any],
libsystemd-dev [linux-any], pkg-config [linux-any], libcap-dev [linux-any],
dh-autoreconf, liblzma-dev, libzstd-dev, dh-runit (>= 2.8.8)
Build-Conflicts: libnacl-dev, libseccomp-dev [!amd64 !i386]
Standards-Version: 3.9.8
Homepage: https://www.torproject.org/
@@ -14,6 +14,7 @@ Architecture: any
Depends: ${shlibs:Depends}, adduser, ${misc:Depends}, lsb-base
Pre-Depends: ${misc:Pre-Depends}
Conflicts: libssl0.9.8 (<< 0.9.8g-9)
+Breaks: ${runit:Breaks}
Recommends: logrotate, tor-geoipdb, torsocks
Suggests: mixmaster, torbrowser-launcher, socat, tor-arm, apparmor-utils,
tor-arm, obfs4proxy
Description: anonymizing overlay network for TCP
diff --git a/debian/rules b/debian/rules
index 710d166..22c093a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -26,6 +26,7 @@ endif
$@ \
--with quilt \
--with autoreconf \
+ --with runit \
$(dhoptions) \
--builddirectory=build \
--parallel
diff --git a/debian/tor.install b/debian/tor.install
index 97da1ca..566d16a 100644
--- a/debian/tor.install
+++ b/debian/tor.install
@@ -11,3 +11,5 @@ debian/systemd/tor.service lib/systemd/system
debian/systemd/tor@.service lib/systemd/system
debian/systemd/tor@default.service lib/systemd/system
debian/systemd/tor-generator lib/systemd/system-generators
+
+debian/tor.runscript/conf/* /etc/tor/conf
diff --git a/debian/tor.runit b/debian/tor.runit
new file mode 100644
index 000..5ca5bca
--- /dev/null
+++ b/debian/tor.runit
@@ -0,0 +1 @@
+debian/tor.runscript name=tor,logscript,since=0.3.5.8-1+runit
diff --git a/debian/tor.runscript/conf/MAX_FILEDESCRIPTORS
b/debian/tor.runscript/conf/MAX_FILEDESCRIPTORS
new file mode 100644
index 000..252cb66
--- /dev/null
+++ b/debian/tor.runscript/conf/MAX_FILEDESCRIPTORS
@@ -0,0 +1 @@
+8192
diff --git a/debian/tor.runscript/run b/debian/tor.runscript/run
new file mode 100644
index 000..b6854c6
--- /dev/null
+++ b/debian/tor.runscript/run
@@ -0,0 +1,23 @@
+#!/usr/bin/env /lib/runit/invoke-run
+readonly daemon=/usr/bin/tor
+exec 2>&1
+
+ulimit -n "${MAX_FILEDESCRIPTORS}"
+
+# default invocation
+set -- "${daemon}" \
+ --defaults-torrc /usr/share/tor/tor-service-defaults-torrc \
+ -f /etc/tor/torrc \
+ --Log 'notice stdout' \
+ --RunAsDaemon 0
+
+if ! "$@" --verify-config ; then
+ echo "persistent error: Tor configuration is not valid"
+ exec sv down tor
+fi
+
+if aa-status --enabled ; then
+ set -- aa-exec --profile=system_tor -- "$@"
+fi
+
+exec "$@"
Bug#672155: qmail: unowned files after purge
control: tags -1 patch Hello. Here is patch to solve bug. From 3a14e36f95ab1c5a6eb8bb0953cd13990d42b344 Mon Sep 17 00:00:00 2001 From: Dmitry Bogatov Date: Wed, 5 Jun 2019 10:37:58 + Subject: [PATCH] Make package piupart-clean Close: #672155 --- debian/qmail.postrm | 6 ++ 1 file changed, 6 insertions(+) diff --git a/debian/qmail.postrm b/debian/qmail.postrm index 255c4b2..6674240 100644 --- a/debian/qmail.postrm +++ b/debian/qmail.postrm @@ -8,5 +8,11 @@ test ! -d /var/lib/qmail || rmdir /var/lib/qmail || : test "$1" = 'purge' || exit 0 rm -f /etc/qmail/users/* +rm -f /etc/qmail/defaultdomain +rm -f /etc/qmail/locals +rm -f /etc/qmail/me +rm -f /etc/qmail/plusdomain +rm -f /etc/qmail/rcpthosts + test ! -d /etc/qmail/users || rmdir /etc/qmail/users || : test ! -d /etc/qmail || rmdir /etc/qmail || : -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction -- pgpDPVnfZTqRf.pgp Description: PGP signature
Bug#928921: reprotest: kernel too old SIGSEGV
control: retitle -1 reprotest: unable to chown [2019-05-12 22:12] Vagrant Cascadian > On 2019-05-13, Dmitry Bogatov wrote: > > Hello. I am working on setting up CI for my packages, and one of them > > fail "reprotest" phase with error: "FATAL: kernel too old"[1][2]. > > This is probably due to the kernel variation using "setarch", which will > cause uname to report a 2.6 kernel, which is too old for some things... > > You should be able to disable it with --variations=+all,-kernel Thank you very much. It did solve the issue. But while setting up CI for another package, I encountered another issue: install: fatal: unable to chown /tmp/reprotest.1SX4Bu/build-experiment-1/debian/qmail/var/lib/qmail: invalid argument Package builds fine, both on CI and locally, and content [full log](https://salsa.debian.org/kaction/qmail/-/jobs/188411) -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#866038: qmail: "hostname -f returned: $1"
control: tags -1 +patch
Hello. Here is patch to fix the problem. Gerrit, what do you think? Do
you want to make upload yourself or should I NMU?
Also, FYI, there is salsa.debian.org/kaction/qmail repository with more
patches.
From 83fb3c44825570502e5c9634ac1811f82050b907 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Sun, 2 Jun 2019 12:17:24 +
Subject: [PATCH] Fix quotation in postinst
Closes: #866038
---
debian/qmail.postinst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/qmail.postinst b/debian/qmail.postinst
index 540f0f1..0fc53c2 100644
--- a/debian/qmail.postinst
+++ b/debian/qmail.postinst
@@ -2,7 +2,7 @@
set -e
stopinst() {
- cat <<-\EOT >&2
+ cat <<-EOT >&2
The hostname -f command returned: $1
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
pgpk4L59Baldy.pgp
Description: PGP signature
Bug#929884: dnsmasq: please provide runscript file
Source: dnsmasq
Version: 2.80-1
Severity: wishlist
Tags: patch
User: ru...@packages.debian.org
Usertags: runscript
Dear maintainer,
please include native script for runit init system into 'dnsmasq'.
Below is diff aganist latest package release (2.80-1).
Here are some links:
* http://smarden.org/runit -- more information about 'runit'
* https://bugs.debian.org/746715 -- technical committe position
on support of init systems, other then sysvinit.
From 3c516dde2b8dd552b141196ed98379800b3e0611 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Sun, 26 May 2019 18:54:36 +
Subject: [PATCH] Add integration script for runit init
---
debian/control | 5 ++--
debian/dnsmasq.runit| 1 +
debian/dnsmasq.runscript/finish | 5
debian/dnsmasq.runscript/run| 43 +
debian/rules| 7 +-
5 files changed, 58 insertions(+), 3 deletions(-)
create mode 100644 debian/dnsmasq.runit
create mode 100755 debian/dnsmasq.runscript/finish
create mode 100755 debian/dnsmasq.runscript/run
diff --git a/debian/control b/debian/control
index 9d4d7e8..40ad6c6 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: optional
Build-depends: gettext, libnetfilter-conntrack-dev [linux-any],
libidn11-dev, libdbus-1-dev (>=0.61), libgmp-dev,
nettle-dev (>=2.4-3), libbsd-dev [!linux-any],
- liblua5.2-dev
+ liblua5.2-dev, dh-runit, debhelper-compat (= 10)
Maintainer: Simon Kelley
Homepage: http://www.thekelleys.org.uk/dnsmasq/doc.html
Standards-Version: 3.9.8
@@ -12,8 +12,9 @@ Standards-Version: 3.9.8
Package: dnsmasq
Architecture: all
Depends: netbase, dnsmasq-base,
- init-system-helpers (>= 1.18~), lsb-base (>= 3.0-6)
+ init-system-helpers (>= 1.18~), lsb-base (>= 3.0-6), ${misc:Depends}
Suggests: resolvconf
+Breaks: ${runit:Breaks}
Conflicts: resolvconf (<<1.15)
Description: Small caching DNS proxy and DHCP/TFTP server
Dnsmasq is a lightweight, easy to configure, DNS forwarder and DHCP
diff --git a/debian/dnsmasq.runit b/debian/dnsmasq.runit
new file mode 100644
index 000..6a457f7
--- /dev/null
+++ b/debian/dnsmasq.runit
@@ -0,0 +1 @@
+debian/dnsmasq.runscript name=dnsmasq,logscript,since=2.80-1+runit
diff --git a/debian/dnsmasq.runscript/finish b/debian/dnsmasq.runscript/finish
new file mode 100755
index 000..cf35240
--- /dev/null
+++ b/debian/dnsmasq.runscript/finish
@@ -0,0 +1,5 @@
+#!/bin/sh -eu
+if [ -x /sbin/resolvconf ] ; then
+ /sbin/resolvconf -d lo.dnsmasq
+fi
+
diff --git a/debian/dnsmasq.runscript/run b/debian/dnsmasq.runscript/run
new file mode 100755
index 000..1a43393
--- /dev/null
+++ b/debian/dnsmasq.runscript/run
@@ -0,0 +1,43 @@
+#!/lib/runit/invoke-run
+
+readonly name=dnsmasq
+readonly daemon=/usr/sbin/dnsmasq
+readonly marker=/usr/share/dnsmasq/installed-marker
+
+test -e "${marker}" || exec sv down "${name}"
+test -x "${daemon}" || exec sv down "${name}"
+
+if [ ! "${RESOLV_CONF:-}" ] &&
+ [ "${IGNORE_RESOLVCONF:-}" != "yes" ] &&
+ [ -x /sbin/resolvconf ]
+then
+ RESOLV_CONF=/run/dnsmasq/resolv.conf
+fi
+
+# This tells dnsmasq to ignore DNS requests that don't come from a local
network.
+# It's automatically ignored if --interface --except-interface,
--listen-address
+# or --auth-server exist in the configuration, so for most installations, it
will
+# have no effect, but for otherwise-unconfigured installations, it stops
dnsmasq
+# from being vulnerable to DNS-reflection attacks.
+
+DNSMASQ_OPTS="${DNSMASQ_OPTS:-} --local-service"
+
+# If the dns-root-data package is installed, then the trust anchors will be
+# available in $ROOT_DS, in BIND zone-file format. Reformat as dnsmasq
+# --trust-anchor options.
+
+ROOT_DS="/usr/share/dns/root.ds"
+
+if [ -f $ROOT_DS ]; then
+DNSMASQ_OPTS="$DNSMASQ_OPTS `env LC_ALL=C sed -rne
"s/^([.a-zA-Z0-9]+)([[:space:]]+[0-9]+)*([[:space:]]+IN)*[[:space:]]+DS[[:space:]]+/--trust-anchor=\1,/;s/[[:space:]]+/,/gp"
$ROOT_DS | tr '\n' ' '`"
+fi
+
+mkdir -p /run/dnsmasq
+chown dnsmasq:nogroup /run/dnsmasq
+[ -x /sbin/restorecon ] && /sbin/restorecon /run/dnsmasq
+exec "${daemon}" \
+ --keep-in-foreground \
+ --log-facility=/dev/stdout \
+ ${RESOLV_CONF:+ -r $RESOLV_CONF} \
+ ${DNSMASQ_OPTS} \
+ -u dnsmasq
diff --git a/debian/rules b/debian/rules
index b4ec4e9..f8d84fd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -159,6 +159,9 @@ clean:
binary-indep: checkroot
$(checkdir)
rm -rf debian/trees/daemon
+ mkdir -p debian/trees
+ dh_runit -pdnsmasq
+ mv debian/dnsmasq/ debian/trees/daemon
install -m 755 \
-d debian/trees/daemon/DEBIAN \
-d debian/trees/daemon/usr/share/doc \
Bug#929883: RFP: geomyidae -- gopher server for Linux/BSD
Package: wnpp Severity: wishlist Programming Language: C Homepage: gopher://bitreich.org/1/scm/geomyidae Features: * gopher menus (see index.gph for an example) * dir listings (if no index.gph was found) * CGI support (.cgi files are executed) * search support in CGI files * logging (-l option) and loglevels (-v option) pgp1u5ZLjf5ms.pgp Description: PGP signature
Bug#929778: dh-runit: install presubj file for reportbug(1)
Package: dh-runit Version: 2.8.8 Severity: wishlist Dear Maintainer, I propose to add new option "presubj" to dh_runit. With this option, dh_runit should install file into /usr/share/bug, so when user is about to report a bug in a package with reportbug(1), he will be shown notice, that if bug is in runit integration, he should add runit mailing list into CC, to relieve burden from maintainer of service, who unlikely to use runit init system himself. -- System Information: Debian Release: 10.0 APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=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 dh-runit depends on: ii debhelper 12.1.1 dh-runit recommends no packages. dh-runit suggests no packages. -- no debconf information -- debsums errors found: debsums: changed file /usr/bin/dh_runit (from dh-runit package) pgpvhoPLdaIvz.pgp Description: PGP signature
Bug#929709: libgdbm6: file exists in libgdbm-dev as well as gdbm
control: severity -1 minor [2019-05-29 13:31] lkcl > Package: libgdbm6 > Version: 1.18.1-4 > Severity: serious > Justification: 2 > > Unpacking libgdbm-dev:amd64 (1.18.1-4) ... > dpkg: error processing archive > /var/cache/apt/archives/libgdbm-dev_1.18.1-4_amd64.deb (--unpack): > trying to overwrite '/usr/share/info/gdbm.info.gz', which is also in package > libgdbm3:amd64 1.8.3-11 > Errors were encountered while processing: > /var/cache/apt/archives/libgdbm-dev_1.18.1-4_amd64.deb Issue, yes. But you are upgrading from rather old version of libgdbm3. According to https://tracker.debian.org/gdbm, it predates even old-stable. Since Debian does not support skip upgrades, this issue is not release-critical. Downgrading severity. I just checked in virtual machine, upgrade stable (1.8.3-14) -> testing (1.18.1-4) seems fine. Please, consider upgrading gradually. I doubt that release team would approve unblock for issue of upsupported upgrade, sorry. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#929709: libgdbm6: file exists in libgdbm-dev as well as gdbm
control: severity -1 minor [2019-05-29 13:31] lkcl > Package: libgdbm6 > Version: 1.18.1-4 > Severity: serious > Justification: 2 > > Unpacking libgdbm-dev:amd64 (1.18.1-4) ... > dpkg: error processing archive > /var/cache/apt/archives/libgdbm-dev_1.18.1-4_amd64.deb (--unpack): > trying to overwrite '/usr/share/info/gdbm.info.gz', which is also in package > libgdbm3:amd64 1.8.3-11 > Errors were encountered while processing: > /var/cache/apt/archives/libgdbm-dev_1.18.1-4_amd64.deb Issue, yes. But you are upgrading from rather old version of libgdbm3. According to https://tracker.debian.org/gdbm, it predates even old-stable. Since Debian does not support skip upgrades, this issue is not release-critical. Downgrading severity. I just checked in virtual machine, upgrade stable (1.8.3-14) -> testing (1.18.1-4) seems fine. Please, consider upgrading gradually. I doubt that release team would approve unblock for issue of upsupported upgrade, sorry. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#929063: SELinux integration in sysVinit
[ Sorry, if I messed quotation. It is complex ] [2019-05-24 21:00] Jason Zaman > > > There is currently some discussion at [0] about SELinux > > > integration in sysVinit and the fact that somebody wants to > > > delegate the loading of the policy to an other binary than PID1. > > > > > > Has somebody a remark or an objection to that proposal? > > > > I object too. There is a *huge* change in functionality. Originally if > > you boot with SELinux enforcing, there are only two things that can > > happen. Either you end up with the policy loaded or the machine halts. > > > > In the new patch, an attacker can just chmod -x /sbin/selinux-check then > > next boot there will be no selinux enabled. > > > > if (access(SELINUX_CHECK, X_OK) != 0) fails, the machine will continue > > to boot without SELinux enabled. There is no difference between a user > > without /sbin/selinux-check on purpose and an attacker just chmod -x'd > > the tool. > > > > SELinux does not protect /sbin anywhere near as much as /etc/selinux > > (and doing that would probably be impossible). You'd need to check if > > selinux is enabled and enforcing before skipping the loading ... which > > is done by calling is_selinux_enabled() which needs linking to > > libselinux. The important part of the original design is not > > selinux_init_load_policy(), its is_selinux_enabled(). How does it come that attacker can just "chmod -x /sbin/selinux-check"? Aren't there supposed to be SELinux rule, preventing attacker from doing this, even if he cracked root process? Okay, this patch should be accompanied with patch to src:refpolicy, correct? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#929063: SELinux integration in sysVinit
[ Sorry, if I messed quotation. It is complex ] [2019-05-24 21:00] Jason Zaman > > > There is currently some discussion at [0] about SELinux > > > integration in sysVinit and the fact that somebody wants to > > > delegate the loading of the policy to an other binary than PID1. > > > > > > Has somebody a remark or an objection to that proposal? > > > > I object too. There is a *huge* change in functionality. Originally if > > you boot with SELinux enforcing, there are only two things that can > > happen. Either you end up with the policy loaded or the machine halts. > > > > In the new patch, an attacker can just chmod -x /sbin/selinux-check then > > next boot there will be no selinux enabled. > > > > if (access(SELINUX_CHECK, X_OK) != 0) fails, the machine will continue > > to boot without SELinux enabled. There is no difference between a user > > without /sbin/selinux-check on purpose and an attacker just chmod -x'd > > the tool. > > > > SELinux does not protect /sbin anywhere near as much as /etc/selinux > > (and doing that would probably be impossible). You'd need to check if > > selinux is enabled and enforcing before skipping the loading ... which > > is done by calling is_selinux_enabled() which needs linking to > > libselinux. The important part of the original design is not > > selinux_init_load_policy(), its is_selinux_enabled(). How does it come that attacker can just "chmod -x /sbin/selinux-check"? Aren't there supposed to be SELinux rule, preventing attacker from doing this, even if he cracked root process? Okay, this patch should be accompanied with patch to src:refpolicy, correct? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#929693: runit: invoke-run should handle installed-not-purged case
Package: runit
Version: 2.1.2-29
Severity: normal
Dear Maintainer,
currently, "invoke-run" script assumes, that service to be started is
present. Period. Actually, since /etc/sv//run script is conffile,
so it to be there, while daemon binary is removed.
I init.d scripts is is handled by something like
test -x ${DAEMON} || exit 0
pgp6_sLEAizS8.pgp
Description: PGP signature
Bug#926471: lintian | WIP: Check that daemons have init.d script (Closes: #926471) (!202)
[2019-05-23 14:27] Chris Lamb > https://bugs.debian.org/926471#20 It seems that tests pass, but code style check fails: code checker demands "return" at the end of "check_missing_script" function. Since this function is void, I do not understand why "return" is needed. Anyway, what do you want me to do on this matter? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#928809: lintian: suggest adding gitlab-ci file
[2019-05-23 07:09] "Chris Lamb" > Mattia Rizzolo wrote: > > > > (Personally, I doubt someone would fork Lintian, more likely its > > > output would become less and less "trusted". But both outcomes suck.) > > > > Rather, people who until at some point diligently read the whole > > lintian output for every single upload they do, may just decide that it > > is too bothersome to do it anymore, and STO reading it. > > You phrased my "output would become less and less trusted" better than > I originally did. Again, I think we are all agreeing here. :) Okay. So resolution is "wontfix"? I am fine with maintaining custom profile, but it raises question of discoveribility: should many different developers maintain separate repositories of custom, not universally-accepted checks, we will get work duplication and fragmentation. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#929063: SELinux integration in sysVinit
[ Sorry, if I messed quotation. It is complex ] [2019-05-24 21:00] Jason Zaman > > > There is currently some discussion at [0] about SELinux > > > integration in sysVinit and the fact that somebody wants to > > > delegate the loading of the policy to an other binary than PID1. > > > > > > Has somebody a remark or an objection to that proposal? > > > > I object too. There is a *huge* change in functionality. Originally if > > you boot with SELinux enforcing, there are only two things that can > > happen. Either you end up with the policy loaded or the machine halts. > > > > In the new patch, an attacker can just chmod -x /sbin/selinux-check then > > next boot there will be no selinux enabled. > > > > if (access(SELINUX_CHECK, X_OK) != 0) fails, the machine will continue > > to boot without SELinux enabled. There is no difference between a user > > without /sbin/selinux-check on purpose and an attacker just chmod -x'd > > the tool. > > > > SELinux does not protect /sbin anywhere near as much as /etc/selinux > > (and doing that would probably be impossible). You'd need to check if > > selinux is enabled and enforcing before skipping the loading ... which > > is done by calling is_selinux_enabled() which needs linking to > > libselinux. The important part of the original design is not > > selinux_init_load_policy(), its is_selinux_enabled(). How does it come that attacker can just "chmod -x /sbin/selinux-check"? Aren't there supposed to be SELinux rule, preventing attacker from doing this, even if he cracked root process? Okay, this patch should be accompanied with patch to src:refpolicy, correct? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#929063: init: delegate selinux operation to separate binary
[2019-05-22 18:24] Jesse Smith > On Wed, 22 May 2019 13:28:39 +0200 (CEST) Thorsten Glaser wrote: > > > > (I’m not quite convinced the effort is worth it, but given that > > this would be changed upstream, and that there are likely other > > users of the same upstream code who’re _not_ using SELinux, this > > would be very welcomed by those, so I’m okay with it.) > > I'd like to point out that init already has compile-time defines in the > code which check for the existence of SELinux (using the variable > WITH_SELINUX). If WITH_SELINUX is not defined at compile time, then the > SELinux code isn't built into init. So other projects, perhaps Debian > Hurd or FreeBSD, can already build init without SELinux features. Sure. Difference is in convenience. One thing is when you have to re-compile program to get those and only those features you need (hi, Gentoo) and another is when you just install and uninstall pre-compiled binaries. Also, every WITH_FOO flag doubles number of configurations your program have. Once you have dozen of flags, you no longer can test all of configurations. I am surprised, that there is so much controversy on whether it is good to have some feature of program pluggable without re-compilation. The only real concern that was raised, as I see it, is how SELinux interacts with extra fork/exec. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#928809: lintian: suggest adding gitlab-ci file
[2019-05-20 15:45] Mattia Rizzolo > On Fri, May 17, 2019 at 08:58:03AM +0100, Chris Lamb wrote: > [...] > > (This kind of conversation always makes me wonder if we need another > > level of "extra pendatic" that people need to opt into... *g*) > > Nah. I just think that lintian should be less pro-active at adding > checks for things that are far from accepted. That is why I propose introducing concept of "controversial" checks. Having Lintian plainly reject such proposals would mean need in creation of something like "lintian-unofficial", that would be wasted technical effort on setting up new source package, re-using Lintian library and so on. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#928969: stterm: incorrect rendering of cyrillic letters with Terminus
[2019-05-19 23:49] Paride Legovini > I tried with xterm and sakura, the Cyrillic string renders exactly as > in stterm, with the correct character width and spacing. > Let me know if there is anything else I can try. Okay. I prepared kvm virtual machine image, that you can download from "people.debian.org/~kaction/stterm-bug.img.xz". After it boots, it shows Xdm prompt. Log is as "user:useruser". You will have default "dwm" instance. Press Alt-Shift-Enter and some terminal will appear. There is ~user/I-Will-Show-You.sh script, that starts stterm to show difference between cyrillic "Привет, мир!" and ascii "Hello, world!". Hope, you will see same thing as me. After that, you can get root permission with su and "root:rootroot". -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#929063: init: delegate selinux operation to separate binary
[2019-05-18 15:00] Laurent Bigonville
> I've seen that in your commit, I just don't understand why this is even
> a goal.
Because I do not want to pay for what I do not use. It is matter of good
design and Unix way.
> libselinux is really small and only pulls libpcre3 which is pulled by
> grep (which is Essential). It's not possible today to install debian
> without libselinux installed anyway.
Path of a thousand miles starts with a single step.
> Also, what's your plan regarding packaging? Would that executable be
> put in a separate package?
Yes, that the plan.
> TBRH I spent a lot of time working opening bugs/submitting patches in
> debian so the user who wants to use SELinux can get (an almost) out of
> the box experience in debian and I would not really be happy to see
> that attempt to revert that in a core component.
And I spend a lot of time of not having useless things installed on my
box.
What is wrong with having selinux support in separate package? Just
enable "Apt::InstallSuggests" and you are golden.
> If you really (really) want to go that way, maybe you should use a
> private path for the helper (as it shouldn't be called my regular users
> after the initial load) and/or use a less common name than "selinux-check".
No problem. I do not insist on any particular naming of helper and I
installed it into sbin just to reduce Makefile part of patch.
It was my plan to install it into /lib/init/ anyway, and you are welcome
to propose any name. What do you suggest?
> >> Was that discussed with anybody involved in SELinux in debian and/or
> >> upstream?
> > That is exactly place to start discussion. Luckily, Jesse is following
> > BTS, and I do not have to go through Savannah issue tracker.
>
> I was more thinking about upstream SELinux people
Okay. I see you added "selinux-devel" into thread. Thank you.
Dear selinux-devel maintainers, we are considering moving following
check from /sbin/init into subprocess:
if (getenv("SELINUX_INIT") == NULL) {
if (is_selinux_enabled() != 1) {
if (selinux_init_load_policy() == 0) {
putenv("SELINUX_INIT=YES");
execv(myname, argv);
} else {
if (enforce > 0) {
/* SELinux in enforcing mode but load_policy failed */
/* At this point, we probably can't open /dev/console, so log()
won't work */
fprintf(stderr,"Unable to load SELinux Policy. Machine is in
enforcing mode. Halting now.\n");
exit(1);
}
}
}
}
Are there any possible unwanted side-effects? Any suggestions about it?
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#929063: Moving SELinux check
[2019-05-18 16:14] Jesse Smith > From a practical perspective, I'm curious if there is any benefit or > drawback. Is this patch fixing a known bug, > does it significantly reduce the size of PID 1 in memory? Not that I really care about 1Mb of RAM, but: 152K/lib/x86_64-linux-gnu/libselinux.so.1 692K/lib/x86_64-linux-gnu/libsepol.so.1 460K/lib/x86_64-linux-gnu/libpcre.so.3.13.3 -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#929339: RFP: qsmtp - drop-in replacement for qmail STMP programs
Package: wnpp Severity: wishlist Qsmtp is a drop in replacement for the qmail SMTP programs qmail-smtpd and qmail-remote. That means you just change your startup scripts to use Qsmtpd instead of qmail-smtpd and most things will work as before. The initial point was a heavily patched qmail-smtpd to get some decent antispam features. This was then rewritten from scratch into a new binary that was designed to allow easy extension to new mail filters. Another design goal was to be 100% IPv6 clean. • Fast and small: written in plain C • IPv6 clean • Many antispam modules included, e.g. SPF, IP blacklists, domain blacklists, badmailfrom, helo filtering • Easy API to add your own spamfilters • For vpopmail hosts: does not create bounces for non-existing users • Tested: includes unit tests, nightly checks available at http://my.cdash.org/index.php?project=Qsmtp pgpy6HbvQIaEQ.pgp Description: PGP signature
Bug#928919: patch: Do not hide errors from initscripts
[2019-05-18 23:26] Thorsten Glaser > > If initscript is called during postinst and fail -- yes, it interrupts > > installation. And it is bug in package. > > No, I can install a package and not have it start perfectly fine. You have exit status 6 for case of package not being configured. Otherwise, I strongly disagree with "failure to start service fine". > Worse is breakage on package *removal*, especially in situations > where the system is wrecked (e.g. package install was aborted) > anyway. > > Breaking apt is more evil than some dæmon not starting during > the system run (on large upgrades, a reboot will be done anyway, > so the problem is very transient). Yeah, having non-unstallable package is evil. But I think hiding the fact, that initscript is broken is even more evil. But with these matters of good and evil we got off the main discussion: what is wrong with having initscripts from bin:initscripts more sensible exit values, given they are not invoked in maintainer scripts? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#928969: stterm: incorrect rendering of cyrillic letters with Terminus
[2019-05-17 18:43] Paride Legovini > I tried with xterm and sakura, the Cyrillic string renders exactly as > in stterm, with the correct character width and spacing. I have found workaround. My regular locale is eo.utf-8, but many X applications (stterm included) fail to start with following error: XOpenIM failed. Could not open input devices. so I start them with LC_ALL=C.UTF-8. Funny thing, I just tried to start "LC_ALL=ru_RU.utf8 stterm -f Terminus", and it rendered cyrillic text properly. But I still believe, that different rendring on different utf-8 locales is a bug. Can you re-do checks with LC_ALL=C.UTF-8? > > Not sure, that it is relevant, but in xterm(1) I found following: > > > > The reason for this resource is to help with certain > > quasi-automatically generated fonts (such as the ISO-10646-1 encoding > > of Terminus) which have incorrect font-metrics.> > > Maybe there are known issues with terminus font, and other terminal > > emulators provide special care for it? > > Could be, I don't know. The font's homepage [0] says that: > > Version 4.47 contains 1326 characters, covers about 120 language > sets and supports ISO8859-1/2/5/7/9/13/15/16 [...] > > and ISO5589-5 is Latin/Cyrillic, so I don't think there are > auto-generated fonts. It also says that Terminus is a "fixed width > bitmap font". On my system I have disabled the bitmap fonts: I have this > symbolic link in place: > > /etc/fonts/conf.d/70-no-bitmaps.conf -> > /usr/share/fontconfig/conf.avail/70-no-bitmaps.conf No, I did no configuration in /etc/fonts/conf.d. I wasn't aware of it. > so maybe even if I explicitly ask for Terminus the terminals lie to me, > and another fallback font is actually used. Did you disable the bitmap > fonts? > Another question. You said xterm renders Terminus well. From how it > looks, can you tell if it is actually Terminus or another font? I did not checked that xterm(1) renders well: $ xterm -f Terminus did not work. I checked sakura(1) and terminology(1). If they are lying to me, they do it very well -- I can't tell the difference. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#928935: Invoke-run: add a way to not stop sysv scripts
[2019-05-17 22:02] Lorenz
> Hi,
>
> > True. Here are patches. What do you think?
>
> I haven't had time to test but the patch looks good to me, just an
> observation:
> to my experience
>
> /etc/init.d/${service} status
>
> is not always reliable in term of both results and exit codes, we will have
> the chance to fix a certain number of sysv init scripts because of this
True. Actually, according to Policy, "status" command is not mandatory,
but I know no better way to figure out, whether sysvinit instance is
running.
Let us hope, that for most non-restartible sevices "status" command
exists and behaves reasonably.
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#928919: patch: Do not hide errors from initscripts
[2019-05-16 14:47] Thorsten Glaser > On Thu, 16 May 2019, Dmitry Bogatov wrote: > > > Having trailing ":" would result of ignoring result these "do_*" functions. > > This is normally right. Initscripts must return 0 in most cases, Why? > and only explicitly exit with a nonzero errorlevel when needed. How do you define "when needed"? In my opinion, ignoring errors must be explicit (e.g || :), checking for them -- default. > > Exit status of initscript does not affect boot process: see "startup()" > > from /etc/init.d/rc (no set -e): > > Hmm, what was it then... this is from Policy §9.3.2... Policy: For "init.d" scripts, it’s often easier to not use "set -e" and instead check the result of each command separately. Just a advice, that, in my opinion, promotes reckless scripting. > but it can make package installation fail, that much is sure. If initscript is called during postinst and fail -- yes, it interrupts installation. And it is bug in package. But how initscripts can fail to install for that reason? They are not invoked in postinst. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#929063: init: delegate selinux operation to separate binary
[2019-05-16 11:43] Laurent Bigonville > On Thu, 16 May 2019 08:54:43 +0000 Dmitry Bogatov > wrote: > > > > From 7f6242e5f3d893e90b3ed44fb09abe5983c2d49a Mon Sep 17 00:00:00 2001 > > From: Dmitry Bogatov > > Date: Wed, 15 May 2019 12:10:13 + > > Subject: [PATCH] init: delegate selinux operation to separate binary > Can you please explain the rational behind this? This way, /sbin/init is no longer linked aganist libselinux (and its transitive dependencies). If user need selinux initialization, she can install /sbin/selinux-check separately. > This looks like a bad idea to me. SELinux needs to be initialized as > soon as possible during the boot otherwise this will call for issues. As you may see, this patch does not change time during boot, when selinux functions are called -- only moves them into child process. > Was that discussed with anybody involved in SELinux in debian and/or > upstream? That is exactly place to start discussion. Luckily, Jesse is following BTS, and I do not have to go through Savannah issue tracker. PS. I removed -lselinux from INITLIBS in src/Makefile. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#928809: lintian: suggest adding gitlab-ci file
[2019-05-17 08:58] "Chris Lamb" > tags 928809 + moreinfo > thanks > > Mattia Rizzolo wrote: > > > it wouldn't even make sense since they lack a testsuite > > Wwat would you say this only triggered if the package had a testsuite > or autopkgtests? Not enough for me. I want piuparts checks and build check, not matter whether I have autopkgtest. > > I don't think test-building the whole package every commit is useful > > Can you elaborate why? I find this a somewhat curious statement > in 2019. > > (This kind of conversation always makes me wonder if we need another > level of "extra pendatic" that people need to opt into... *g*) And after that extra-extra-pedantic, and so on. What about list of "controversal" checks, that are hidden by default, and are enabled one-by-one with something like lintian --enable-controversal-check missing-gitlab-ci ( We all know how to write shell aliases. ) I suggest makeing it impossible to turn of all controversal by single flag (or it will become extra-pedantic), and refer in documentation to /usr/share/lintian/checks/controversal.desc -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#928919: patch: Do not hide errors from initscripts
[2019-05-13 12:58] Thorsten Glaser
> On Mon, 13 May 2019, Dmitry Bogatov wrote:
>
> > @@ -65,5 +65,3 @@ case "$1" in
> > exit 3
> > ;;
> > esac
> > -
> > -:
>
> I think this is not advisable. What this will do is
> cause the last errorlevel to be returned by the script,
> which may not be an error but simply the result of a
> test command.
Then this initscripts will always fail. Bug to fix. But actually, most
scripts have following form:
case $1 in
start) do_start ;;
stop) do_stop ;;
# [...]
esac
Having trailing ":" would result of ignoring result these "do_*" functions.
It is true, that some of them, unfortunately, do not thread return
value properly (ex: mountall).
This change in no way complete, but just one step in direction when exit
status of initscript is meaningful.
> Initscripts explicitly call the exit built-in utility
> in case of errors and must not use 'set -e', but even
> so, this may break some legit uses.
Not that it is good thing, but I know, that both initscripts and
lsb-base can't be used with "set -e".
What legit uses you are talking about?
> Furthermore, not erroring out seems to be the proper fallback case for
> initscripts because doing otherwise may cause the system to not boot,
> which is the greater evil.
Exit status of initscript does not affect boot process: see "startup()"
from /etc/init.d/rc (no set -e):
startup() {
action=$1
shift
scripts="$@"
for script in $scripts ; do
$debug "$script" $action
done
}
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#928935: Invoke-run: add a way to not stop sysv scripts
control: tags -1 +pending +patch
[2019-05-13 14:35] Lorenzo Puliti
> Hi,
>
> In order to avoid conflicts, recent version of invoke-run interpreter stops
> the sysv
> init scripts before starting the run service.
> Please note that this logic, when applied to daemons like dbus, slim, sddm,
> lightdm
> (and possibly others) will break the graphic session, so there is need for a
> way
> to prevent the sysv script being replaced by the run script while the graphic
> session
> is active.
> This also will need support in dh-runit.
True. Here are patches. What do you think?
From 66e9071165250793d8900f17cd5b35ca7b45526b Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Tue, 14 May 2019 10:45:06 +
Subject: [PATCH] invoke-run: add option to not stop sysv scripts
Closes: #928935
---
debian/contrib/lib/invoke-run | 10 ++
1 file changed, 10 insertions(+)
diff --git a/debian/contrib/lib/invoke-run b/debian/contrib/lib/invoke-run
index a424b73..9fa5c59 100755
--- a/debian/contrib/lib/invoke-run
+++ b/debian/contrib/lib/invoke-run
@@ -40,7 +40,17 @@ if [ -r "/etc/default/${service}" ] ; then
fi
readonly initscript="/etc/init.d/${service}"
+readonly noreplace="/var/lib/runit/noreplace/${service}"
+
if [ -x "${initscript}" ] ; then
+ # Stopping some services (e.g display manager) is disruptive
+ # and must be done only manually by user.
+ if [ -f "${noreplace}" ] ; then
+ if "${initscript}" status >/dev/null 2>&1 ; then
+ sv down "${service}"
+ exit 0
+ fi
+ fi
"${initscript}" stop
fi
And here is patch for dh_runit. It may be more convenient to see it at
salsa.debian.org/runit-team/dh-runit.
From cb411affcbc2eb183ee5f35e50c3863c0b94f98a Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Tue, 14 May 2019 15:41:52 +
Subject: [PATCH] Add option to mark service as non-restartable
---
dh_runit | 18 ++
t/924903.t | 5 -
t/928935.t | 10 ++
3 files changed, 32 insertions(+), 1 deletion(-)
create mode 100644 t/928935.t
diff --git a/dh_runit b/dh_runit
index 5ed55b5..4c9820e 100755
--- a/dh_runit
+++ b/dh_runit
@@ -5,6 +5,7 @@ use v5.10.1;
use strict;
use Debian::Debhelper::Dh_Lib;
use File::Find;
+use File::Path qw(make_path);
use File::stat;
use feature 'signatures';
no warnings 'experimental';
@@ -17,6 +18,7 @@ sub parse_options($opts) {
when (/^name=(.*)$/) { $conf->{name} = $1; };
when (/^since=(.*)$/) { $conf->{since} = $1; };
when (/^logscript$/) { $conf->{logscript} = 1};
+when (/^noreplace$/) { $conf->{noreplace} = 1};
when (/^defaults$/){ "do nothing"; };
default{ error("unknown option `$opt'"); }
}
@@ -59,6 +61,13 @@ PKG: foreach my $pkg (@{$dh{DOPACKAGES}}) {
my $conf = parse_options($opts);
my $name = $conf->{name} || basename($path);
+if ($conf->{noreplace}) {
+make_path("${tmp}/var/lib/runit/noreplace/");
+open(my $fh, ">", "${tmp}/var/lib/runit/noreplace/${name}")
+|| die $!;
+close($fh);
+}
+
if ( -f $path) {
install_dir("$sv_dir/$name");
install_prog($path, "$sv_dir/$name/run");
@@ -182,6 +191,15 @@ version of package. See #923233.
If this option is not specified, it means that runscript was provided
all history of package.
+=item I
+
+Mark service as non-restartible. Interpreter B, provided by
+I package does not stop sysvinit-managed instance of service to
+replace it with runit-managed instance when service is marked as
+non-restartible.
+
+Display managers (xdm, kdm, ...) are examples of non-restartible services.
+
=item I
If you don't need other options, specify this one.
diff --git a/t/924903.t b/t/924903.t
index 710ea39..b969314 100644
--- a/t/924903.t
+++ b/t/924903.t
@@ -1,7 +1,7 @@
#!/usr/bin/perl
use strict;
use warnings;
-use Test::More tests => 3;
+use Test::More tests => 4;
use File::stat;
use T;
@@ -11,3 +11,6 @@ ok(-d $path, 'supervise directory correctly created');
my $info = stat($path);
my $mode = sprintf("%o", $info->mode & 0777);
is($mode, '700', 'supervise directory have conservative permissions');
+
+my $noreplace = 'debian/dh-runit-test/var/lib/runit/noreplace/test';
+ok(!-f $noreplace, 'noreplace file is correctly absent');
diff --git a/t/928935.t b/t/928935.t
new file mode 100644
index 000..e31756b
--- /dev/null
+++ b/t/928935.t
@@ -0,0 +1,10 @@
+#!/usr/bin/perl
+use strict;
+use warnings;
+use Test::More tests => 2;
+use T;
+
+system_ok('dh_runit', 'debian/test.runscript', 'name=test,noreplace');
+
+my $n
Bug#929063: init: delegate selinux operation to separate binary
Package: sysvinit
Severity: wishlist
Tags: patch
From 7f6242e5f3d893e90b3ed44fb09abe5983c2d49a Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Wed, 15 May 2019 12:10:13 +
Subject: [PATCH] init: delegate selinux operation to separate binary
Move selinux-related logic from /sbin/init into separate binary
(/sbin/selinux-check) by default. This way, /sbin/init is no longer
linked aganist libselinux (and its transitive dependencies).
If user need selinux initialization, she can install /sbin/selinux-check
separately.
---
src/Makefile| 8 +++
src/init.c | 51 +++--
src/init.h | 4
src/paths.h | 1 +
src/selinux-check.c | 21 +++
5 files changed, 61 insertions(+), 24 deletions(-)
create mode 100644 src/selinux-check.c
diff --git a/src/Makefile b/src/Makefile
index e54c051c..a23fbe38 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -23,7 +23,7 @@ MNTPOINT=
# For some known distributions we do not build all programs, otherwise we do.
BIN=
-SBIN = init halt shutdown runlevel killall5 fstab-decode logsave
+SBIN = init halt shutdown runlevel killall5 fstab-decode logsave
selinux-check
USRBIN = last mesg readbootlog
MAN1 = last.1 lastb.1 mesg.1 readbootlog.1
@@ -81,11 +81,9 @@ MANDIR = /usr/share/man
ifeq ($(WITH_SELINUX),yes)
SELINUX_DEF = -DWITH_SELINUX
- INITLIBS += -lsepol -lselinux
SULOGINLIBS = -lselinux
else
SELINUX_DEF =
- INITLIBS =
SULOGINLIBS =
endif
@@ -105,8 +103,10 @@ all: $(BIN) $(SBIN) $(USRBIN)
# $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LDLIBS)
#%.o: %.c
# $(CC) $(CFLAGS) $(CPPFLAGS) -c $^ -o $@
+#
+selinux-check: -lsepol -lselinux
-init: LDLIBS += $(INITLIBS) $(STATIC)
+init: LDLIBS += $(STATIC)
init: init.o init_utmp.o runlevellog.o
halt: LDLIBS += $(STATIC)
diff --git a/src/init.c b/src/init.c
index 4369beb9..58e098fa 100644
--- a/src/init.c
+++ b/src/init.c
@@ -64,9 +64,6 @@ Version information is not placed in the top-level Makefile
by default
#include
#include
-#ifdef WITH_SELINUX
-# include
-#endif
#ifdef __FreeBSD__
extern char **environ;
#endif
@@ -3012,6 +3009,35 @@ int telinit(char *progname, int argc, char **argv)
return 1;
}
+static
+void maybe_init_selinux(char **argv)
+{
+ int wstatus, ret;
+
+ if (getenv("SELINUX_INIT")) return; /* We were re-execed. */
+ if (access(SELINUX_CHECK, X_OK) != 0) return; /* Helper not installed */
+
+ if (fork() == 0) { /* child */
+ execl(SELINUX_CHECK, SELINUX_CHECK, NULL);
+ fprintf(stderr, "Failed to execute helper to init SELinux\n");
+ exit(SELINUX_CHECK_HALT);
+ }
+
+ /* parent */
+ wait();
+ ret = WIFEXITED(wstatus) ? WEXITSTATUS(wstatus) : SELINUX_CHECK_HALT;
+ switch (ret) {
+ case SELINUX_CHECK_CONTINUE: return;
+ case SELINUX_CHECK_REEXEC:
+ putenv("SELINUX_INIT=YES");
+ execv(myname, argv);
+ fprintf(stderr, "Failed to re-exec init\n");
+ /* fall through */
+ case SELINUX_CHECK_HALT:
+ default: exit(1);
+ }
+}
+
/*
* Main entry for init and telinit.
*/
@@ -3095,23 +3121,8 @@ int main(int argc, char **argv)
maxproclen += strlen(argv[f]) + 1;
}
-#ifdef WITH_SELINUX
- if (getenv("SELINUX_INIT") == NULL) {
- if (is_selinux_enabled() != 1) {
- if (selinux_init_load_policy() == 0) {
- putenv("SELINUX_INIT=YES");
- execv(myname, argv);
- } else {
- if (enforce > 0) {
- /* SELinux in enforcing mode but load_policy failed */
- /* At this point, we probably can't open /dev/console, so log()
won't work */
- fprintf(stderr,"Unable to load SELinux Policy. Machine is in
enforcing mode. Halting now.\n");
- exit(1);
- }
- }
- }
- }
-#endif
+ maybe_init_selinux(argv);
+
/* Start booting. */
argv0 = argv[0];
argv[1] = NULL;
diff --git a/src/init.h b/src/init.h
index 1b70d6d1..b9440e93 100644
--- a/src/init.h
+++ b/src/init.h
@@ -50,6 +50,10 @@
/* Default path inherited by every child. */
#define PATH_DEFAULT "/sbin:/usr/sbin:/bin:/usr/bin"
+/* Interface with SELINUX_CHECK */
+#define SELINUX_CHECK_CONTINUE 0
+#define SELINUX_CHECK_REEXEC 1
+#define SELINUX_CHECK_HALT 2
/* Prototypes. */
void write_utmp_wtmp(char *user, char *id, int pid, int type, char *line);
diff --git a/src/paths.h b/src/paths.h
index c9b82c1a..8230c8a9 100644
--- a/src/paths.h
+++ b/src/paths.h
@@ -38,6 +38,7 @@
#define PWRSTAT_OL
Bug#928969: stterm: incorrect rendering of cyrillic letters with Terminus
Package: stterm Version: 0.8.2-1 Severity: normal Dear Maintainer, cyrillic letters in stterm with Terminus font are rendered as more wide and overlapping than latin letters. On both "xterm" and under tty cyrillic letters are rendered properly. This issue is only with Terminus font: no other monospace font I checked have such problems. Please, try to reproduce it yourself. You will need: * xfonts-terminus * stterm * cyrillic text "Привет" Start stterm: $ stterm -f Terminus and view cyrillic text in that terminal. If you want, I can make screenshots. pgpNnbmKG2voB.pgp Description: PGP signature
Bug#624289: sysvinit-utils: bootlogd fails to start: ioctl TIOCGDEV: invalid argument
control: tags -1 +moreinfo [2011-04-27 09:24] arno renevier > Package: sysvinit-utils > Version: 2.88dsf-13.2 > Severity: normal > > Hi, > bootlogd fails to start. I investigated with printf-debug, and found that > ioctl(0, TIOCGDEV, ) fails and strerror(errno) is: "Invalid argument". > Also, when removing the ioctl stuff, consolename is correctly found. Why not > continue into the function even if ioctl fails ? > > Bootlogd worked fine until 13rd or 14th or 15th of april. And sysvinit-utils > was not upgraded at that time. So, the bug may come from another package. Sorry for late response. Can you reproduce issue on modern installations? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#440709: patch: mount securityfs when it is available (Closes: #440709)
control: tags 440709 +patch +pending
Here I refreshed patch:
From efedf38621a2a63fd193f1fa740c3a97ae8bee26 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Mon, 13 May 2019 15:18:41 +
Subject: [PATCH] Mount securityfs when it is available (Closes: #440709)
Thanks: Ritesh Raj Sarraf
---
debian/src/initscripts/etc/init.d/mountkernfs.sh | 4
debian/src/initscripts/etc/init.d/umountfs | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/debian/src/initscripts/etc/init.d/mountkernfs.sh
b/debian/src/initscripts/etc/init.d/mountkernfs.sh
index e95cac3a..8f2b20a8 100755
--- a/debian/src/initscripts/etc/init.d/mountkernfs.sh
+++ b/debian/src/initscripts/etc/init.d/mountkernfs.sh
@@ -34,6 +34,10 @@ mount_filesystems () {
#
domount "$MNTMODE" proc "" /proc proc "-onodev,noexec,nosuid"
+ if grep -E -qs "securityfs\$" /proc/filesystems ; then
+ domount securityfs "" /sys/kernel/security securityfs
+ fi
+
#
# Mount sysfs on /sys
#
diff --git a/debian/src/initscripts/etc/init.d/umountfs
b/debian/src/initscripts/etc/init.d/umountfs
index 633a3f6d..126e7aab 100755
--- a/debian/src/initscripts/etc/init.d/umountfs
+++ b/debian/src/initscripts/etc/init.d/umountfs
@@ -30,7 +30,7 @@ do_stop () {
;;
esac
case "$FSTYPE" in
- proc|procfs|linprocfs|sysfs|usbfs|usbdevfs|devpts)
+ proc|procfs|linprocfs|sysfs|securityfs|usbfs|usbdevfs|devpts)
continue
;;
tmpfs)
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
pgpANv2I0iCik.pgp
Description: PGP signature
Bug#403369: initscripts: boot messages not displayed on serial console with bootlogd enabled
control: tags -1 +unreproducible +moreinfo [2006-12-16 18:01] Paul Slootman > part text/plain1776 > Package: initscripts > Version: 2.86.ds1-14.1 > Severity: normal > > While configuring a Sun Netra T1 (which only has a serial console, no > graphics at all), I noticed that the boot messages from init scripts > stopped displaying when I enabled bootlogd. I get this (serial consoles > _are_ handy :-) : > > > [ 23.190733] EXT3-fs: mounted filesystem with ordered data mode. > [ 23.268793] VFS: Mounted root (ext3 filesystem) readonly. > INIT: version 2.86 booting > Starting boot logger: bootlogd[ 24.866020] Adding 2931760k swap on > /dev/md4. Priority:-1 extentsk > [...] Seems things changed for 13 years. I just set up virtual machine with following kernel options: console=tty0 console=ttyS0,9600n and runit with "kvm -serial file:serial". When it booted content of /var/log/boot in VM and "serial" on host was same -- both listed events up to openssh service. So, seems I need more information and guidance to debug this issue. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#927254: [Pkg-javascript-devel] Bug#927254: libjs-vue-router: ships node module instead of browser one
[2019-04-22 09:56] Dmitry Bogatov > > Provided files are not node-* ones but recompiled using rollup. Could > > you check if Laminar works well with > > https://unpkg.com/vue-router@3.0.2/dist/vue-router.js file ? (same > > version than in Buster) > > Yes, file from this URL is OK. Is it present in some Debian package? Any suggestions, what to do next? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#669406: patch: remove overly aggressive optimization from /etc/init.d/rc
control: tags 669406 +patch +pending
From 59a9444af50c2b922db6b28cf7bb4476acaba19d Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Tue, 14 May 2019 08:07:02 +
Subject: [PATCH] Remove overly aggressive optimization from /etc/init.d/rc
The optimization:
A start script is not run when the service was already
configured to run in the previous runlevel. A stop script is
not run when the the service was already configured not to run
in the previous runlevel.
assumes, that services are never started or stopped manually. It means,
that if service was started manually, but disabled in general, on
shutdown it will not be duly stoppend. This change remove such
optimization. (Closes: #669406)
---
debian/src/sysv-rc/rc | 48 ---
1 file changed, 48 deletions(-)
diff --git a/debian/src/sysv-rc/rc b/debian/src/sysv-rc/rc
index 025a1c54..3cf51dbb 100755
--- a/debian/src/sysv-rc/rc
+++ b/debian/src/sysv-rc/rc
@@ -4,11 +4,6 @@
#
# Starts/stops services on runlevel changes.
#
-# Optimization: A start script is not run when the service was already
-# configured to run in the previous runlevel. A stop script is not run
-# when the the service was already configured not to run in the previous
-# runlevel.
-#
# Authors:
# Miquel van Smoorenburg
# Bruce Perens
@@ -167,20 +162,6 @@ then
# Check if the script is there.
[ ! -f "$i" ] && continue
- #
- # Find stop script in previous runlevel but
- # no start script there.
- #
- suffix=${i#/etc/rc$runlevel.d/K[0-9][0-9]}
-
previous_stop=/etc/rc$previous.d/K[0-9][0-9]$suffix
-
previous_start=/etc/rc$previous.d/S[0-9][0-9]$suffix
- #
- # If there is a stop script in the previous
level
- # and _no_ start script there, we don't
- # have to re-stop the service.
- #
- [ -f $previous_stop ] && [ ! -f $previous_start
] && continue
-
# Stop the service.
SCRIPTS="$SCRIPTS $i"
done
@@ -214,35 +195,6 @@ then
do
[ ! -f "$i" ] && continue
- suffix=${i#/etc/rc$runlevel.d/S[0-9][0-9]}
- if [ "$previous" != N ]
- then
- #
- # Find start script in previous
runlevel and
- # stop script in this runlevel.
- #
-
stop=/etc/rc$runlevel.d/K[0-9][0-9]$suffix
-
previous_start=/etc/rc$previous.d/S[0-9][0-9]$suffix
- #
- # If there is a start script in the
previous level
- # and _no_ stop script in this level,
we don't
- # have to re-start the service.
- #
- if [ start = "$ACTION" ] ; then
- [ -f $previous_start ] && [ !
-f $stop ] && continue
- else
- # Workaround for the special
- # handling of runlevels 0 and 6.
-
previous_stop=/etc/rc$previous.d/K[0-9][0-9]$suffix
- #
- # If there is a stop script in
the previous level
- # and _no_ start script there,
we don't
- # have to re-stop the service.
- #
- [ -f $previous_stop ] && [ ! -f
$previous_start ] && continue
- fi
-
- fi
SCRIPTS="$SCRIPTS $i"
done
startup $ACTION $SCRIPTS
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
pgpzNaaAWALrs.pgp
Description: PGP signature
Bug#627797: patch: ensure mdadm starts before checkfs (Closes: #627797)
control: tags 627797 +patch +pending From 5de0dc682fc11e9bd10691638610955eec979571 Mon Sep 17 00:00:00 2001 From: Dmitry Bogatov Date: Mon, 13 May 2019 17:53:47 + Subject: [PATCH] Ensure mdadm starts before checkfs (Closes: #627797) --- debian/src/initscripts/etc/init.d/checkfs.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/src/initscripts/etc/init.d/checkfs.sh b/debian/src/initscripts/etc/init.d/checkfs.sh index 67929dec..738a7415 100755 --- a/debian/src/initscripts/etc/init.d/checkfs.sh +++ b/debian/src/initscripts/etc/init.d/checkfs.sh @@ -3,7 +3,7 @@ # Provides: checkfs # Required-Start:checkroot # Required-Stop: -# Should-Start: +# Should-Start: mdadm-raid # Default-Start: S # Default-Stop: # X-Interactive: true -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction -- pgp37ScxLyQuZ.pgp Description: PGP signature
Bug#926471: lintian/patch: check that daemons have init.d script
[2019-04-18 10:24] Dmitry Bogatov > Here is prelimitary patch, that implement the check. It seems to affect > t/tags/checks/init.d/init.d-lsb-depends-nonrel/ check, and, maybe, > something else -- I did not run whole test suite. Just a ping, to make sure that issue did not got lost. -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#928808: tracker.debian.org: automatic filing bugs
[2019-05-12 21:26] Raphael Hertzog > On Sat, 11 May 2019, Dmitry Bogatov wrote: > > would it be possible to automatically file bugs with issues, already > > detected by tracker? > > Right now, there's no email notification and I certainly agree > that there should be some email notification about new upstream releases. > Wouldn't that be sufficient? Do you really want a bug filed? Sure, I want. When I feel like working on Debian, I open BTS to see bugs aganist my packages. > > Question is access-control. Probably, only maintainer/uploader of > > package can make decision, whether bugs should be auto-reported. > > I see it as something like this: > > While we have a mailbot, I see it mainly as legacy, the control interface > for such a feature would likely be on the web interface. Sad. At least, I hope it will be possible to enable this from script with "curl". -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#928970: RFP: jj - FIFO-based jabber client
Package: wnpp Severity: wishlist Homepage: https://23.fi/jj jj is simple FIFO and filsystem-based Jabber client. It was inspired by "ii" IRC client. pgpYfW6PXCXHP.pgp Description: PGP signature
Bug#390067: initscripts: SELinux and log saving in /etc/init.d/check*.sh
control: severity -1 wishlist control: tags -1 +moreinfo [2006-09-29 02:52] Erich Schubert > For SELinux domain transition purposes, it would be good to have the > logsave invocations split out from the init scripts into separate > scripts (that may even boil down to something like this:) > --- > #!/bin/sh > FSCK_LOGFILE=$(shift) > exec logsave -s $FSCK_LOGFILE fsck "$@" > --- > [...] Today, as 13 years ago we need patches. Or, at least, someone who are willing to test what I can write based on provided description: I am not selinux user. Dear submitter, are you still interested in this feature? -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#928810: patch: Make debian-watch-uses-insecure-uri more generic
[2019-05-11 16:08] Jelmer Vernooij
> On Sat, May 11, 2019 at 02:49:11PM +0000, Dmitry Bogatov wrote:
> > From 2789fed85a6088c85f8f37ba96984eb7f3d8e8ef Mon Sep 17 00:00:00 2001
> > From: Dmitry Bogatov
> > Date: Fri, 10 May 2019 23:32:01 +
> > Subject: [PATCH] Make debian-watch-uses-insecure-uri more generic
> >
> > Instead of using hard-coded list of hosts, that are known to support
> > https new implementation just replace "http://; with "https://; and
> > makes sure, that uscan report is same.
> Does lintian-brush still build successfully under e.g. sbuild with this patch?
> I suspect that this makes the test for debian-watch-uses-insecure-uri fail
> because it now needs internet access.
Good catch. What do you want me to do about it?
By the way, how does it come that "homepage-uses-insecure-uri" does not
fail in sbuild?
> This also seems to unconditionally run uscan, regardless of whether
> there are any http: URLs in debian/watch, slowing down lintian-brush
> in situations when there's nothing to fix. Could you perhaps grep for
> http: first?
Good idea.
From f1a994eae7b81f208a6973af4249918b87bd26ea Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Fri, 10 May 2019 23:32:01 +
Subject: [PATCH] Make debian-watch-uses-insecure-uri more generic
Instead of using hard-coded list of hosts, that are known to support
https new implementation just replace "http://; with "https://; and
makes sure, that uscan report is same.
---
fixers/debian-watch-uses-insecure-uri.sh | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/fixers/debian-watch-uses-insecure-uri.sh
b/fixers/debian-watch-uses-insecure-uri.sh
index 85136b8..66c9dad 100755
--- a/fixers/debian-watch-uses-insecure-uri.sh
+++ b/fixers/debian-watch-uses-insecure-uri.sh
@@ -1,6 +1,20 @@
#!/bin/sh
-perl -p -i -e
's/http:\/\/code.launchpad.net\//https:\/\/code.launchpad.net\//' debian/watch
-perl -p -i -e 's/http:\/\/launchpad.net\//https:\/\/launchpad.net\//'
debian/watch
-perl -p -i -e 's/http:\/\/ftp.gnu.org\//https:\/\/ftp.gnu.org\//' debian/watch
+test -r debian/watch|| exit 0
+grep 'http://' debian/watch || exit 0
+
+before=$(mktemp)
+after=$(mktemp)
+uscan --dehs > "${before}" 2>&1
+sed -i.bak s,http://,https://,g debian/watch
+uscan --dehs > "${after}" 2>&1
+
+# Make sure that reports are same up to http/https substitution in URL.
+sed -i s,http://,https://,g "${before}" "${after}"
+if cmp -s "${before}" "${after}" ; then
+ rm -f debian/watch.bak
+else
+ mv debian/watch.bak debian/watch
+fi
+rm -f "${before}" "${after}"
echo "Use secure URI in debian/watch."
echo "Fixed-Lintian-Tags: debian-watch-uses-insecure-uri"
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
Bug#928811: patch: New fixer: patch-file-present-but-not-mentioned-in-series.sh
[2019-05-11 15:56] Jelmer Vernooij
> Thanks! Makes sense.
>
> Any chance you could add a test case for this under
> tests/patch-file-present-but-not-mentioned-in-series/?
Sure.
From 6e795731f4ae266954acf9de70ace6f0ea4e944c Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Sat, 11 May 2019 14:46:44 +
Subject: [PATCH] New fixer: patch-file-present-but-not-mentioned-in-series.sh
Make sure that debian/patches contain only patches, mentioned in series
file.
---
fixers/index.desc | 3 +++
.../patch-file-present-but-not-mentioned-in-series.sh | 10 ++
.../have-patches/in/debian/patches/one | 0
.../have-patches/in/debian/patches/series | 2 ++
.../have-patches/in/debian/patches/three | 0
.../have-patches/in/debian/patches/two | 0
.../have-patches/message | 2 ++
.../have-patches/out/debian/patches/one| 0
.../have-patches/out/debian/patches/series | 2 ++
.../have-patches/out/debian/patches/two| 0
.../no-patches/in/debian/control | 0
.../no-patches/out | 1 +
12 files changed, 20 insertions(+)
create mode 100755 fixers/patch-file-present-but-not-mentioned-in-series.sh
create mode 100644
tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/one
create mode 100644
tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/series
create mode 100644
tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/three
create mode 100644
tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/two
create mode 100644
tests/patch-file-present-but-not-mentioned-in-series/have-patches/message
create mode 100644
tests/patch-file-present-but-not-mentioned-in-series/have-patches/out/debian/patches/one
create mode 100644
tests/patch-file-present-but-not-mentioned-in-series/have-patches/out/debian/patches/series
create mode 100644
tests/patch-file-present-but-not-mentioned-in-series/have-patches/out/debian/patches/two
create mode 100644
tests/patch-file-present-but-not-mentioned-in-series/no-patches/in/debian/control
create mode 12
tests/patch-file-present-but-not-mentioned-in-series/no-patches/out
diff --git a/fixers/index.desc b/fixers/index.desc
index 735179f..058889c 100644
--- a/fixers/index.desc
+++ b/fixers/index.desc
@@ -120,6 +120,9 @@ Lintian-Tags:
package-uses-deprecated-debhelper-compat-version,
package-uses-old-debhelper-compat-version
+Fix-Script: patch-file-present-but-not-mentioned-in-series.sh
+Lintian-Tags: patch-file-present-but-not-mentioned-in-series
+
Fix-Script: possible-missing-colon-in-closes.sh
Lintian-Tags: possible-missing-colon-in-closes
diff --git a/fixers/patch-file-present-but-not-mentioned-in-series.sh
b/fixers/patch-file-present-but-not-mentioned-in-series.sh
new file mode 100755
index 000..66ff555
--- /dev/null
+++ b/fixers/patch-file-present-but-not-mentioned-in-series.sh
@@ -0,0 +1,10 @@
+#!/bin/sh -eu
+test -r debian/patches/series || exit 0
+cd debian/patches
+
+for f in * ; do
+ test "${f}" != series || continue
+ grep -q -- "${f}" series || rm "${f}"
+done
+echo "Remove patches missing from debian/patches/series."
+echo "Fixed-Lintian-Tags: patch-file-present-but-not-mentioned-in-series"
diff --git
a/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/one
b/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/one
new file mode 100644
index 000..e69de29
diff --git
a/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/series
b/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/series
new file mode 100644
index 000..814f4a4
--- /dev/null
+++
b/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/series
@@ -0,0 +1,2 @@
+one
+two
diff --git
a/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/three
b/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/three
new file mode 100644
index 000..e69de29
diff --git
a/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/two
b/tests/patch-file-present-but-not-mentioned-in-series/have-patches/in/debian/patches/two
new file mode 100644
index 000..e69de29
diff --git
a/tests/patch-file-present-but-not-mentioned-in-series/have-patches/message
b/tests/patch-file-present-but-not-mentioned-in-series/have-patches/message
new file mode 100644
index 000..2281c60
--- /dev/null
+++ b/tests/patch-file-present-but-not-mentioned-in-series/have-patches/message
@@ -0,0 +1,2 @@
+Remove patches missing from
Bug#928918: hurd: taking over /etc/hurd/runsystem.sysv
Package: hurd Severity: normal Affects: initscripts Blocks: 922962 Dear Maintainer, bin:initscripts ships /etc/hurd/runsystem.sysv file on hurd architecture, thus making bin:initscript arch:any, which is quite unfortunate, given that both "/etc/hurd/runsystem.sysv" and rest of bin:initscript are shell scripts. Please copy this file into bin:hurd and provide apporiate Replaces. pgpicL_W7Y9MQ.pgp Description: PGP signature
Bug#928394: RFS: freetype-py/2.1.0.post1-1 [ITP]
[2019-05-09 22:35] Bastian Germann > I have changed that and also made the smoke test run. Fine. Uploaded. I also suggest you to use Gitlab CI. See here: https://salsa.debian.org/salsa-ci-team/pipeline/ -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction --
Bug#928920: patch: Introduce logging functions that check ${VERBOSE}
Package: lsb-base
Severity: wishlist
Tags: patch
From 58dd6e6add24a4e5531a84ff2404f2f5ed71e114 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov
Date: Sat, 11 May 2019 21:20:48 +
Subject: [PATCH] Introduce logging functions that check ${VERBOSE}
Use of logging functions in initscripts are often conditioned on value
of $VERBOSE variable, causing same code to be repeated over and over
again.
This change introduce number of logging functions (with prefix "v") that
are functionally equivalent to their counterparts without prefix when
value of $VERBOSE is not "no", and do nothing if value of $VERBOSE is "no".
---
conf/conf.yaml| 7 +++
debian/control| 1 +
debian/lsb-base.install | 1 +
debian/rules | 4
init-functions.d/.gitignore | 1 +
init-functions.d/00-verbose.jinja | 9 +
6 files changed, 23 insertions(+)
create mode 100644 conf/conf.yaml
create mode 100644 init-functions.d/.gitignore
create mode 100644 init-functions.d/00-verbose.jinja
diff --git a/conf/conf.yaml b/conf/conf.yaml
new file mode 100644
index 000..d1ac18b
--- /dev/null
+++ b/conf/conf.yaml
@@ -0,0 +1,7 @@
+log_functions:
+ - log_daemon_msg
+ - log_begin_msg
+ - log_end_msg
+ - log_action_msg
+ - log_action_begin_msg
+ - log_action_end_msg
diff --git a/debian/control b/debian/control
index b39cdc6..e4746d2 100644
--- a/debian/control
+++ b/debian/control
@@ -9,6 +9,7 @@ Build-Depends: debhelper (>> 11~),
python3-all:any,
dh-python,
distro-info-data,
+ ionit
Standards-Version: 4.2.1
Homepage: https://wiki.linuxfoundation.org/lsb/start
Vcs-Browser: https://salsa.debian.org/debian/lsb
diff --git a/debian/lsb-base.install b/debian/lsb-base.install
index 66dc0df..d2d9588 100644
--- a/debian/lsb-base.install
+++ b/debian/lsb-base.install
@@ -1,2 +1,3 @@
init-functions /lib/lsb
+init-functions.d/00-verbose /lib/lsb/init-functions.d
init-functions.d/20-left-info-blocks /lib/lsb/init-functions.d
diff --git a/debian/rules b/debian/rules
index 33c4aff..32789c5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,6 +8,10 @@ PY3VERSIONS=$(shell [ -x /usr/bin/py3versions ] && py3versions
-vr)
%:
dh $@ --with python3
+override_dh_auto_build:
+ dh_auto_build
+ ionit -c conf -t init-functions.d
+
# These are used for cross-compiling and for saving the configure script
# from having to guess our platform (since we know it already)
DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
diff --git a/init-functions.d/.gitignore b/init-functions.d/.gitignore
new file mode 100644
index 000..876584d
--- /dev/null
+++ b/init-functions.d/.gitignore
@@ -0,0 +1 @@
+00-verbose
diff --git a/init-functions.d/00-verbose.jinja
b/init-functions.d/00-verbose.jinja
new file mode 100644
index 000..15916aa
--- /dev/null
+++ b/init-functions.d/00-verbose.jinja
@@ -0,0 +1,9 @@
+## Generated automatically. Do not edit! -*- shell-script -*-
+{% for fn in log_functions %}
+v{{ fn }} () {
+ if test "${VERBOSE:-yes}" != no ; then
+ {{ fn }} "$@"
+ fi
+}
+{% endfor %}
+# vim: ft=sh
--
Note, that I send and fetch email in batch, once every 24 hours.
If matter is urgent, try https://t.me/kaction
--
pgp2KJ8ql_M2p.pgp
Description: PGP signature
Bug#928921: reprotest: kernel too old SIGSEGV
Package: reprotest Version: 0.7.8 Severity: normal Hello. I am working on setting up CI for my packages, and one of them fail "reprotest" phase with error: "FATAL: kernel too old"[1][2]. I grepped upstream sources for "kernel too old" message and found nothing. Regular build is successful. Any suggestions, what may be wrong and how to fix it? On another package I get "bad system call" error[2]. [^1] https://salsa.debian.org/debian/bglibs/-/jobs/170367 [^2] https://salsa.debian.org/debian/bcron/-/jobs/170195 [^3] https://salsa.debian.org/debian/gdbm/-/jobs/170585 -- Note, that I send and fetch email in batch, once every 24 hours. If matter is urgent, try https://t.me/kaction -- pgpY_nC7exCk5.pgp Description: PGP signature
Bug#928922: devscripts: make debrepro use debuild
Package: devscripts Version: 2.19.4 Severity: wishlist Dear Maintainer, please consider using "debuild" instead of "dpkg-buildpackage" in "debrepro" script to avoid spurious failures in unsual environments (effectful environment variables, unexpected binaries in PATH, ...) Alternatively (not that it is best route), document that "debrepro" uses "dpkg-buildpackage" and user is responsible for environment sanititization. pgpd2Y9xV4OUz.pgp Description: PGP signature
