Bug#1077987: undertime: example config file not shipped by debian package
On 2024-08-10 15:07, Antoine Beaupré wrote: On 2024-08-05 10:35:55, Gabriel Filion wrote: The manpage for undertime(1) mentions toward the end of the document that there should be an example configuration file in /usr/share/doc/undertime/examples/undertime.yml However, I don't see this file in that directory. It's probably just an oversight that's easy to fix. Also, there's a config file in /etc/undertime.yml so it's rather a minor issue that the example file is not present since we can always take the system-wide file as an example.. Uh! Interesting. I wonder: in your opinion, should i just fix the manpage to stop pointing at the example file? Or should i not ship the system-wide file and ship it as an example instead? hmm great question.. if the example file would be the exact same as the global config, I guess that it doesnt' add much the default config is a good example, and I like that truncate is enabled by default. so I think that the default config file is serving its purpose. it's good to have pointers in the man page to example configs though
Bug#611615: puppetmaster logrotate script conflicts with puppet's one
Package: puppetmaster Version: 2.6.2-4 Severity: normal puppetmaster installs a logrotate file that defines a rule for /var/log/puppet/masterhttp.log however, the puppet package installs a file, too, in which rules are set for /varl/log/puppet/*.log. This creates a conflict and logrotate exits with the following error: /etc/cron.daily/logrotate: error: puppetmaster:1 duplicate log entry for /var/log/puppet/masterhttp.log error: found error in /var/log/puppet/masterhttp.log , skipping Also, the logrotate script installed by 'puppet' already restarts puppetmaster. -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-openvz-686 (SMP w/1 CPU core) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages puppetmaster depends on: ii facter 1.5.7-3 a library for retrieving facts fro ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip ii puppet-common2.6.2-4 Centralized configuration manageme ii ruby1.8 1.8.7.302-2 Interpreter of object-oriented scr Versions of packages puppetmaster recommends: ii libldap-ruby1.8 0.9.7-1.1 OpenLDAP library binding for Ruby ii rails 2.3.5-1.2 MVC ruby based framework geared fo ii ruby [rdoc] 4.5An interpreter of object-oriented Versions of packages puppetmaster suggests: pn apache2 | nginx(no description available) ii libactiverecord-ruby1.8 2.3.5-1.2 ORM database interface for ruby pn libapache2-mod-passenger (no description available) ii libmysql-ruby1.8 2.8.2-1MySQL module for Ruby 1.8 ii librack-ruby 1.1.0-4A modular Ruby webserver interface pn libstomp-ruby1.8 (no description available) pn mongrel(no description available) pn puppet-el (no description available) pn stompserver(no description available) ii vim-puppet2.6.2-4syntax highlighting for puppet man -- Configuration Files: /etc/logrotate.d/puppetmaster [Errno 2] No such file or directory: u'/etc/logrotate.d/puppetmaster' /etc/puppet/fileserver.conf changed [not included] -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#922395: smokeping: fails to stop and to upgrade: start-stop-daemon: matching only on non-root pidfile /var/run/smokeping/smokeping.pid is insecure
Hello, On 2019-02-15 7:53 a.m., Axel Beckert wrote: > sorry for the late report, but smokeping failed to configure (probably > after the recent upgrade) for a few days for me now: > > # dpkg --configure -a > Setting up smokeping (2.7.3-1) ... > apache2_invoke: Enable module cgi > [ ok ] Restarting Apache httpd web server: apache2 > apache2_invoke smokeping: already enabled > [ ok ] Reloading Apache httpd web server: apache2. > [] Shutting down latency logger daemon: smokepingstart-stop-daemon: > matching only on non-root pidfile /var/run/smokeping/smokeping.pid is insecure > This seems to happen since dpkg 1.19.3. According changelog entry: Thanks for bringing this to our attention! dpkg 1.19.3 was migrated to testing only a couple days before smokeping 2.7.3-1, so maybe when Antoine and I were working on this release our tests were running on a previous dpkg version: I've tested out an install of smokeping on a fresh install with the init script but I didn't notice any error about the pid. I'll run more tests to try and reproduce this. signature.asc Description: OpenPGP digital signature
Bug#922395: smokeping: fails to stop and to upgrade: start-stop-daemon: matching only on non-root pidfile /var/run/smokeping/smokeping.pid is insecure
On 2019-02-15 10:33 p.m., Gabriel Filion wrote: > On 2019-02-15 7:53 a.m., Axel Beckert wrote: >> sorry for the late report, but smokeping failed to configure (probably >> after the recent upgrade) for a few days for me now: >> >> # dpkg --configure -a >> Setting up smokeping (2.7.3-1) ... >> apache2_invoke: Enable module cgi >> [ ok ] Restarting Apache httpd web server: apache2 >> apache2_invoke smokeping: already enabled >> [ ok ] Reloading Apache httpd web server: apache2. >> [] Shutting down latency logger daemon: smokepingstart-stop-daemon: >> matching only on non-root pidfile /var/run/smokeping/smokeping.pid is >> insecure > >> This seems to happen since dpkg 1.19.3. According changelog entry: > > Thanks for bringing this to our attention! > > dpkg 1.19.3 was migrated to testing only a couple days before smokeping > 2.7.3-1, so maybe when Antoine and I were working on this release our > tests were running on a previous dpkg version: I've tested out an > install of smokeping on a fresh install with the init script but I > didn't notice any error about the pid. > > I'll run more tests to try and reproduce this. I was able to reproduce this bug by switching an amd64 debian sid VM to boot using sysvinit, and then to run "dpkg-reconfigure smokeping" when using the systemd unit, the pid file is owned by root:root and we're not encountering this issue. I've found an example for a fix in #920466 that worked for me: adding "--exec $DAEMON" to the s-s-d command that stops the daemon makes it possible to stop the daemon without error. I'll push this fix to salsa and ask for Antoine to review and upload. signature.asc Description: OpenPGP digital signature
Bug#681714: smokeping - off-by-one error on graph time axis
Hi James, I'm sorry to be reviving such an old report. I'm current helping out with maintenance of this package and I'm trying to clear out as many bugs as possible. On Sun, 15 Jul 2012 13:57:31 -0600 ja...@nurealm.net wrote: > The chart data seem to be displayed "off-by-one", with the most recent 5min > measurement shown covering the earlier 10min to earlier 5min time period, and > with the most recent time period shown blank, when using 5min updates. The > data is shown 5min earlier than the actual time. > > This is especially a problem when setting-up smokeping "targets" for the first > time and wondering if new configuration is correct and working, where it may > appear that no measurement was made or recorded for the current time period. I believe the behavior you mentioned is normal. since measurements are done only every once in a while, the most recent period is almost always empty. so once you do get results on the graph, it means that it was already measured and it's not necessarily what is happening right now. Tell me if I misunderstood your inquiry. I will close this bug report in one week if I get no response. Cheers! signature.asc Description: OpenPGP digital signature
Bug#825526: smokeping: deletes files in /etc/smokeping
Hi there, On Fri, 27 May 2016 14:07:00 +0200 Francesco =?utf-8?Q?Potort=C3=AC?= wrote: > Package: smokeping > Version: 2.6.11-3 > Severity: normal > > I keep an "apache2.conf" file in /etc/smokeping, which is my backup of > my personalised /etc/apache2/smokeping.conf. > > When smokeping got updated, it deleted that file. > > I think it should not. From what I know, the apache2 config file is considered as a config file for the smokeping package. as an example, this is how I see this in buster: # cat /var/lib/dpkg/info/smokeping.conffiles | grep apache2 /etc/apache2/conf-available/smokeping.conf if I were to venture a guess about what hapened here is that dpkg may have asked if this file should be overwritten during upgrade. if the upgrade was run in a non-interactive way, it's possible that this question was hushed or pre-answered in a way. what you could try in order to avoid having your config file get overwritten is you could use dpkg-divert(1) to add a divert rule for the file. This way the package will not overwrite it. cheers! signature.asc Description: OpenPGP digital signature
Bug#892908: puppet 5 is now builtin to puppet since 4.9
Package: puppet Version: 5.4.0-1 Severity: minor Hello, Hiera version 5 is now built into puppet. It's been so since 4.9 ref: https://docs.puppet.com/hiera/#note-weve-released-a-major-update-to-hiera-called-hiera-5 It's now possible to perform a hiera lookup with: puppet lookup key_name [options...] this works well with the current packaged puppet binary. I'm just curious whether the package's dependency on the hiera package is still needed. hiera 3.x (as distributed by the hiera package) is still maintained but I'm wondering if we require it with newer puppet installs. I haven't made any sort of test yet. I guess to test this, we'd need a puppet package without the dependency on hiera installed on a host without hiera, then check that lookups are still working regardless of the tool's absence. If tests are successful then I believe we could simply drop the dependency to hiera from the puppet package. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages puppet depends on: ii adduser 3.117 ii facter 3.10.0-3 ii hiera3.2.0-2 ii init-system-helpers 1.51 ii lsb-base 9.20170808 ii ruby 1:2.5.0 ii ruby-augeas 1:0.5.0-3+b5 ii ruby-deep-merge 1.1.1-1 ii ruby-shadow 2.5.0-1 Versions of packages puppet recommends: ii debconf-utils 1.5.66 ii lsb-release9.20170808 ii ruby-selinux 2.7-2+b1 Versions of packages puppet suggests: pn ruby-hocon pn ruby-rrd -- no debconf information
Bug#911849: iptables: new version breaks firewall loading
Hi there, I just wanted to word in here that I hit exactly this bug where nothing was working anymore (read: no firewall rules at all anymore), and after being pointed to this ticket by folks in #debian-next I've upgraded to 1.8.1-2 and now I have a firewall again. thanks! signature.asc Description: OpenPGP digital signature
Bug#759487: smokeping: reporting a bug tries to include private data into the bug report
Hello, I've taken a look at this issue and I believe that in theory the file "smokeping_secrets" should not be managed by the package as a config file at all. ...however while trying to patch the package for this, I relized the following: * smokeing absolutely *wants* to have "secrets=" defined * the file pointed to by "secrets=" *must* exist * setting "secrets=/dev/null" (this would arguably be a very ugly hack) does not work: smokeping wants a plain file so we're stuck here. if we want the default configuration to work and have a functional service right after install, we need to deploy the file and point configuration to it. ... maybe something that could work would be to touch the file from postinst, but I'm not yet convinced this is so great. signature.asc Description: OpenPGP digital signature
Bug#923087: gbp-dch: fails to enumerate commits when log.showSignature is true in git config
Package: git-buildpackage Version: 0.9.13 Severity: normal Hi, I'm having difficulty running gbp dch. I get the following output (with --verbose set): pkg-smokeping$ gbp dch --verbose gbp:debug: ['git', 'rev-parse', '--show-cdup'] gbp:debug: ['git', 'rev-parse', '--is-bare-repository'] gbp:debug: ['git', 'rev-parse', '--git-dir'] gbp:debug: ['git', 'symbolic-ref', 'HEAD'] gbp:debug: ['git', 'show-ref', 'refs/heads/master'] gbp:debug: ['git', 'tag', '-l', 'debian/2.7.3-2'] gbp:debug: ['git', 'tag', '-l', 'debian/2.7.3-2'] gbp:debug: ['git', 'log', '--pretty=format:%H', '-1', '--', 'debian/changelog'] gbp:info: Changelog last touched at 'gpg: Signature made Fri 01 Feb 2019 03:56:19 PM EST' gbp:debug: ['git', 'log', '--pretty=format:%H', 'gpg: Signature made Fri 01 Feb 2019 03:56:19 PM EST..HEAD', '--no-merges', '--'] fatal: bad revision 'gpg: Signature made Fri 01 Feb 2019 03:56:19 PM EST..HEAD' gbp:error: Error getting commits gpg: Signature made Fri 01 Feb 2019 03:56:19 PM EST..HEAD It's trying to get a commit that is actually a PGP signature. I have found that this is caused by the fact that I have configured git to always show PGP signatures. In order to replicate, you can configure this option with: git config log.showSignature true If this option is disabled, then gbp dch works correctly. I believe that a simple fix for this issue would be to force-disable the option when calling git log: simply adding --no-show-signature to the arguments should do the trick. This way, gbp dch would avoid receiving the unexpected PGP signature output. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages git-buildpackage depends on: ii devscripts 2.19.2 ii git1:2.20.1-2 ii man-db 2.8.5-2 ii python33.7.2-1 ii python3-dateutil 2.7.3-3 ii python3-pkg-resources 40.8.0-1 ii sensible-utils 0.0.12 Versions of packages git-buildpackage recommends: ii cowbuilder0.88 ii pbuilder 0.230.1 ii pristine-tar 1.46 ii python3-requests 2.21.0-1 ii sbuild0.78.1-1 Versions of packages git-buildpackage suggests: ii python3-notify2 0.3-3 ii sudo 1.8.27-1 ii unzip6.0-22 -- no debconf information
Bug#923087: gbp-dch: fails to enumerate commits when log.showSignature is true in git config
I've formatted a patch for upstream that fixes this behaviour. See file
attached
From 42582015feef85b760932c05e802e2f65418a19c Mon Sep 17 00:00:00 2001
From: Gabriel Filion
Date: Sat, 23 Feb 2019 20:03:41 -0500
Subject: [PATCH] Disable PGP signatures when retrieving list of commits
gbp dch errors out with the following output if the "log.showSignature"
git config is enabled:
$ gbp dch --verbose
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: ['git', 'rev-parse', '--git-dir']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/master']
gbp:debug: ['git', 'tag', '-l', 'debian/2.7.3-2']
gbp:debug: ['git', 'tag', '-l', 'debian/2.7.3-2']
gbp:debug: ['git', 'log', '--pretty=format:%H', '-1', '--', 'debian/changelog']
gbp:info: Changelog last touched at 'gpg: Signature made Fri 01 Feb 2019 03:56:19 PM EST'
gbp:debug: ['git', 'log', '--pretty=format:%H', 'gpg: Signature made Fri 01 Feb 2019 03:56:19 PM EST..HEAD', '--no-merges', '--']
fatal: bad revision 'gpg: Signature made Fri 01 Feb 2019 03:56:19 PM EST..HEAD'
gbp:error: Error getting commits gpg: Signature made Fri 01 Feb 2019 03:56:19 PM EST..HEAD
This is caused by gbp dch receiving unexpected output for the PGP
signatures and trying to use this unexpected output.
To avoid any surprises, let's disable signatures being output when we
list commits.
Also, when collecting a shortlog-like output from commit objects, the
same unexpected PGP signature output is sprayed all over the changelog.
We'll avoid this by also disable showing signatures when showing each
commit's first line.
---
gbp/git/repository.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gbp/git/repository.py b/gbp/git/repository.py
index a44c71e1..dfc8e556 100644
--- a/gbp/git/repository.py
+++ b/gbp/git/repository.py
@@ -1613,7 +1613,7 @@ class GitRepository(object):
merge commit
@type first_parent: C{bool}
"""
-args = GitArgs('--pretty=format:%H')
+args = GitArgs('--pretty=format:%H', '--no-show-signature')
args.add_true(num, '-%d' % num)
args.add_true(first_parent, '--first-parent')
if since:
@@ -1694,7 +1694,7 @@ class GitRepository(object):
commit_sha1 = self.rev_parse("%s^0" % commitish)
args = GitArgs('--pretty=format:%an%x00%ae%x00%ad%x00%cn%x00%ce%x00%cd%x00%s%x00%f%x00%b%x00',
'-z', '--date=raw', '--no-renames', '--name-status',
- commit_sha1)
+ '--no-show-signature', commit_sha1)
out, err, ret = self._git_inout('show', args.args)
if ret:
raise GitRepositoryError("Unable to retrieve commit info for %s"
--
2.20.1
signature.asc
Description: OpenPGP digital signature
Bug#923087: [git-buildpackage/master] Disable PGP signatures when retrieving list of commits
tag 923087 pending thanks Date: Sat Feb 23 20:03:41 2019 -0500 Author: Gabriel Filion Commit ID: 34b9da1de902be0f4e43fd99d0fcb7e278bedbd9 Commit URL: https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=34b9da1de902be0f4e43fd99d0fcb7e278bedbd9 Patch URL: https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=34b9da1de902be0f4e43fd99d0fcb7e278bedbd9 Disable PGP signatures when retrieving list of commits gbp dch errors out with the following output if the "log.showSignature" git config is enabled: $ gbp dch --verbose gbp:debug: ['git', 'rev-parse', '--show-cdup'] gbp:debug: ['git', 'rev-parse', '--is-bare-repository'] gbp:debug: ['git', 'rev-parse', '--git-dir'] gbp:debug: ['git', 'symbolic-ref', 'HEAD'] gbp:debug: ['git', 'show-ref', 'refs/heads/master'] gbp:debug: ['git', 'tag', '-l', 'debian/2.7.3-2'] gbp:debug: ['git', 'tag', '-l', 'debian/2.7.3-2'] gbp:debug: ['git', 'log', '--pretty=format:%H', '-1', '--', 'debian/changelog'] gbp:info: Changelog last touched at 'gpg: Signature made Fri 01 Feb 2019 03:56:19 PM EST' gbp:debug: ['git', 'log', '--pretty=format:%H', 'gpg: Signature made Fri 01 Feb 2019 03:56:19 PM EST..HEAD', '--no-merges', '--'] fatal: bad revision 'gpg: Signature made Fri 01 Feb 2019 03:56:19 PM EST..HEAD' gbp:error: Error getting commits gpg: Signature made Fri 01 Feb 2019 03:56:19 PM EST..HEAD This is caused by gbp dch receiving unexpected output for the PGP signatures and trying to use this unexpected output. To avoid any surprises, let's disable signatures being output when we list commits. Also, when collecting a shortlog-like output from commit objects, the same unexpected PGP signature output is sprayed all over the changelog. We'll avoid this by also disable showing signatures when showing each commit's first line. Closes: #923087
Bug#925444: smokeping: --pid-dir doesn't worj as expected
Hello, On 2019-03-26 3:26 p.m., BERTRAND Joël wrote: >> Did you recently upgrade smokeping? if so what version were you >> using before? (maybe check your dpkg logs for signs of upgrade of >> the smokeping package) > Yes, I have. > > -> 2019-03-17 03:26:38 upgrade smokeping:all 2.7.2-3 2.7.3-2 Up to now I wasn't able to reproduce the bug. I'll soon try to do the same upgrade to see if there's an issue during that process. But since the problem affects an upgrade from one version that was previously only in testing/sid to a version that is currently in testing, I don't think this bug should be marked as grave (e.g. automatically marking this package for renewal) If the upgrade process from stretch to buster was affected, I would agree that an RC bug would be necessary. Now, that being said, I'll still continue trying to reproduce your bug soon so that if something can help out with upgrades I could maybe add this bit to the package. signature.asc Description: OpenPGP digital signature
Bug#926689: cryptsetup-initramfs: config lines in grub.cfg for cryptodisk/luks and other modules missing
Package: cryptsetup Version: 2:2.1.0-2 Severity: grave Justification: renders package unusable Hello, I've rebooted my computer this morning and the password prompt to unlock the crypto device would not appear before grub would search for the lvm device inside. This means that the system was not booting and I was getting dropped in the grub rescue prompt. The only way that I could bring the system back was by using the "Rescue mode" with the debian stretch installer. I have all files, including /boot, in one partition, and I use grub to unlock the crypto in order for it to find kernel and boot options. If this seems like a case that wouldn't affect most users, please don't hesitate to demote the severity. I found out that some configuration lines are missing in all options that get generated inside grub.cfg. Here's a diff between the grub configuration that was generated while in rescue mode (in a chroot inside the device that gets used for / ) vs. generated while the system is running: -8<8<8<--- $ diff -burN ~/grub.cfg /boot/grub/grub.cfg --- /home/gabster/grub.cfg 2019-04-08 19:20:24.000726392 -0400 +++ /boot/grub/grub.cfg 2019-04-08 19:37:00.360714287 -0400 @@ -58,15 +58,8 @@ if [ x$feature_default_font_path = xy ] ; then font=unicode else -insmod part_msdos -insmod cryptodisk -insmod luks -insmod gcry_rijndael -insmod gcry_rijndael -insmod gcry_sha256 insmod lvm insmod ext2 -cryptomount -u f100e85eb832489a9e97f1a9661a0c45 set root='lvmid/RfBQnU-gtRN-m55o-zwRA-L433-esRb-UpOa0w/lEtX5E-aBNo-0ngD-TwvX-3qrY-OxNF-DaG8T4' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint='lvmid/RfBQnU-gtRN-m55o-zwRA-L433-esRb-UpOa0w/lEtX5E-aBNo-0ngD-TwvX-3qrY-OxNF-DaG8T4' f8c6cb03-667e-46fc-b531-eb30a2558d74 @@ -81,7 +74,7 @@ load_video insmod gfxterm set locale_dir=$prefix/locale - set lang=C + set lang=en_CA insmod gettext fi terminal_output gfxterm ->8>8>8--- (I've abbreviated the diff since all the rest is just repetition of missing "insmod" and "cryptomount" lines for all options. for some reason those lines are not added when running the system after decrypting the disk properly, but they are present when the grub.conf file is generated in the chroot in rescue mode. since the same versions of software are used in both cases, I can only presume that something is different in the mounts currently available, or some other kernel setting that might differ.. Heres a listing of mounts (which are mostly things that come from the kernel -- you can also see the debian stretch usb key that saved me :P ) -8<8<8<--- $ mount sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,nosuid,relatime,size=8053524k,nr_inodes=2013381,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1614472k,mode=755) /dev/mapper/host-root on / type ext4 (rw,relatime,errors=remount-ro,stripe=8191) securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=25,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=12208) debugfs on /sys/kernel/debug type debugfs (rw,relatime) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) mque
Bug#989354: smokeping: Classical initscript (Sysvinit) fails to stop daemon
Hi there Patrik, Thanks for the change you've submitted! As you said, the init script is still there in the package so we might as well keep it maintained. I've committed your change to salsa and it should make it to the next upload. I'll see if I can gather the efforts necessary to get an upload soon to debian Cheers!
Bug#993559: ganeti-3.0 unable to remove a dpkg-divert during postrm when 2.16 is still there
Package: ganeti-3.0 Version: 3.0.1-2 Severity: normal Hello, I've just performed an upgrade of a ganeti cluster from buster+2.16 to bullseye+3.0 and hit a problem during the upgrade. The procedure that I used was to: 1. install ganeti 3.0 from buster-backports and upgrade the cluster 2. run OS upgrade from buster to bullseye (I had not removed ganeti 2.16) During the upgrade to bullseye, ganeti was upgraded from the 3.0 backports package to the same one from bullseye. At that point, dpkg stopped with an error. Running "apt -f install" to fix the situation did not clear things up. Running "apt purge ganeti-2.16 ganeti-haskell-2.16 ganeti-htools-2.16" was jammed on a conflict of configuration files with 3.0: # apt -f install Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages were automatically installed and are no longer required: at-spi2-core bsdmainutils libapt-inst2.0 libevent-core-2.1-6 libevent-pthreads-2.1-6 libhogweed4 libnftables0 libprocps7 libreadline5 python3-asn1crypto python3.7 python3.7-minimal Use 'apt autoremove' to remove them. The following additional packages will be installed: ganeti-3.0 The following packages will be upgraded: ganeti-3.0 1 upgraded, 0 newly installed, 0 to remove and 497 not upgraded. 323 not fully installed or removed. Need to get 0 B/876 kB of archives. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] Reading changelogs... Done Preconfiguring packages ... (Reading database ... 64433 files and directories currently installed.) Preparing to unpack .../ganeti-3.0_3.0.1-2_all.deb ... Unpacking ganeti-3.0 (3.0.1-2) over (3.0.1-1~bpo10+1) ... Removing 'diversion of /usr/share/ganeti/2.16/ganeti/utils/version.py to /usr/share/ganeti/2.16/ganeti/utils/version.py.orig by ganeti-3.0' dpkg-divert: error: rename involves overwriting '/usr/share/ganeti/2.16/ganeti/utils/version.py' with different file '/usr/share/ganeti/2.16/ganeti/utils/version.py.orig', not allowed dpkg: warning: old ganeti-3.0 package post-removal script subprocess returned error exit status 2 dpkg: trying script from the new package instead ... Removing 'diversion of /usr/share/ganeti/2.16/ganeti/utils/version.py to /usr/share/ganeti/2.16/ganeti/utils/version.py.orig by ganeti-3.0' dpkg-divert: error: rename involves overwriting '/usr/share/ganeti/2.16/ganeti/utils/version.py' with different file '/usr/share/ganeti/2.16/ganeti/utils/version.py.orig', not allowed dpkg: error processing archive /var/cache/apt/archives/ganeti-3.0_3.0.1-2_all.deb (--unpack): new ganeti-3.0 package post-removal script subprocess returned error exit status 2 Removing 'diversion of /usr/share/ganeti/2.16/ganeti/utils/version.py to /usr/share/ganeti/2.16/ganeti/utils/version.py.orig by ganeti-3.0' dpkg-divert: error: rename involves overwriting '/usr/share/ganeti/2.16/ganeti/utils/version.py' with different file '/usr/share/ganeti/2.16/ganeti/utils/version.py.orig', not allowed dpkg: error while cleaning up: new ganeti-3.0 package post-removal script subprocess returned error exit status 2 Errors were encountered while processing: /var/cache/apt/archives/ganeti-3.0_3.0.1-2_all.deb needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1) In order to get out of that situation, we had to modify the postrm script in /var/lib/dpkg/info/ganeti-3.0.postrm to comment out the dpkg-diver --remove command. That permitted the package to finish upgrading and the os upgrade to complete. Once the upgrade was completed, I was able to purge ganeti 2.16 (and I had to manually remove the diversion that was left behind) I'm guessing this happened because the ganeti 2.16 packages were still in place. But it was a situation quite difficult to work around of. I'm wondering if something can be done to avoid this situation. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ganeti-3.0 depends on: ii adduser3.118 pn bridge-utils ii debconf [debconf-2.0] 1.5.77 pn fping ii iproute2 5.13.0-2 pn iputils-arping ii libcap2-bin1:2.44-1 ii lvm2 2.03.11-2.1 ii openssh-client 1:8.4p1-6 ii openssh-server 1:8.4p1-6 ii openssl1.1.1l-1 ii python33.9.2-3 pn python3-bitarray pn python3-openssl ii python3-paramiko 2.7.2-1 ii python3-psutil 5.8.0-1 ii python3-pycurl 7.44.1-1
Bug#990457: monitoring-plugins-contrib: Too many things in the same package leads to recommends being ignored most of the time
Package: monitoring-plugins-contrib Severity: normal Hello, The monitoring-plugins-contrib package contains many useful things, so I tend to always install it on hosts. However, many checks that are contained within it are not really useful most of the time. This means that if I just install this package as-is, I'll end up with lots of useless dependencies on every host, so I've started installing it with --no-install-recommends. This has the benefit of letting me manage what dependencies come with it, but it has the downfall that I need to manually install the required ones. I would like to suggest breaking up this package into smaller binary packages that are focused on one application/service per package. This way one could install only the checks that are required with their individual requirements. The package named monitoring-plugins-contrib could be kept in place just to make it depend on all of the other smaller packages. This way the current behavior would be kept around for ppl used to installing this package and getting it all in one go. -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_WARN Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled monitoring-plugins-contrib depends on no packages. Versions of packages monitoring-plugins-contrib recommends: ii bind9-host 1:9.16.15-1 ii binutils 2.35.2-2 ii curl 7.74.0-1.3 pn debsecan ii file 1:5.39-3 pn freeipmi-tools ii libc6 2.31-12 ii libdata-validate-domain-perl 0.10-1.1 pn libdata-validate-ip-perl ii libdate-manip-perl 6.85-1 pn libdbd-mysql-perl ii libio-socket-ssl-perl 2.069-1 ii libipc-run-perl20200505.0-1 ii liblocale-gettext-perl 1.07-4+b1 pn liblwp-useragent-determined-perl pn libmail-imapclient-perl pn libmemcached11 pn libmonitoring-plugin-perl | libnagios-plugin-perl pn libnet-cups-perl ii libnet-dns-perl1.29-1 ii libnet-dns-sec-perl1.18-1+b1 ii libnet-smtp-ssl-perl 1.04-1 pn libnet-smtp-tls-perl pn libnet-smtpauth-perl pn libnet-snmp-perl ii libnet-ssleay-perl 1.88-3+b1 ii libreadonly-perl 2.050-3 pn libredis-perl ii libsocket-perl 2.031-1 ii libtimedate-perl 2.3300-2 pn libwebinject-perl ii libxml-simple-perl 2.25-1 pn lz4 ii lzop 1.04-2 pn nagios-plugins-basic ii openssl1.1.1k-1 ii perl 5.32.1-4 ii perl-base [libsocket-perl] 5.32.1-4 ii python33.9.2-3 pn python3-pymongo ii ruby 1:2.7+2 ii snmp 5.9+dfsg-3+b1 ii whois 5.5.10 Versions of packages monitoring-plugins-contrib suggests: pn backuppc pn cciss-vol-status pn expect ii libsys-virt-perl 7.0.0-1 pn moreutils pn mpt-status pn nagios-plugin-check-multi pn percona-toolkit pn perl-doc pn python3-boto pn smstools
Bug#990457: [Pkg-nagios-devel] Bug#990457: monitoring-plugins-contrib: Too many things in the same package leads to recommends being ignored most of the time
Hello, On 2021-06-29 16 h 08, Jan Wagner wrote: Hi Gabriel, Am 29.06.21 um 19:34 schrieb Gabriel Filion: I would like to suggest breaking up this package into smaller binary packages that are focused on one application/service per package. This way one could install only the checks that are required with their individual requirements. as you may have read the documentation and used our suggested way to solve your problem by not installing the recommands automatically, our plan worked out. Anyway ... if you would like to do the work to draft such a package split, you can send MRs via https://salsa.debian.org/nagios-team/pkg-nagios-plugins-contrib/, which would be very welcomed. With kind regards, Jan. I unfortunately will be unavailable for the next month. also I'm still very much a beginner with debian packaging, so I'm not certain that I'll know exactly all of the details that need to be handled. So I'm afraid that I unfortunately won't be able to push this forward for some time :\
Bug#991196: RFP: vim-vint -- Fast and highly extensible Vim script language lint
Package: wnpp Severity: wishlist * Package name: vim-vint Version : 0.4a4 Upstream Author : Kuniwak * URL : https://github.com/Vimjas/vint * License : MIT Programming Lang: Python Description : Fast and highly extensible Vim script language lint Vint is a Vim script Language Lint that aims to be highly extensible, highly customizable and high performance. It can be used standalone or can be integrated with Vim plugins such as syntastic or CoC.vim in order to continually check your scripts. The linting rules are based upon a number of sources, among which are the Google Vimscript Style Guide. This package makes writing better vimscript way easier since it helps you avoid many pitfalls while you're writing or reviewing your code. I personally have no experience with creating packaging for python codebases. I also don't have much spare energy so I don't think I can put the effort into creating the package for Vint.
Bug#986864: python3-sshtunnel: New upstream version 0.4.0
Package: python3-sshtunnel Version: 0.1.4-2 Severity: normal Hello, Thanks for maintaining this library package, I've used it to make things easier for reaching services that are reachable only on localhost on certain machines. I've just encountered a bug with the currently available version where using the default parameter value of host_pkey_directories=None when creating a class of type SSHTunnelForwarder does not search for keys inside the default ~/.ssh directory, contrary to what is documented in the code. I've looked upstream and this problem was solved in newer releases. Whenever it is convenient for you, could you please bump the library's version? Currently there is 0.4.0 available on github. Cheers! -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-sshtunnel depends on: ii python3 3.9.2-3 ii python3-paramiko 2.7.2-1 python3-sshtunnel recommends no packages. python3-sshtunnel suggests no packages. -- no debconf information
Bug#821207: [nagios-plugins-contrib] check_smtp_send fails when sending with --tls
Hi there,
This bug is still present and it's annoying that we can't use the plugin
with tls connections because of it. There hasn't been any movement
upstream for 8 years now unfortunately.
But, thanks to Jan's input, I've tried a simple workaround of just
commenting out all of the calls to the problematic $smtp->message()
calls and it made the script work again.
I'm attaching the patch that I used for the workaround.
--- /usr/lib/nagios/plugins/check_smtp_send.orig 2020-09-25 15:36:59.291283004 -0400
+++ /usr/lib/nagios/plugins/check_smtp_send 2020-09-25 15:37:38.739800192 -0400
@@ -149,26 +149,26 @@
if( $tls and $auth_method ) {
$smtp_port = $default_smtp_tls_port unless $smtp_port;
$smtp = TLS_auth->new($smtp_server, Timeout=>$timeout, Port=>$smtp_port, User=>$username, Password=>$password, Auth_Method=>$auth_method);
- if( $smtp ) {
- my $message = oneline($smtp->message());
- die "cannot connect with TLS/$auth_method: $message" if $smtp->code() =~ m/53\d/;
- }
+ #if( $smtp ) {
+ # my $message = oneline($smtp->message());
+ # die "cannot connect with TLS/$auth_method: $message" if $smtp->code() =~ m/53\d/;
+ #}
}
elsif( $tls ) {
$smtp_port = $default_smtp_tls_port unless $smtp_port;
$smtp = Net::SMTP::TLS->new($smtp_server, Timeout=>$timeout, Port=>$smtp_port, User=>$username, Password=>$password);
- if( $smtp ) {
- my $message = oneline($smtp->message());
- die "cannot connect with TLS: $message" if $smtp->code() =~ m/53\d/;
- }
+ #if( $smtp ) {
+ # my $message = oneline($smtp->message());
+ # die "cannot connect with TLS: $message" if $smtp->code() =~ m/53\d/;
+ #}
}
elsif( $ssl ) {
$smtp_port = $default_smtp_ssl_port unless $smtp_port;
$smtp = Net::SMTP::SSL->new($smtp_server, Port => $smtp_port, Timeout=>$timeout,Debug=>$smtp_debug);
if( $smtp && $username ) {
$smtp->auth($username, $password);
- my $message = oneline($smtp->message());
- die "cannot connect with SSL/password: $message" if $smtp->code() =~ m/53\d/;
+ #my $message = oneline($smtp->message());
+ #die "cannot connect with SSL/password: $message" if $smtp->code() =~ m/53\d/;
}
}
elsif( $auth_method ) {
@@ -176,8 +176,8 @@
$smtp = Net::SMTP_auth->new($smtp_server, Port=>$smtp_port, Timeout=>$timeout,Debug=>$smtp_debug);
if( $smtp ) {
$smtp->auth($auth_method, $username, $password);
- my $message = oneline($smtp->message());
- die "cannot connect with SSL/$auth_method: $message" if $smtp->code() =~ m/53\d/;
+ #my $message = oneline($smtp->message());
+ #die "cannot connect with SSL/$auth_method: $message" if $smtp->code() =~ m/53\d/;
}
}
else {
@@ -185,8 +185,8 @@
$smtp = Net::SMTP->new($smtp_server, Port=>$smtp_port, Timeout=>$timeout,Debug=>$smtp_debug);
if( $smtp && $username ) {
$smtp->auth($username, $password);
- my $message = oneline($smtp->message());
- die "cannot connect with password: $message" if $smtp->code() =~ m/53\d/;
+ #my $message = oneline($smtp->message());
+ #die "cannot connect with password: $message" if $smtp->code() =~ m/53\d/;
}
}
};
signature.asc
Description: OpenPGP digital signature
Bug#971334: opendkim should use /run instead of /var/run
Package: opendkim Version: 2.11.0~alpha-12 Severity: normal Hello, When installing opendkim on debian buster, I get the following warning: Setting up opendkim (2.11.0~alpha-12) ... Created symlink /etc/systemd/system/multi-user.target.wants/opendkim.service -> /lib/systemd/system/opendkim.service. [opendkim.conf:1] Line references path below legacy directory /var/run/, updating /var/run/opendkim → /run/opendkim; please update the tmpfiles.d/ drop-in file accordingly. indeed, opendkim is still using /var/run instead of the new path /run I might have missed some occurrences of this, but it's at least present in the systemd unit, /etc/default/opendkim and in /etc/opendkim.conf -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU threads) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages opendkim depends on: ii adduser 3.118 ii dns-root-data2019052802 ii init-system-helpers 1.58 ii libbsd0 0.10.0-1 ii libc62.31-3 ii libdb5.3 5.3.28+dfsg1-0.6 ii libldap-2.4-22.4.53+dfsg-1 pn liblua5.1-0 pn libmemcached11 pn libmilter1.0.1 pn libopendbx1 pn libopendkim11 pn librbl1 ii libssl1.11.1.1g-1 ii libunbound8 1.11.0-1 pn libvbr2 ii lsb-base 11.1.0 Versions of packages opendkim recommends: pn opendkim-tools opendkim suggests no packages.
Bug#932135: puppetdb can't create/upgrade its DB schema past version 65 with postgres-11 11.4-1
Package: puppetdb Version: 6.2.0-3 Severity: grave Justification: renders package unusable Hi there! I've hit a bug with a new installation of puppetdb on buster (e.g. I've re-created my puppetmaster vagrant box) where puppetdb would fail to start, erroring out on an SQL upgrade of the database schema during the first service start. I'll include the error log lower down since it's pretty long. I've found a bug report on pupperware (puppet packaged up in docker containers) that describes exactly the same problem, identifies a faulty postgresql 9.6.x version and seems to point to an upstream bug report that contains a fix. https://github.com/puppetlabs/pupperware/issues/82 Since in buster we're using postgresql-11, we've had to identify which version had introduced the problem. I'm not sure about the exact minor version of postgres, but for certain when downgrading the debian package to postgres-11 version 11.3-1, then puppetdb is able to start and complete its schema upgrade. So the bug must have been introduced somewhere between 11.3 and 11.4 The upstream bug report says that there might be a fix for puppetdb available: https://tickets.puppetlabs.com/browse/PDB-4422 It might be interesting to test applying the fix from the most appropriate branch (I'm not sure whether 6.0 or 6.3 makes more sense) and then test a new install with postgresql-11 version 11.4-1 to see if it goes through the schema upgrade successfully. Here's the puppetdb log that shows the error happening during the first run of a new puppetdb 6.2.0-3 install with postgresql-11 version 11.4-1: --8<8<-- 2019-07-15T05:11:14.759-04:00 INFO [p.p.c.services] PuppetDB version 6.2.0 2019-07-15T05:11:14.760-04:00 WARN [c.z.h.HikariConfig] The initializationFailFast propery is deprecated, see initializationFailTimeout 2019-07-15T05:11:14.761-04:00 INFO [c.z.h.HikariDataSource] PDBMigrationsPool - Starting... 2019-07-15T05:11:14.763-04:00 INFO [c.z.h.HikariDataSource] PDBMigrationsPool - Start completed. 2019-07-15T05:11:15.098-04:00 INFO [p.p.s.migrate] Applying database migration version 28 2019-07-15T05:11:15.564-04:00 INFO [p.p.s.migrate] Applied database migration version 28 in 465 ms 2019-07-15T05:11:15.564-04:00 INFO [p.p.s.migrate] Applying database migration version 29 2019-07-15T05:11:15.865-04:00 INFO [p.p.s.migrate] Applied database migration version 29 in 301 ms 2019-07-15T05:11:15.865-04:00 INFO [p.p.s.migrate] Applying database migration version 30 2019-07-15T05:11:15.870-04:00 INFO [p.p.s.migrate] Applied database migration version 30 in 5 ms 2019-07-15T05:11:15.870-04:00 INFO [p.p.s.migrate] Applying database migration version 31 2019-07-15T05:11:15.897-04:00 INFO [p.p.s.migrate] Applied database migration version 31 in 26 ms 2019-07-15T05:11:15.897-04:00 INFO [p.p.s.migrate] Applying database migration version 32 2019-07-15T05:11:15.916-04:00 INFO [p.p.s.migrate] Applied database migration version 32 in 19 ms 2019-07-15T05:11:15.917-04:00 INFO [p.p.s.migrate] Applying database migration version 33 2019-07-15T05:11:15.940-04:00 INFO [p.p.s.migrate] Applied database migration version 33 in 23 ms 2019-07-15T05:11:15.940-04:00 INFO [p.p.s.migrate] Applying database migration version 34 2019-07-15T05:11:15.992-04:00 INFO [p.p.s.migrate] Applied database migration version 34 in 52 ms 2019-07-15T05:11:15.992-04:00 INFO [p.p.s.migrate] Applying database migration version 35 2019-07-15T05:11:15.993-04:00 INFO [p.p.s.migrate] Applied database migration version 35 in 1 ms 2019-07-15T05:11:15.993-04:00 INFO [p.p.s.migrate] Applying database migration version 36 2019-07-15T05:11:15.995-04:00 INFO [p.p.s.migrate] Applied database migration version 36 in 2 ms 2019-07-15T05:11:15.995-04:00 INFO [p.p.s.migrate] Applying database migration version 37 2019-07-15T05:11:15.997-04:00 INFO [p.p.s.migrate] Applied database migration version 37 in 2 ms 2019-07-15T05:11:15.997-04:00 INFO [p.p.s.migrate] Applying database migration version 38 2019-07-15T05:11:15.999-04:00 INFO [p.p.s.migrate] Applied database migration version 38 in 1 ms 2019-07-15T05:11:15.999-04:00 INFO [p.p.s.migrate] Applying database migration version 39 2019-07-15T05:11:16.055-04:00 INFO [p.p.s.migrate] Applied database migration version 39 in 56 ms 2019-07-15T05:11:16.056-04:00 INFO [p.p.s.migrate] Applying database migration version 40 2019-07-15T05:11:16.096-04:00 INFO [p.p.s.migrate] Applied database migration version 40 in 40 ms 2019-07-15T05:11:16.097-04:00 INFO [p.p.s.migrate] Applying database migration version 41 2019-07-15T05:11:16.099-04:00 INFO [p.p.s.migrate] Applied database migration version 41 in 3 ms 2019-07-15T05:11:16.100-04:00 INFO [p.p.s.migrate] Applying database migration version 42 2019-07-15T05:11:16.192-04:00 INFO [p.p.s.migrate] Applied database migration version 42 in 92 ms 2019-07-15T05:11:16.192-04:00 INFO [p.
Bug#978500: facter: package deploys ruby code but no gem
Package: facter Version: 3.14.12-1+b2 Severity: normal Hello, The "facter" package currently does not ship the .gemspec file that gets generated during build. This means that facter is not visible as an installed system-wide gem. The impact of this is that other packages that depend on the "facter" gem, will require a hack in order to remove facter from the gemspec dependencies. Also, gems installed manually may end up installing a second copy of facter on the system. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages facter depends on: ii libboost-program-options1.74.0 1.74.0-5 ii libc6 2.31-6 ii libfacter3.14.123.14.12-1+b2 ii libgcc-s1 10.2.1-3 ii libleatherman1.12.1 1.12.1+dfsg-1.1 ii libstdc++6 10.2.1-3 ii ruby1:2.7+2 facter recommends no packages. facter suggests no packages. -- no debconf information
Bug#979642: RFP: shellspec -- Unit testing framework using the BDD paradigm for bash, ksh, zsh, dash and all POSIX shells.
Package: wnpp Severity: wishlist * Package name: shellspec Version : 0.28.0 Upstream Author : Koichi Nakashima <> * URL : https://github.com/shellspec/shellspec * License : Expat Programming Lang: Shell Description : Unit testing framework using the BDD paradigm for bash, ksh, zsh, dash and all POSIX shells. ShellSpec is a full-featured BDD unit testing framework for dash, bash, ksh, zsh and all POSIX shells that provides first-class features such as code coverage, mocking, parameterized test, parallel execution and more. It was developed as a dev/test tool for cross-platform shell scripts and shell script libraries. This framework is an alternative to other frameworks which are already packaged in debian like bats, shunit2 and shelltestrunner. However, this library provides a BDD aproach to testing shell scripts and also provides some very interesting additional features. The project also has a website: https://shellspec.info/
Bug#971671: gnome-shell-extension-autohidetopbar: error loading extension after gnome-shell upgrade
Package: gnome-shell-extension-autohidetopbar Version: 20200921-1 Severity: normal Hello, I've run upgrades today on debian sid, and gnome-shell was upgraded from 3.36.6-1 to 3.38.0-2. The autohidetopbar is not working, and in gnome-tweaks I see a message on the add-on that says "Error loading extension". I currently don't know how to find out more information about the error, but I'm willing to dig for more. I'm running gnome with Xorg 2:1.20.9-2 -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-shell-extension-autohidetopbar depends on: ii gnome-shell 3.38.0-2 Versions of packages gnome-shell-extension-autohidetopbar recommends: ii gnome-tweaks 3.34.0-4 gnome-shell-extension-autohidetopbar suggests no packages. -- no debconf information
Bug#971671: gnome-shell-extension-autohidetopbar: error loading extension after gnome-shell upgrade
On 2020-10-05 9:58 a.m., Tobias Frost wrote: On Sun, Oct 04, 2020 at 01:59:33PM -0400, Gabriel Filion wrote: Package: gnome-shell-extension-autohidetopbar Version: 20200921-1 Severity: normal Hello, I've run upgrades today on debian sid, and gnome-shell was upgraded from 3.36.6-1 to 3.38.0-2. The autohidetopbar is not working, and in gnome-tweaks I see a message on the add-on that says "Error loading extension". I currently don't know how to find out more information about the error, but I'm willing to dig for more. This could be https://github.com/mlutfy/hidetopbar/issues/255. Can you try a "journalctl --user" and see if you can find something in the logs? nice, I've just upgraded and reloaded gnome and the problem is fixed. thanks for the quick response!
Bug#972065: python3-plac: New upstram release 1.2.0
Package: python3-plac Version: 0.9.6-1 Severity: normal Hello, The plac library has see some releases since the current version that's in the debian archive was released. Version 1.2.0 is currently available: https://pypi.org/project/plac/#files Version 0.9.6 was released in 2016: https://pypi.org/project/plac/#history The list of changes that happened does not seem very huge, but there's been some feature additions and bug fixes: https://github.com/micheles/plac/blob/master/CHANGES.md upstream now also has a LICENSE.txt file to make it more explicit that the code is under 2-clause BSD. cheers! -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-plac depends on: ii python3 3.8.2-3 python3-plac recommends no packages. python3-plac suggests no packages. -- no debconf information
Bug#956936: [Pkg-libvirt-maintainers] Bug#956936: libvirt-daemon: clients unable to connect to libvirt: CheckAuthorization: Action org.libvirt.unix.manage is not registered
Hi Guido, thanks for your quick feedback! much appreciated. On 2020-04-17 3:10 a.m., Guido Günther wrote: > On Thu, Apr 16, 2020 at 06:42:32PM -0400, Gabriel Filion wrote: >> my user is part of the libvirt and kvm groups so I should have access to the >> local unix sockets. however when I try and connect to libvirt on localhost >> (either with vagrant-libvirt or with virt-manager) I get an error message >> that >> also appears in the service's log as: >> >> Apr 16 17:51:47 meevyl libvirtd[544743]: error from service: >> CheckAuthorization: Action org.libvirt.unix.manage is not registered >> Apr 16 17:51:47 meevyl libvirtd[544743]: End of file while reading data: >> Input/output error > > Is that qemu:///system ? yes exactly. and vagrant shows it this way (also confirming that it's connecting to qemu:///system: Error while connecting to libvirt: Error making a connection to libvirt URI qemu:///system?no_verify=1&keyfile=/home/gabster/.ssh/id_rsa: Call to virConnectOpen failed: error from service: CheckAuthorization: Action org.libvirt.unix.manage is not registered >> From what I could vaguely understand, the first line seems to be related to >> polkit but I don't quite understand how this thing is supposed to be working. >> >> >> I do have polkit installed and runing: >> >> $ dpkg -l | grep polkit >> ii gir1.2-polkit-1.0 0.105-26 >> amd64GObject introspection data for PolicyKit >> ii libpolkit-agent-1-0:amd64 0.105-26 >> amd64PolicyKit Authentication Agent API >> ii libpolkit-gobject-1-0:amd64 0.105-26 >> amd64PolicyKit Authorization API >> $ ps aux|grep polkit >> root 544473 0.0 0.0 235204 10120 ?Ssl 17:49 0:00 >> /usr/lib/policykit-1/polkitd --no-debug >> gabster 545750 0.0 0.0 8744 844 pts/8S+ 18:29 0:00 grep >> --color=auto polkit > > You don't show the polkitd (package policykit-1) version oh, right I missed this out in the original report: $ dpkg -l | grep policykit ii policykit-1 0.105-26 amd64framework for managing administrative policies and privileges ii policykit-1-gnome 0.105-7 amd64authentication agent for PolicyKit > but if that's > 0.105 as well can you check if things like >pkexec /bin/ls > work this asks me for my password, and then shows this output (it's not the contents of the current directory so I'm not sure what it's listing exactly): $ pkexec /bin/ls snap > and check if > /var/lib/polkit-1/localauthority/10-vendor.d/60-libvirt.pkla is present I get file not found for the above. > and there's no other libvirt related policies e.g. in /etc/polkit-1? nothing that seems relevant to libvirt in both directories: $ sudo tree /var/lib/polkit-1/localauthority/ /var/lib/polkit-1/localauthority/ ├── 10-vendor.d │ ├── fwupd.pkla │ ├── geoclue-2.0.pkla │ ├── gnome-control-center.pkla │ ├── org.freedesktop.Flatpak.pkla │ ├── org.freedesktop.NetworkManager.pkla │ ├── org.freedesktop.packagekit.pkla │ └── systemd-networkd.pkla ├── 20-org.d ├── 30-site.d ├── 50-local.d └── 90-mandatory.d 5 directories, 7 files $ sudo tree /etc/polkit-1/ /etc/polkit-1/ ├── localauthority │ ├── 10-vendor.d │ ├── 20-org.d │ ├── 30-site.d │ ├── 50-local.d │ └── 90-mandatory.d ├── localauthority.conf.d │ ├── 50-localauthority.conf │ └── 51-debian-sudo.conf └── rules.d ├── 40-debian-sudo.rules └── 50-default.rules 8 directories, 4 files since I use etckeeper, I've checked the history for /etc/polkit-1/ and there was never a file with "libvirt" in its name in there. oh! but I just searched on codesearch.d.n and found out that the polkit file should be installed there by libvirt-daemon-system and for some reason this package was in state "rc" on my system. I with version 6.0.0-6 of it with "apt install libvirt-daemon-system" and now it's present on my system! and I can connect to qemu:///system again! I've also had to manually start the virtlogd.socket unit. but now with those two details fixed I can manage VMs again on my laptop. I'm not sure why libvirt-daemon-system had been left semi-removed on the system though .. according to my dpkg log it was left removed during the upgrade from 5.6.0-3 to 6.0.0-5 .. oh well I guess it's all fine for now. thanks, I was able to figure it out thanks to your pointers! signature.asc Description: OpenPGP digital signature
Bug#925444: smokeping: --pid-dir doesn't worj as expected
Hi Cameron, Sorry it took me so much time to reply. I've just now fixed my local discardable VM setup for testing so I'm able to dive in again. On Tue, 11 Feb 2020 11:23:19 +1000 Cameron Davidson wrote: > This has just started hapenning to my also. > > The cause, I think, that evenutally a tmpfile cleanup will delete > /run/smokeping - maybe depends on age and/or because it is not owned by > root. This is very strange.. As I've mentioned earlier in this bug report, the systemd unit file should have a directive (RuntimeDirectory) that automatically creates the directory /run/smokeping. I've just verified and the sysvinit script also does create the directory (albeit under /var/run, but that should be equivalent since /var/run can be expected to symlink to /run). Something that I've just discovered today though is that systemd completely destroys the /run/smokeping directory when the service is stopped. So this might throw some ppl off (myself included!) when trying to debug this. maybe one thing that might be interesting to verify is whether the configuration file points to the right directory for "piddir". In the default configuration that the package ships, the file /etc/smokeping/config.d/pathnames contains the following: root@debian-10-amd64:~# cat /etc/smokeping/config.d/pathnames sendmail = /usr/sbin/sendmail imgcache = /var/cache/smokeping/images imgurl = ../smokeping/images datadir = /var/lib/smokeping piddir = /var/run/smokeping smokemail = /etc/smokeping/smokemail tmail = /etc/smokeping/tmail dyndir = /var/lib/smokeping/__cgi check in this file if "piddir" points either to /var/run/smokeping or /run/smokeping, otherwise try and correct the path. and finally as I mentioned earlier, if smokeping is running in "slave" mode, then --pid-dir behaves differently : it does not create a pid file for some reason. if you're running smokeping using this mode, then take a look at the example file I've added to the package: /usr/share/doc/smokeping/examples/systemd/slave_mode.conf this can be copied in a systemd override directory and then adapted for the master url. the file contains some instructions in comments for where to place it. > One solution (I found for other systemd processes run as non-root) is to > add a config file: > > /usr/lib/tmpfiles.d/smokeping.conf > > Contents should be something like: > > d /run/smokeping 0755 smokeping smokeping - - > > to have systemd recreate the dir when smokeping is started. I believe this should be non-necessary since both the init script and the systemd units have some method to automatically create the directory. If you're still unable to get the pid file to be created by systemd, then maybe I'm missing something out. In this case, tell me a bit more information about your system. e.g. what CPU architecture is being used (amd64, arm64, i386, ...) and what version of systemd your system currently has installed. Cheers! signature.asc Description: OpenPGP digital signature
Bug#977932: python3-pypuppetdb: new upstream version 2.2.0 available
Package: python3-pypuppetdb Version: 0.3.3-2 Severity: normal Hello, the version of this library that's currently in debian is now 3 years old and new versions were released since. The latest release is 2.2.0 from june 2020. It brings in a couple desirable changes among which are: * support for the "status" endpoint * use of POST for query * support of new query operator FromOperator * support for the command API -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pypuppetdb depends on: ii python3 3.9.0-4 ii python3-requests 2.25.0+dfsg-1 python3-pypuppetdb recommends no packages. python3-pypuppetdb suggests no packages. -- no debconf information -- debsums errors found: debsums: changed file /usr/lib/python3/dist-packages/pypuppetdb/api.py (from python3-pypuppetdb package)
Bug#974697: trocla: new upstream release 0.3.0 is available
Package: trocla Severity: normal Hello, according to github tag timestamps[0], version 0.3.0 of trocla was released in august 2017. [0]:https://github.com/duritong/trocla/tags it would be nice to get the newer version in debian , especially since puppet-related tools have the tendency to move a lot with enough time. thanks in advance! -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages trocla depends on: ii ruby 1:2.7+2 pn ruby-bcrypt pn ruby-highline pn ruby-moneta trocla recommends no packages. Versions of packages trocla suggests: ii puppet 5.5.22-1
Bug#881460: apparmor-profiles: dhclient set to enforce prevents getting an IPv4 with DHCP
Package: apparmor-profiles Version: 2.11.1-3 Severity: critical Justification: breaks unrelated software Hello, I've started using apparmor very recently, and when I rebooted to activate the kernel part, I didn't notice the issue below.. but a couple reboots afterwards I couldn't obtain a DHCP address anymore for wired and wifi interfaces. >From what I could see, when dhclient6 gets called by network-manager, this program gets denied a bunch of operations which makes it not do what it's supposed to and just exit. The weird part that I don't understand yet is that I don't think I've installed or upgraded anything else since I enabled apparmor (so why didn't I see this in a more consistent manner?). In the syslog I found the following log lines that are relevant: Nov 11 16:53:14 boohn kernel: [ 15.622076] audit: type=1400 audit(1510437193.949:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="dhclient" pid=620 comm="apparmor_parser" Nov 11 16:53:20 boohn NetworkManager[678]: [1510437200.9563] dhcp-init: Using DHCP client 'dhclient' Nov 11 16:53:24 boohn NetworkManager[678]: [1510437204.1739] dhcp4 (eth0): dhclient started with pid 1184 Nov 11 16:53:24 boohn dhclient[1185]: execve (/usr/lib/NetworkManager/nm-dhcp-helper, ...): Permission denied Nov 11 16:53:24 boohn kernel: [ 25.862578] audit: type=1400 audit(1510437204.189:74): apparmor="DENIED" operation="exec" profile="dhclient" name="/usr/lib/NetworkManager/nm-dhcp-helper" pid=1185 comm="dhclient" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 Nov 11 16:53:24 boohn dhclient[1184]: DHCPREQUEST of 192.168.2.243 on eth0 to 255.255.255.255 port 67 Nov 11 16:53:24 boohn dhclient[1184]: DHCPNAK from 192.168.2.1 Nov 11 16:53:24 boohn dhclient[1186]: execve (/usr/lib/NetworkManager/nm-dhcp-helper, ...): Permission denied Nov 11 16:53:24 boohn kernel: [ 25.887214] audit: type=1400 audit(1510437204.214:75): apparmor="DENIED" operation="exec" profile="dhclient" name="/usr/lib/NetworkManager/nm-dhcp-helper" pid=1186 comm="dhclient" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 Nov 11 16:53:24 boohn kernel: [ 25.887967] audit: type=1400 audit(1510437204.215:76): apparmor="DENIED" operation="exec" profile="dhclient" name="/usr/lib/NetworkManager/nm-dhcp-helper" pid=1187 comm="dhclient" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 Nov 11 16:53:24 boohn dhclient[1187]: execve (/usr/lib/NetworkManager/nm-dhcp-helper, ...): Permission denied Nov 11 16:53:24 boohn dhclient[1184]: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 Nov 11 16:53:24 boohn dhclient[1184]: DHCPREQUEST of 192.168.2.233 on eth0 to 255.255.255.255 port 67 Nov 11 16:53:24 boohn dhclient[1184]: DHCPOFFER of 192.168.2.233 from 192.168.2.1 Nov 11 16:53:24 boohn dhclient[1184]: DHCPACK of 192.168.2.233 from 192.168.2.1 Nov 11 16:53:24 boohn dhclient[1188]: execve (/usr/lib/NetworkManager/nm-dhcp-helper, ...): Permission denied Nov 11 16:53:24 boohn kernel: [ 25.894073] audit: type=1400 audit(1510437204.221:77): apparmor="DENIED" operation="exec" profile="dhclient" name="/usr/lib/NetworkManager/nm-dhcp-helper" pid=1188 comm="dhclient" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 Nov 11 16:53:24 boohn dhclient[1184]: bound to 192.168.2.233 -- renewal in 37728 seconds. Nov 11 16:53:26 boohn NetworkManager[678]: [1510437206.3351] dhcp6 (eth0): dhclient started with pid 1189 Nov 11 16:53:26 boohn kernel: [ 28.012088] audit: type=1400 audit(1510437206.339:78): apparmor="DENIED" operation="open" profile="dhclient" name="/var/lib/NetworkManager/dhclient6-eth0.conf" pid=1189 comm="dhclient" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Nov 11 16:53:26 boohn kernel: [ 28.012098] audit: type=1400 audit(1510437206.339:79): apparmor="DENIED" operation="open" profile="dhclient" name="/var/lib/NetworkManager/dhclient6-b63c69a8-9bf3-4eef-9610-09eee2527a06-eth0.lease" pid=1189 comm="dhclient" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Nov 11 16:53:26 boohn kernel: [ 28.012104] audit: type=1400 audit(1510437206.339:80): apparmor="DENIED" operation="open" profile="dhclient" name="/var/lib/NetworkManager/dhclient6-b63c69a8-9bf3-4eef-9610-09eee2527a06-eth0.lease" pid=1189 comm="dhclient" requested_mask="wc" denied_mask="wc" fsuid=0 ouid=0 Nov 11 16:53:26 boohn dhclient[1189]: can't create /var/lib/NetworkManager/dhclient6-b63c69a8-9bf3-4eef-9610-09eee2527a06-eth0.lease: Permission denied Nov 11 16:53:26 boohn dhclient[1190]: execve (/usr/lib/NetworkManager/nm-dhcp-helper, ...): Permission denied Nov 11 16:53:26 boohn dhclient[1189]: Created duid "\000\001\000\001!\232-\326\360\336\361+\253L". Nov 11 16:53:26 boohn dhclient[1189]: can't create /var/lib/NetworkManager/dhclient6-b63c69a8-9bf3-4eef-9610-09eee2527a06-eth0.lease: Permission denied Nov 11 16:53:26 boohn dhclient[1189]: Can't create /run/dhclient6-eth0.pid: Permission denied Nov 11 16:53:26 boohn kernel: [ 28.012575] audit: type=1400 au
Bug#881460: apparmor-profiles: dhclient set to enforce prevents getting an IPv4 with DHCP
intrigeri: > Let's sort this out first as there seems to be a misunderstanding. > IMO this bug is not RC because: > > 1. The profile this bug report is about is not enforced by default; >it's not even shipped in /etc/apparmor.d. It takes 2 manual steps >to enforce it, so thankfully, we're far from shipping a broken >default configuration :) oh! you're totally right! I don't remember enabling the profile but I was just blindly finding my way around to understand apparmor in the recent days. thanks for the super clear explanation for changing the status :) > If you came across instructions that told you to enforce such profiles > and that did not point you to the aforementioned warning, then I'm > very sorry! I'll treat this as a RC bug. Please point me to that doc > and I'll fix it ASAP. Thanks in advance! fwiw I was following mainly the debian wiki pages about apparmor. I remember reading the advisory, but for some reason I didn't keep the information that "the profiles might not work with default configurations" when reading. probably some level of confusion on my part. >> and when I rebooted to activate the kernel part, I didn't notice the >> issue below.. but a couple reboots afterwards I couldn't obtain >> a DHCP address anymore for wired and wifi interfaces. > > Thanks for reporting this. I'm sorry this profile broke an essential > part of your system. I'm not surprised though: to the best of my > knowledge, nobody is actively using this profile on, and maintaining > this profile for, Debian. Quite some paths in it don't match where > things are shipped in Debian. This is why we don't enable this profile > by default. well I guess that my report confirms that the current profile in apparmor-profiles-extra is somewhat broken. (it's still intriguing why it was working for some time and then stopped working.. but I'd have to repeat in order to figure out why. my time is probably better spent on testing this other profile you mentioned) > The good news is that there is a dhclient profile available elsewhere, > that works way better on Debian: see #795467. ok I can see that it looks like the proposed profile for isc-dhcp-client is the one from ubuntu. still no reply from debian packagers about this though, two years later. what approach should we take here in order to get things going? do you think that having more feedback from ppl who use the profile successfully would help to get that merged in, or do you suspect it might just be lack of available time or interest from package maintainers? also, maybe if we can get more ppl to test ubuntu's profile in debian, then they'd be willing to upstream it in apparmor? Cheers signature.asc Description: OpenPGP digital signature
Bug#888055: ikiwiki: Fenced code block rendering has been broken
Package: ikiwiki Version: 3.20170111 Severity: normal Hello, I've been using fenced code blocks for a while since I usually post about technical issues or howtos. That used to be available in Discount, used through ikiwiki, with a line that contains only a set of more than three ~ characters above and another one below the code block. That was activated by an option when ikiwiki was calling discount, and for some reason that option was removed. So all fenced code block rendering was completely broken by that change. Discount can have that feature enabled by an environment variable, so I've tried specifying that variable in the environment variables in my wiki's .setup file but that unfortunately didn't bring fenced code blocks back. Apparently the only way to re-enable the missing option is to patch ikiwiki. I'm wondering why that was removed without any means to bring it back. I'd very much like to be able to re-enable fenced code blocks. -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE=en_CA:en (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages ikiwiki depends on: ii libhtml-parser-perl 3.72-3 ii libhtml-scrubber-perl 0.15-1 ii libhtml-template-perl 2.95-2 ii libjson-perl2.90-1 ii libtext-markdown-discount-perl 0.11-1+b3 ii liburi-perl 1.71-1 ii libyaml-libyaml-perl0.63-2 ii perl5.24.1-3+deb9u2 Versions of packages ikiwiki recommends: ii gcc [c-compiler] 4:6.3.0-4 ii gcc-6 [c-compiler] 6.3.0-18 ii git [git-core] 1:2.11.0-3+deb9u2 ii libauthen-passphrase-perl0.008-2 ii libc6-dev [libc-dev] 2.24-11+deb9u1 ii libcgi-formbuilder-perl 3.10-1 ii libcgi-pm-perl 4.35-1 ii libcgi-session-perl 4.48-3 ii libcrypt-ssleay-perl 0.73.04-2 ii libgravatar-url-perl 1.07-1 ii liblwpx-paranoidagent-perl 1.12-1 ii libmail-sendmail-perl0.79.16-2 ii libnet-openid-consumer-perl 1.18-1 ii librpc-xml-perl 0.80-1 ii libterm-readline-gnu-perl1.35-1 ii libtimedate-perl 2.3000-2 ii libxml-simple-perl 2.22-1 Versions of packages ikiwiki suggests: pn dvipng ii file 1:5.30-1+deb9u1 pn gettext pn ghostscript pn graphviz pn libfile-mimeinfo-perl pn libhighlight-perl ii libhtml-tree-perl 5.03-2 pn libimage-magick-perl | perlmagick ii liblocale-gettext-perl 1.07-3+b1 pn libmagickcore-extra ii libmailtools-perl 2.18-1 pn libnet-amazon-s3-perl pn libnet-inet6glue-perl pn libsearch-xapian-perl ii libsort-naturally-perl 1.03-1 pn libsparkline-php pn libtext-csv-perl ii libtext-multimarkdown-perl 1.35-1 pn libtext-textile-perl pn libtext-typography-perl pn libtext-wikicreole-perl pn libtext-wikiformat-perl pn libxml-feed-perl pn libxml-writer-perl pn po4a pn polygen ii python 2.7.13-2 ii python-docutils0.13.1+dfsg-2 pn texlive pn tidy pn viewvc | gitweb | viewcvs pn xapian-omega -- no debconf information
Bug#888055: ikiwiki: Fenced code block rendering has been broken
Simon McVittie: >> [Fenced code blocks were] activated by an option when ikiwiki was >> calling discount, and >> for some reason that option was removed. So all fenced code block >> rendering was completely broken by that change. > You seem very sure that this was caused by an ikiwiki change. Can you > point to that change in ikiwiki.git? > > You're right that fenced code blocks are documented as being activated > by the MKD_FENCEDCODE flag, but we've never passed that flag to Discount > anyway, and they apparently worked in the past. That makes me wonder > whether this was an incompatible change in the Discount library or in > libtext-markdown-discount-perl, rather than in ikiwiki. oh you're right I was probably just confused about what had actually changed. It's annoying that there's no way to re-enable the fenced code blocks through ikiwiki though :\ signature.asc Description: OpenPGP digital signature
Bug#879230: puppet-common: puppet warns about a duplicate key :queue_type in defaults.rb on every run
Package: puppet-common
Version: 3.7.2-4+deb8u1
Severity: minor
Tags: patch
Hello,
I'm running puppet 3.7 from jessie with ruby 2.3 in stretch (I know this
is a bit convoluted, but that's because the master is still running 3.7)
On every run of the puppet client, I'm getting the following warning
message:
/usr/lib/ruby/vendor_ruby/puppet/defaults.rb:465: warning: key :queue_type is
duplicated and overwritten on line 466
Indeed by looking at the code, key :queue_type is defined twice
in a row with the exact same value. removing the second occurrence as in
the diff below removes the warning message:
# diff -burN /usr/lib/ruby/vendor_ruby/puppet/defaults.rb.orig
/usr/lib/ruby/vendor_ruby/puppet/defaults.rb
--- /usr/lib/ruby/vendor_ruby/puppet/defaults.rb.orig 2017-10-20
15:06:15.417868622 -0400
+++ /usr/lib/ruby/vendor_ruby/puppet/defaults.rb2017-10-20
15:06:20.518122058 -0400
@@ -463,10 +463,6 @@
:default=> "stomp",
:desc => "Which type of queue to use for asynchronous processing.",
},
-:queue_type => {
- :default=> "stomp",
- :desc => "Which type of queue to use for asynchronous processing.",
-},
:queue_source => {
:default=> "stomp://localhost:61613/",
:desc => "Which type of queue to use for asynchronous processing.
If your stomp server requires
v- below information was modified manually.. I'm not reporting from the
affected machine. so there might be some inconsistencies.
-- System Information:
Debian Release: stretch
APT prefers stretch
APT policy: (500, 'stretch')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-4-amd64 #1 SMP
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL
set to en_CA.utf8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to
en_CA.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages puppet-common depends on:
ii puppet 3.7.2-4+deb8u1
puppet-common recommends no packages.
puppet-common suggests no packages.
-- no debconf information
Bug#889855: apticron: on each run, getting twice: W: --force-yes is deprecated
Package: apticron Version: 1.1.61 Severity: normal Hello, Ever since we have stretch servers using apticron, we're getting emails from the cron runs that show only two warning messages, twice the same line: W: --force-yes is deprecated, use one of the options starting with --allow instead. I've run apticron with tracing on (bash -x apticron) and found out that the two following commands are the ones causing the warnings: /usr/bin/apt-get -q -y --ignore-hold --allow-unauthenticated -s dist-upgrade and: /usr/bin/apt-get --ignore-hold -qq -d dist-upgrade This means that apticron is calling apt-get with a deprecated set of arguments, but I'm not sure how to fix this yet. -- System Information: Debian Release: 9.3 APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apticron depends on: ii apt1.4.8 ii bzip2 1.0.6-8.1 ii cron [cron-daemon] 3.0pl1-128+b1 ii debconf [debconf-2.0] 1.5.61 ii dpkg 1.18.24 ii mailutils [mailx] 1:3.1.1-1 ii ucf3.0036 Versions of packages apticron recommends: ii apt-listchanges 3.10 ii iproute2 4.9.0-1+deb9u1 apticron suggests no packages. -- debconf information excluded
Bug#826041: Bug#816391: tor: "systemctl status tor" does not provide useful output
On Wed, 1 Jun 2016 19:13:26 + Peter Palfrader wrote: > Michael Biebl schrieb am Donnerstag, dem 14. April 2016: > > Am 14.04.2016 um 00:46 schrieb Michael Biebl: > > > The tor.service afaics is only used, so you have a > > > systemctl restart/reload tor > > > shortcut which propagates that request to all instances. > > > tor.service in itself does not provide any service. > > > > > > So it is useful to have. > > > > I'm not sure. Maybe we can convince upstream that using "status" on a > > service which is composed by several sub-services via PartOf [0], also > > propagates the status request and merges that into a single output. > > > > Or we add a dedicated key, like PropagatesReloadTo [1], say ProgatesStatusTo > > Something like that might be nice indeed. Cloning/etc bug. It could be status propagation, or if upstream changes the status of the "parent service", another idea could be to list all sub-services (instance names) in the output. maybe showing a one line status for all instances would make the top-level status all the more useful. I don't know much about the systemd code though so I don't know which option is more feasible. I just wanted to add in a different suggestion for how to improve status output. signature.asc Description: OpenPGP digital signature
Bug#889855: apticron: on each run, getting twice: W: --force-yes is deprecated
Gah! I did a little bit more research and found out that the warning was not replicating on stretch hosts managed elsewhere. This led me to find that the warning was *not* caused by aptitude itself but rather by an option in apt.conf.d/ that was configured by our configuration management (e.g. it was configuring "APT::Get::force-yes true;" I've removed this from the configuration that is being pushed by our configuration management and the warning is gone. So I'm really sorry for creating noise here and not having investigated a bit more! I thought that since I could replicate on more than one host it was a problem with the software but it was rather a configuration problem. This bug report can be closed (sorry don't know the magic email line that does this) signature.asc Description: OpenPGP digital signature
Bug#878203: apparmor logs /proc//cmdline denials on vm shutdown
Hello, I can still see this in the apparmor file included in libvirt-daemon-system 3.9.0-1 FWIW according to this ubuntu bug they've added a line to the profile to permit access: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1693115 signature.asc Description: OpenPGP digital signature
Bug#887395: vim-puppet: package vim plugin from rodjek
Package: vim-puppet Version: 3.8.5-2 Severity: normal Hello, The vim-puppet package has no package above debian jessie. I can understand why that happened: the puppetlabs vim plugin has not been maintained for so long! There is however an alternative that's available: https://github.com/rodjek/vim-puppet After discussing this with puppet package maintainers in december 2016, I was told that it didn't support puppet 4 syntax. So I opened issues and pull requests in order to have that implemented in rodjek's plugin, and the changes were merged in. So the plugin now has at least syntax hilighting for parameter types. A handful of other bugs were also corrected since the discussion. It would be great to have a vim-puppet package again with code that's a bit newer and still maintained. I've been using rodjek's syntax hilighting on my laptop for a bit more than a year now (e.g. since the above-mentioned thread) (ps. I don't recall why I have a version of the vim-puppet package installed that's more recent than the one in jessie.. but it shouldn't matter for the current suggestion) -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) vim-puppet depends on no packages. Versions of packages vim-puppet recommends: ii vim-addon-manager 0.5.6 vim-puppet suggests no packages. -- no debconf information
Bug#887395: vim-puppet: package vim plugin from rodjek
Stig Sandbeck Mathisen: >> On 15 Jan 2018, at 21:36, Gabriel Filion wrote: >> >> Package: vim-puppet >> Version: 3.8.5-2 >> Severity: normal >> >> Hello, >> >> The vim-puppet package has no package above debian jessie. I can >> understand why that happened: the puppetlabs vim plugin has not been >> maintained for so long! >> >> There is however an alternative that's available: >> >> https://github.com/rodjek/vim-puppet > > That plugin works well, but I think it should have a free software license > before it can be included in Debian. oh, fair point! Apparently, someone else thought of the same thing than you did (and also for debian packaging!) and already opened an issue on the project about licensing: https://github.com/rodjek/vim-puppet/issues/79 signature.asc Description: OpenPGP digital signature
Bug#896674: dovecot-core: new upstream release 2.3.1
Package: dovecot-core Version: 1:2.2.27-3+deb9u2 Severity: wishlist Hello, There's a new branch upstream, 2.3.x, that was started in december 2017 and the current latest release is 2.3.1, released in february and is considered stable by upstream. Version 2.3.x has at least one advantage over 2.2.x: it supports more modern password hashing schemes like bcrypt and ARGON2I/ARGON2ID It would be nice to see 2.3.1 get pushed to unstable so that it could eventually migrate to testing -- Package-specific info: -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE=en_CA:en (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dovecot-core depends on: ii adduser 3.115 ii init-system-helpers 1.48 ii libbz2-1.0 1.0.6-8.1 ii libc62.24-11+deb9u3 ii libexttextcat-2.0-0 3.4.4-2+b1 ii liblz4-1 0.0~r131-2+b1 ii liblzma5 5.2.2-1.2+b1 ii libpam-runtime 1.1.8-3.6 ii libpam0g 1.1.8-3.6 ii libssl1.11.1.0f-3+deb9u2 ii libstemmer0d 0+svn585-1+b2 ii libwrap0 7.6.q-26 ii lsb-base 9.20161125 ii openssl 1.1.0f-3+deb9u2 ii ucf 3.0036 ii zlib1g 1:1.2.8.dfsg-5 dovecot-core recommends no packages. Versions of packages dovecot-core suggests: pn dovecot-gssapi ii dovecot-imapd 1:2.2.27-3+deb9u2 pn dovecot-ldap pn dovecot-lmtpd pn dovecot-lucene ii dovecot-managesieved 1:2.2.27-3+deb9u2 ii dovecot-mysql 1:2.2.27-3+deb9u2 pn dovecot-pgsql pn dovecot-pop3d ii dovecot-sieve 1:2.2.27-3+deb9u2 pn dovecot-solr pn dovecot-sqlite ii ntp 1:4.2.8p10+dfsg-3+deb9u2 Versions of packages dovecot-core is related to: ii dovecot-core [dovecot-common] 1:2.2.27-3+deb9u2 pn dovecot-dbg pn dovecot-dev pn dovecot-gssapi ii dovecot-imapd 1:2.2.27-3+deb9u2 pn dovecot-ldap pn dovecot-lmtpd ii dovecot-managesieved 1:2.2.27-3+deb9u2 ii dovecot-mysql 1:2.2.27-3+deb9u2 pn dovecot-pgsql pn dovecot-pop3d ii dovecot-sieve 1:2.2.27-3+deb9u2 pn dovecot-sqlite -- no debconf information
Bug#928172: debian-security-support: fails to upgrade from 'testing': dpkg: error: error executing hook
On Mon, 29 Apr 2019 15:44:39 +0200 Santiago Vila wrote: > On Mon, Apr 29, 2019 at 01:22:18PM +, Holger Levsen wrote: > > if we now could please focus on #928172 and ignore #927450 for now, > > that would be great. (and "ignoring #927450" also means not mixing them > > up.) > > Let's focus on #928172 if you like. I try not to mix them up, but I > believe they are strongly related in the sense that the reason #928172 > is serious now is that the package in stable still has #927450. so, I'm currently in this situation where the package doesn't upgrade. and nothing else upgrades either because of this. is there a known way to work around the issue that the hook encounters in order to unblock my install? signature.asc Description: OpenPGP digital signature
Bug#928172: debian-security-support: fails to upgrade from 'testing': dpkg: error: error executing hook
Hi again! On Tue, 7 May 2019 02:24:59 -0400 Gabriel Filion wrote: > On Mon, 29 Apr 2019 15:44:39 +0200 Santiago Vila wrote: > > On Mon, Apr 29, 2019 at 01:22:18PM +, Holger Levsen wrote: > > > if we now could please focus on #928172 and ignore #927450 for now, > > > that would be great. (and "ignoring #927450" also means not mixing them > > > up.) > > > > Let's focus on #928172 if you like. I try not to mix them up, but I > > believe they are strongly related in the sense that the reason #928172 > > is serious now is that the package in stable still has #927450. > > so, I'm currently in this situation where the package doesn't upgrade. > and nothing else upgrades either because of this. > > is there a known way to work around the issue that the hook encounters > in order to unblock my install? I reveived some help from anarcat on irc to work around this issue and unblock upgrades on my system. While I think a fix would be nice for this issue, I'm reporting here how I got around this in case others end up in the same situation as I was and are looking to continue upgrading their sid machine: "apt remove debian-security-support" was triggering the hook and made it impossible to remove the package, but "apt purge ..." did work. so in order to unblock things one might want to run: apt purge debian-security-support apt update && apt upgrade apt install debian-security-support cheers! signature.asc Description: OpenPGP digital signature
Bug#952816: ITP: metadata-json-lint -- Utility to verify Puppet metadata.json files
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: metadata-json-lint Version : 2.2.0 Upstream Author : Vox Pupuli * URL : https://github.com/voxpupuli/metadata-json-lint * License : Apache-2.0 Programming Lang: Ruby Description : Utility to verify Puppet metadata.json files The metadata-json-lint tool validates and lints metadata.json files in Puppet modules against style guidelines from the Puppet Forge module metadata recommendations. metadata.json files are, as implied by the extension in the name, using a JSON syntax but a specific schema is expected to be used to format information in the data structure. They are helpful for specifying dependencies to Puppet modules and for making license and other such metadata parseable by a machine. This file is expected to be present when a module is published to the Puppet forge. This package is generally useful for Puppet module developers. It is also a dependency of puppet-development-kit, since it uses it directly to run verifications on modules. I plan to maintain this package within the ruby team and will ask for sponsorship from the team.
Bug#952819: ITP: facterdb -- Database of facts from many Facter versions on many Operating Systems
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: facterdb Version : 1.2.0 Upstream Author : Mickaël Canévet * URL : https://github.com/camptocamp/facterdb * License : Apache-2.0 Programming Lang: Ruby Description : Database of facts from many Facter versions on many Operating Systems The facterdb command can lookup its database with a set of versions of Facter and a set of Operating System distributions and versions and output the list of facts corresponding to those to the terminal. The output is formatted in JSON so it can be parsed by other scripts and programs. When used as a library, the same lookups can be done in a programmatic way. This means that you can use the facts in any Ruby program. Having access to lists of facts that mimic different setups is useful for running tests and making sure that features for those different setups are doing what's expected. This command and library is generally useful for Puppet module development and creating CI environments for running module unit tests. It's also used by the puppet-development-kit, so it is a dependency for this tool. I plan on maintaining this package from within the ruby team. I will ask for sponsorship from the team.
Bug#952823: ITP: jgrep -- Compare a list of json documents to a simple logical language and returns matches as output
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: jgrep Version : 1.5.2 Upstream Author : Pieter Loubser , Dominic Cleal , R.I. Pienaar * URL : https://github.com/ploubser/JSON-Grep * License : Apache-2.0 Programming Lang: Ruby Description : Compare a list of json documents to a simple logical language and returns matches as output JGrep is a command line tool and API for parsing JSON documents based on logical expressions. It returns a JSON datastructure that contains all of the matches from the original JSON document. Used as a library, you can filter results in a similar fashion from within your Ruby code. This tool is very similar in functionality to jq, but uses a matching syntax that is a lot simpler. This tool/library can be very useful on its own either directly on the command line or as a tool for building complex programs that need to filter JSON. It's also used as a dependency by facterdb, which itself is required for puppet-development-kit. I plan to maintain this package from within the ruby team. I will ask for sponsorship from the team.
Bug#939292: related RFP closed
FYI I saw that there was an RFP open for puppet-development-kit, which I had missed earlier: #879271 I've closed this other bug report since this one aims to fulfill it. signature.asc Description: OpenPGP digital signature
Bug#946852: SSH probe in smokeping does not work
Hi Kate, Thanks for this report. rsa1, wow, blast from the past. On 2019-12-16 10:00 a.m., Dawson, Kate wrote: > The SSH plugin in smokeping calls ssh-keyscan and expects to look for rsa1 > type keys on initialisation. However ssh-keyscan no longer supports rsa1. > This causes smokeping to fail to start. > Upstream version of the SSH plugin has removed the dependancy on rsa1 keys > > > https://github.com/oetiker/SmokePing/commit/62ac9fda04b994bbf4f97d3dd1cf8b92cf279e71 This patch was merged upstream in master after the release of 2.7.3 and there hasn't been a new release since then. I can apply it to the next package update so we get the fix before the next upstream release. it's a shame they added support for ecdsa but not ed25519 though :\ signature.asc Description: OpenPGP digital signature
Bug#951018: ITP: ruby-tty-spinner -- Library for showing a spinner icon for terminal tasks that have non-deterministic time frame
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: ruby-tty-spinner Version : 0.9.3 Upstream Author : Piotr Murach * URL : https://ttytoolkit.org/ * License : expat Programming Lang: Ruby Description : Library for showing a spinner icon for terminal tasks that have non-deterministic time frame tty-spinner provides a selection of different text-based animations that can be shown when the user is waiting on a task run in terminal that will end some time that is not known in the future, or for which the completion timestamp can only be estimated. Those tasks will usually be waiting for some I/O, for example a download or a task that was requested from a service that will give an answer whenever the response is ready. This package is currently required for packaging puppet-developement-kit (pdk), but might be needed for other ruby-based scripts expected to run in a terminal. I plan on maintaining this library within the ruby team. I will ask for sponsorship from within the team to ensure that I follow the team's policies properly.
Bug#951097: ITP: ruby-spdx-licenses -- Library for looking up and identifying SPDX licences
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: ruby-spdx-licenses Version : 1.2.0 Upstream Author : Dominic Cleal * URL : https://github.com/domcleal/spdx-licenses * License : Expat Programming Lang: Ruby Description : Library for looking up and identifying SPDX licences This library can lookup a list of SPDX licences on spdx.org, and provide them as a list of information that can be handled by your code. You can also use this to lookup whether a certain licence is an SPDX license or not, and thus programatically identify certain licences in code or other structured information. This library is a dependency to metadata-json-lint, which in turn is needed for packaging puppet-development-kit (pdk) which I'm working towards packaging. I intend to maintain this within the ruby team, and will ask for a sponsor within the team.
Bug#951098: ITP: ruby-rspec-puppet-facts -- Library containing facts from many Facter versions on many Operating Systems
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: ruby-rspec-puppet-facts Version : 1.10.0 Upstream Author : Mickaël Canévet * URL : https://github.com/mcanevet/rspec-puppet-facts * License : Apache-2.0 Programming Lang: Ruby Description : Library containing facts from many Facter versions on many Operating Systems With this library, simplify your unit tests by looping on every supported Operating System and populating facts (provided by facterdb). This simplifies unit testing because you don't need to specify the facts yourself. This library is very useful for writing tests when working on a puppet module. It also makes it very fast to setup a CI environment for your modules. This library is used by puppet-development-kit as a requirement in order to provide an easier framework and workflow for puppet module development. I intend to maintain this module within the ruby team and I will ask for sponsorship within the team.
Bug#941942: ganeti-instance-debootstrap: provide "gpt" as an option to PARTITION_STYLE
Package: ganeti-instance-debootstrap Version: 0.16-6 Severity: wishlist Tags: upstream Hi, I couldn't find an upstream bug reporting page so I'll send it here. If you have a better idea where the bug tracking happens upstream fo this project, could you please forward this? Currently the option PARTITION_STYLE that one can use in a file under /etc/ganeti/instance-debootstrap/variants/ only offers values "none" and "msdos". This means that it's impossible to create VMs that have disks that are bigger than 2Tb. It would be nice to be able to make gpt-style partitions with instance-debootstrap. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ganeti-instance-debootstrap depends on: ii debootstrap 1.0.116 pn dump ii e2fsprogs1.45.4-1 ii fdisk2.34-0.1 ii kpartx 0.7.9-3+b2 ii util-linux 2.34-0.1 ganeti-instance-debootstrap recommends no packages. ganeti-instance-debootstrap suggests no packages.
Bug#931044: installing python3.4 fails
Hi, Since the bug report was indicating that the issue was fixed in 3.4.2-1+deb8u4, I've tried to apply upgrades and it seems to have upgraded successfully. So the fix seems to work for me! signature.asc Description: OpenPGP digital signature
Bug#925444: smokeping: --pid-dir doesn't worj as expected
Hi again Bertrand, On Tue, 2 Apr 2019 10:46:38 -0400 Gabriel Filion wrote: > On 2019-03-26 3:26 p.m., BERTRAND Joël wrote: > >> Did you recently upgrade smokeping? if so what version were you > >> using before? (maybe check your dpkg logs for signs of upgrade of > >> the smokeping package) > > Yes, I have. > > > > -> 2019-03-17 03:26:38 upgrade smokeping:all 2.7.2-3 2.7.3-2 If this bug is still affecting your install, could you paste the contents of the file /lib/systemd/system/smokeping.service ? also, which version of systemd are you running? Normally there should be a line like the following that tells systemd to create the /run/somkeping directory: RuntimeDirectory=smokeping signature.asc Description: OpenPGP digital signature
Bug#929515: smokeping: CSS and js files not found
Hi Keith, I'm terribly sorry for the time it took to respond to your bug report. On Sat, 25 May 2019 10:09:27 +0100 Keith Edmunds wrote: > Package: smokeping > Version: 2.7.3-2 > Severity: important > > System was upgraded from Stretch to Buster, with smokeping working on Stretch. > > After the upgrade, it's evident from the display that there is a CSS problem. > > Chrome devtools reports: > > GET http://ws.midnighthax.com/cgi-bin/css/smokeping-screen.css > net::ERR_ABORTED 404 (Not Found) When I install smokeping on a vanilla buster VM I see that the CSS files come from this kind of URL (e.g. there's no "cgi-bin" in the path): http://192.168.121.33/smokeping/css/smokeping-screen.css If you use "View source" on the web page, can you paste the lines around the top where the page points to smokeping-screen.css and smokeping-print.css On my end, it looks like this: Lastly, this might be "too late" since your bug report was sent so long ago.. but maybe running a force refresh on the page (ctrl-f5 on firefox) could clear up the lack of css files. I've just tested installing smokeping on a vanilla stretch VM, then upgrading to buster, and (other than systemd being unhappy about the already running instance) I can see the CSS just fine.. maybe one possibility is if there was a manual change to the file /etc/apache2/conf-available/smokeping.conf signature.asc Description: OpenPGP digital signature
Bug#656369: smokeping: slave mode has fewer dependencies
Hello Simon, On Wed, 18 Jan 2012 19:21:26 + Simon Wilcox wrote: > Smokeping has the ability to run in a master/slave configuration. > > In the slave configuration data is sent to a master server and a local > apache installation is not required. > > We want to install smokeping on devices that should not have apache > installed, to use as slaves to a master server but we can't do this with > the current dependency chain. > > May I request that the smokeping package is divided into two, with a > data collector package separate from a web-UI package. Or possibly that > you consider a separate smokeping-slave package that would leave the > current smokeping package untouched. > > I know that we could roll our own package or install outside of the > package system altogether so perhaps you may wish to re-grade this > ticket to a wishlist request rather than a bug but I've filed it as such > since we can't use the package for our use case at this time. > > Thank you for the time and effort you give to the Debian project and for > taking the time to consider this bug. This bug report has been open forever. I've taken a look at this and I believe that the state of the package has changed in a way that could permit installing smokeping without apache: apache2 is currently a "Recommends" for smokeping (it has been at least since the version that was in jessie). so you can install the package using this to avoid apache: apt install --no-install-recommends smokeping Note that in that case you might need to manually install some additional packages if you need them: dnsutils, echoping and libsocket6-perl are also recommends and won't be installed because of the option. I believe that using this option, you can create an install of smokeping for using it with the "slave" mode without having apache on the same machine. Cheers! signature.asc Description: OpenPGP digital signature
Bug#940587: cloud.debian.org: additional Vagrant boxes with puppet/ansible pre-installed?
Package: cloud.debian.org Severity: wishlist Hi there, I've been holding back on using the debian/* boxes with vagrant mostly since there's no puppet pre-installed in the boxes. I know that, as documented in the wiki, I can install puppet with a shell provisioner, but doing that on every boot makes things very much slower. I could also start from the vanilla box, install puppet and then repackage into a new box locally, but the point of using a public box is so that other contributers can start with exactly the same environment. I'm also aware that pre-installing those would make the images much bigger, and I can see the point of having a very tiny completely vanilla debian image. I was wondering if folks maintaining the vagrant boxes would be willing to publish additional images that would have puppet/ansible pre-installed with the debian packages from each release's package repository? cheers! -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#940587: cloud.debian.org: additional Vagrant boxes with puppet/ansible pre-installed?
Hi, On 2019-09-18 1:36 a.m., Geert Stappers wrote: > On Tue, Sep 17, 2019 at 10:52:54AM -0400, Gabriel Filion wrote: >> I was wondering if folks maintaining the vagrant boxes would be willing to >> publish additional images that would have puppet/ansible pre-installed with >> the debian packages from each release's package repository? > > I also don't understand how cloudinit works. > > There is https://cloudinit.readthedocs.io/en/latest/ > But it lacks what it makes it tick. > > Nowhere is documented > * how it starts (what triggers the start) > * how "client" finds "server" > * why "client" trusts "server" I don't quite understand how this question is related to building Vagrant boxes. According to the documentation[0] the boxes are generated using a Packer template, and cloudinit is mentioned nowhere on that wiki page. [0]: https://wiki.debian.org/Teams/Cloud/VagrantBaseBoxes#Build_process signature.asc Description: OpenPGP digital signature
Bug#941327: ruby-rspec-puppet: new upstream release 2.7.5
Package: ruby-rspec-puppet Version: 2.6.1-1 Severity: normal Hi, The version of rspec-puppet that's currently in sid is quite old: it dates back to 2017. Upstream has seen a good number of releases since then and it would be nice to have a fresher version of this code in unstable. Cheers! -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ruby-rspec-puppet depends on: ii puppet-common 5.5.10-4 ii ruby 1:2.5.1 ii ruby-rspec 3.8.0c0e1m0s0-1 ruby-rspec-puppet recommends no packages. ruby-rspec-puppet suggests no packages. -- no debconf information
Bug#941331: rubocop: new upstream release 0.74.0
Package: rubocop Version: 0.52.1+dfsg-1 Severity: normal Hello, There's been multiple upstream releases since the currently packaged version. The current latest release is 0.74.0. version 0.52 was released on december 12th 2017 -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rubocop depends on: ii ruby1:2.5.1 ii ruby-parallel 1.12.1-2 ii ruby-powerpack 0.1.1-4 ii ruby-progressbar1.9.0-2 ii ruby-rainbow3.0.0-2 ii ruby-unicode-display-width 1.1.3-1 ii ruby-whitequark-parser 2.4.0.2-1 rubocop recommends no packages. rubocop suggests no packages. -- no debconf information
Bug#941396: ITP: ruby-pastel -- Terminal strings styling with intuitive and clean API
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: ruby-pastel Version : 0.7.3 Upstream Author : Piotr Murach * URL : https://piotrmurach.github.io/tty/ * License : expat Programming Lang: Ruby Description : Terminal strings styling with intuitive and clean API Pastel is a ruby library that helps to colorize output on the terminal. It is minimal and focused to work in all terminal emulators. It provides provides independent coloring component for TTY toolkit. This package is required as a dependency to puppet-development-kit. I plan to maintain this package as part of the ruby team, and will request sponsoring from within the team to ensure that I respect their policies.
Bug#941398: ITP: ruby-equatable -- Ruby module that adds explicit indications of whether objects can be compared in equality checks
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: ruby-equatable Version : 0.6.1 Upstream Author : Piotr Murach * URL : https://github.com/piotrmurach/equatable * License : expat Programming Lang: Ruby Description : Ruby module that adds explicit indications of whether objects can be compared in equality checks Equatable extends Ruby objects with equality comparison and inspection methods. By including this module, a class indicates that its instances have explicit general contracts for `hash`, `==` and `eql?` methods. Specifically eql? contract requires that it implements an equivalence relation. By default each instance of the class is equal only to itself. This is a right behaviour when you have distinct objects. However, it is the responsibility of any class to clearly define their equality. Failure to do so may prevent instances to behave as expected when for instance Array#uniq is invoked or when they are used as Hash keys. This package is a requirement of ruby-pastel, which if we move further up the requirements tree, is needed in order to be able to package puppet-development-kit. I plan to maintain this package with the ruby team. I will ask for sponsorship from within this team so that I'm sure that my package will respect the team's policies.
Bug#941401: ITP: ruby-tty-color -- Ruby library that provides terminal color capabilities detection
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: ruby-tty-color Version : 0.5.0 Upstream Author : Piotr Murach * URL : http://piotrmurach.github.io/tty * License : expat Programming Lang: Ruby Description : Ruby library that provides terminal color capabilities detection tty-color is a simple library that provides independent color support detection. It is a component for TTY toolkit. This is a requirement to ruby-pastel, which is needed to create the package puppet-development-kit. I plan on maintaining this package with the ruby team. I will ask for sponsorship within that team so that I can ensure that I respect the team's policies.
Bug#941403: ITP: ruby-tty-reader -- A set of methods for processing keyboard input in character, line and multiline modes
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: ruby-tty-reader Version : 0.6.0 Upstream Author : Piotr Murach * URL : https://ttytoolkit.org/ * License : expat Programming Lang: Ruby Description : A set of methods for processing keyboard input in character, line and multiline modes tty-reader is a pure Ruby library that is part of the TTY Toolkit that provides a set of methods for processing keyboard input in character, line and multiline modes. It maintains history of entered input with an ability to recall and re-edit those inputs. It lets you register to listen for keystroke events and trigger custom key events yourself. This library is required by ruby-tty-prompt, which in turn is necessary for packaging puppet-development-kit. I plan on maintining this package with the ruby team. I will ask for sponsorship within the team so that I can ensure that I'll respect the team's policies.
Bug#941404: ITP: ruby-tty-cursor -- Ruby library to help move the terminal cursor around and manipulate text by using intuitive method calls
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: ruby-tty-cursor Version : 0.7.0 Upstream Author : Piotr Murach * URL : https://ttytoolkit.org/ * License : expat Programming Lang: Ruby Description : Ruby library to help move the terminal cursor around and manipulate text by using intuitive method calls tty-cursor makes it easy to programatically move the cursor in a terminal without needing to know terminal control codes. It is a component of the TTY Toolkit. This library is required by ruby-tty-reader, which in the end is needed for packaging puppet-development-kit. I plan on maintaining this package with the ruby team. I will ask for sponsorship from within the team to ensure that I follow the team's policies properly.
Bug#941405: ITP: ruby-tty-screen -- Ruby library that detects terminal screen size for many platforms
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: ruby-tty-screen Version : 0.7.0 Upstream Author : Piotr Murach * URL : https://ttytoolkit.org/ * License : expat Programming Lang: Ruby Description : Ruby library that detects terminal screen size for many platforms tty-screen implements terminal screen size detection which works on Linux, OS X and Windows/Cygwin platforms and supports MRI, JRuby and Rubinius interpreters. It is a component of the TTY Toolkit. This library is required by ruby-tty-reader, which in the end is needed for packaging puppet-development-kit. I plan on maintaining this package with the ruby team. I will ask for sponsorship from within the team to ensure that I follow the team's policies.
Bug#934334: munin-plugins-extra: please package asterisk multigraph plugin from munin-contrib
Package: munin-plugins-extra Version: 2.0.49-1 Severity: normal Hello, I've been using the multigraph plugin for asterisk that's present in the munin-contrib repository for a number of years and find it nice. I was wondering if this package would be well suited for including it. For what it's worth, the asterisk_* plugins that are shipped with the package don't seem to work with the version of asterisk in buster. The plugin is this one: https://github.com/munin-monitoring/contrib/blob/master/plugins/asterisk/asterisk However, I've had to fix the plugin to make it parse the AMI response correctly for newer versions of asterisk. I would recommend to wait for the changes in the following PR to be merged in: https://github.com/munin-monitoring/contrib/pull/1005 Cheers! -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.UTF-8), LANGUAGE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages munin-plugins-extra depends on: ii munin-common 2.0.49-1 ii perl 5.28.1-6 munin-plugins-extra recommends no packages. Versions of packages munin-plugins-extra suggests: pn libcache-memcached-perl ii liblwp-useragent-determined-perl 1.07-1 ii libnet-ip-perl1.26-2 ii libnet-netmask-perl 1.9104-1 ii libnet-snmp-perl 6.0.1-5 pn libnet-telnet-perl pn libtext-csv-xs-perl ii libxml-libxml-perl2.0134+dfsg-1 ii python3 3.7.3-1 -- Configuration Files: /etc/munin/plugin-conf.d/dhcpd3 [Errno 2] No such file or directory: '/etc/munin/plugin-conf.d/dhcpd3' /etc/munin/plugin-conf.d/spamstats [Errno 2] No such file or directory: '/etc/munin/plugin-conf.d/spamstats' -- no debconf information
Bug#934170: smokeping: Alert edgetrigger functionality is broken)
Hi there Gerald, On 2019-08-07 2:09 p.m., Gerald Turner wrote: > Control: tags -1 + patch > > I've created a patch which restores "prevmatch" to being a boolean, > fixing the edgetrigger alerts. I built and tested the package with this > patch. > > The only side-effect is the aformentioned syslog message change is > marginally affected: > > smokeping[6642]: Alert full-loss was cleared for dns.ns6-gandi-net loss: > 0%%, 0%%, 0%%, 0%%, 0%%, 0%%, 0%%, 100%%, 100%%, 100%%, 100%%, 0%%(0/5) rtt: > 153ms, 155ms, 156ms, 155ms, 155ms, 156ms, 155ms, U, U, U, U, 155ms prevmatch: > 1 comment: 100%% packet loss > > ^ with the patch, the substring "prevmatch: 1", will always be one. Thanks for your submission! > Fix edgetrigger alerts as discussed in: > https://github.com/oetiker/SmokePing/issues/183 It seems to me that some folks reported in this issue being able to stop the influx of emails by chaning the "format" option where edgetrigger is set. Did you try applying this solution? I'm mostly hesitant to apply a patch on the software itself and diverge from upstream if upstream doesn't seem to be willing to apply the same patch (or -- another case -- if the patch is not useful solely for making packaging possible but would not be accepted upstream). If the change of "format" doesn't work for you, maybe then I can help you in applying some pressure upstream to merge that patch in. But for this we'd need to have a clearly defined case where the solution/workaround proposed by Tobias doesn't fix the issue. Cheers! signature.asc Description: OpenPGP digital signature
Bug#934170: smokeping: Alert edgetrigger functionality is broken)
On 2019-08-12 10:43 a.m., Gabriel Filion wrote: > It seems to me that some folks reported in this issue being able to stop > the influx of emails by chaning the "format" option where edgetrigger is > set. Did you try applying this solution? woops! sorry for the imprecision. it's actually the "pattern" option. (I read the upstream issue this week-end but couldn't reply until today so there was a mix bowl of salad in my head instead of a brain) signature.asc Description: OpenPGP digital signature
Bug#923892: puppet: package deploys ruby code but no gem
Package: puppet Version: 5.5.10-1 Severity: normal Hello, I recently saw that the "puppet" package deploys the ruby code for puppet, but does not install that code as a gem. This means that other packages that should depend on puppet cannot satisfy their dependencies, and debian packages need to patch gemspecs in order to remove that dependency. It also means that if you install some code manually with "gem install", gem will not know that a copy of the puppet ruby code is already installed and will install a new(er) version as a dependency. I reckon that there might be a reason for this, and that I may simply not know about the reason. Cheers! -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages puppet depends on: ii adduser 3.118 ii facter 3.11.0-1.1+b1 ii hiera3.2.0-2 ii init-system-helpers 1.56+nmu1 ii lsb-base 10.2018112800 ii ruby 1:2.5.1 ii ruby-augeas 1:0.5.0-3+b6 ii ruby-deep-merge 1.1.1-1 ii ruby-shadow 2.5.0-1+b1 Versions of packages puppet recommends: ii debconf-utils 1.5.70 ii lsb-release10.2018112800 ii ruby-selinux 2.8-1+b1 Versions of packages puppet suggests: pn ruby-hocon pn ruby-rrd -- no debconf information
Bug#924285: ITP: vagrant-librarian-puppet -- A Vagrant plugin to install Puppet modules using Librarian-Puppet
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: vagrant-librarian-puppet Version : 0.9.2 Upstream Author : Vox Pupuli * URL : https://github.com/voxpupuli/vagrant-librarian-puppet * License : MIT Programming Lang: Ruby Description : A Vagrant plugin to install Puppet modules using Librarian-Puppet vagrant-librarian-puppet is a plugin for Vagrant that will automatically run librarian-puppet before any provisioning step. It looks for a Puppetfile in the configured directory and uses that file with librarian-puppet. More details: - This plugin automates management of module dependencies when testing puppet modules, or simply when maintaining your local test VM for day-to-day puppet development. I removes the need to remember to install new modules with librarian-puppet after having pulled in other people's changes on the Puppetfile. - It is not a dependency for another package - I so far use it for testing individual puppet modules that I maintain, and to make it easier to test changes before committing. I also intend to use it at work to reduce friction around keeping modules up to date in the local dev VMs. - I don't know of another package that provides such functionality. It's also the only vagrant plugin that I know can help automate this. - Since I'm not a DD or a DM, I am planning on asking a friend who is a Debian Developer to help me out with shaping the package so that it's acceptable for debian. I would then intend to ask the ruby packaging team if they are willing to make this one of the team packages and I would continue maintaining it through the team.
Bug#902413: Systemd unit is also pointing to /var/run instead of /run
Hello, Additionally to what wavexx reported, the systemd unit file is also pointing PIDFile= inside the deprecated /var/run instead of /run. The init script is also pointing to that directory. I'm reporting this here since it's related to why that tmpfiles line exists. However, this would imply a change upstream I suggest that the following changes for the upstream file. arguably though many lines of python code also reference /var/run and should be changed, too. -8<8<- --- a/files/fail2ban.service.in 2019-03-17 01:12:08.0 -0400 +++ b/files/fail2ban.service.in 2019-03-17 01:08:05.339634130 -0400 @@ -6,13 +6,13 @@ [Service] Type=simple -ExecStartPre=/bin/mkdir -p /var/run/fail2ban ExecStart=@BINDIR@/fail2ban-server -xf start # if should be logged in systemd journal, use following line or set logtarget to sysout in fail2ban.local # ExecStart=@BINDIR@/fail2ban-server -xf --logtarget=sysout start ExecStop=@BINDIR@/fail2ban-client stop ExecReload=@BINDIR@/fail2ban-client reload -PIDFile=/var/run/fail2ban/fail2ban.pid +RuntimeDirectory=fail2ban +PIDFile=/run/fail2ban/fail2ban.pid Restart=on-failure RestartPreventExitStatus=0 255 --- a/files/debian-initd2019-03-17 01:12:08.0 -0400 +++ b/files/debian-initd2019-03-17 01:14:18.993738399 -0400 @@ -34,7 +34,7 @@ # Ad-hoc way to parse out socket file name SOCKFILE=`grep -h '^[^#]*socket *=' /etc/$NAME/$NAME.conf /etc/$NAME/$NAME.local 2>/dev/null \ | tail -n 1 | sed -e 's/.*socket *= *//g' -e 's/ *$//g'` -[ -z "$SOCKFILE" ] && SOCKFILE='/var/run/fail2ban.sock' +[ -z "$SOCKFILE" ] && SOCKFILE='/run/fail2ban.sock' # Exit if the package is not installed [ -x "$DAEMON" ] || exit 0 @@ -109,13 +109,13 @@ DAEMON_ARGS="$DAEMON_ARGS -x" fi - # Assure that /var/run/fail2ban exists - [ -d /var/run/fail2ban ] || mkdir -p /var/run/fail2ban + # Assure that /run/fail2ban exists + [ -d /run/fail2ban ] || mkdir -p /run/fail2ban if [ "$FAIL2BAN_USER" != "root" ]; then # Make the socket directory, IP lists and fail2ban log # files writable by fail2ban - chown "$FAIL2BAN_USER" /var/run/fail2ban + chown "$FAIL2BAN_USER" /run/fail2ban # Create the logfile if it doesn't exist touch /var/log/fail2ban.log chown "$FAIL2BAN_USER" /var/log/fail2ban.log signature.asc Description: OpenPGP digital signature
Bug#939292: ITP: ruby-pdk -- A CLI to facilitate easy, unified development workflows for Puppet modules
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: ruby-pdk Version : 1.13.0 Upstream Author : Puppet, Inc. * URL : https://github.com/puppetlabs/pdk * License : Apache License 2.0 Programming Lang: Ruby Description : A CLI to facilitate easy, unified development workflows for Puppet modules The Puppet Development Kit (PDK) includes key Puppet code development and testing tools for Linux, Windows, and OS X workstations, so you can install one package with the tools you need to create and validate new modules. PDK includes testing tools, a complete module skeleton, and command line tools to help you create, validate, and run tests on Puppet modules. PDK also includes all dependencies needed for its use. This package is the very useful helper that's been adopted by the puppet community to help out building new modules and maintaining them. It also helps with publishing modules to forge.puppet.com, which is the community module repository. Puppet, up to the 5.x branch, has had a builtin command "puppet module build" that can create a tar archive with the relevant files placed in a layout that's acceptable for publication on forge.puppet.com. This builtin command is marked as deprecated in puppet 5.x and was removed in the 6.x branch. This means that puppet users now need to use pdk for publishing their modules. pdk also interacts with other tools, some of which are already packaged in debian, to help users validate the syntax and code style of theire modules but also to write unit tests. the upstream project vendors all of those additional tools and the ones that are not yet packaged yet would need to be packaged separately for debian. This currently includes the metadata-json-lint and rspec-puppet-facts ruby gems I plan to maintain this package and the dependencies that I will need to package additionally within the ruby team.
Bug#939292: ITP: ruby-pdk -- A CLI to facilitate easy, unified development workflows for Puppet modules
On Mon, 02 Sep 2019 17:11:44 -0400 Gabriel Filion wrote: > Package: wnpp > Severity: wishlist > Owner: Gabriel Filion > > * Package name: ruby-pdk I've discussed the name a bit on different channels today and the folks in the ruby team told me that calling it "ruby-pdk" would be a mistake since it's not a library but rather a binary. Also, just calling the package "pdk" seems to be too confusing since it sounds very generic. So for now the consensus seems to point towards naming this package "puppet-development-kit" instead in order to make it obvious what it is and easy to find. > Version : 1.13.0 > Upstream Author : Puppet, Inc. > * URL : https://github.com/puppetlabs/pdk > * License : Apache License 2.0 > Programming Lang: Ruby > Description : A CLI to facilitate easy, unified development workflows > for Puppet modules > > The Puppet Development Kit (PDK) includes key Puppet code development and > testing tools for Linux, Windows, and OS X workstations, so you can install > one package with the tools you need to create and validate new modules. > > PDK includes testing tools, a complete module skeleton, and command line tools > to help you create, validate, and run tests on Puppet modules. PDK also > includes all dependencies needed for its use. > > > This package is the very useful helper that's been adopted by the puppet > community to help out building new modules and maintaining them. It also helps > with publishing modules to forge.puppet.com, which is the community module > repository. > > Puppet, up to the 5.x branch, has had a builtin command "puppet module build" > that can create a tar archive with the relevant files placed in a layout > that's acceptable for publication on forge.puppet.com. This builtin command > is marked as deprecated in puppet 5.x and was removed in the 6.x branch. This > means that puppet users now need to use pdk for publishing their modules. > > pdk also interacts with other tools, some of which are already packaged in > debian, to help users validate the syntax and code style of theire modules but > also to write unit tests. > > the upstream project vendors all of those additional tools and the ones that > are not yet packaged yet would need to be packaged separately for debian. This > currently includes the metadata-json-lint and rspec-puppet-facts ruby gems > > I plan to maintain this package and the dependencies that I will need to > package additionally within the ruby team. > > signature.asc Description: OpenPGP digital signature
Bug#939302: ITP: ruby-pathspec -- Ruby library to match path patterns such as gitignore
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: ruby-pathspec Version : 0.2.1 Upstream Author : Brandon High * URL : https://github.com/highb/pathspec-ruby * License : Apache License 2.0 Programming Lang: Ruby Description : Ruby library to match path patterns such as gitignore This library implements matching of path patterns as they exist in gitignore files. With this library you can load a gitignore file, and then verify that a path matches one of the patterns listed in the file. You can also find out all of the files maching different patterns in a whole hierarchy of a filesystem. This library is a ruby port of the python library with the same name. This package is required by puppet-development-kit (pdk) that I'm currently working to package. I plan on maintaining this package within the ruby team. Since I do not have DM or DD status, I will need a sponsor for the package which I will ask in the ruby team once it's ready.
Bug#939306: ITP: ruby-tty-prompt -- Beautiful and powerful interactive command line prompt
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: ruby-tty-prompt Version : 0.19.0 Upstream Author : Piotr Murach * URL : https://ttytoolkit.org/ * License : Expat Programming Lang: Ruby Description : Beautiful and powerful interactive command line prompt TTY::Prompt provides tools to shaping a terminal prompt for your application. It has a robust API for getting and validating complex inputs, has a number of prompt types to gather user input, provides user-friendly error messages, has an intuitive DSL for creating complex menus, can manage paging of long menus and supports Linux, OS X, FreeBSD and Windows systems. This package is needed as a dependency to puppet-development-kit, which I'm currently working to package. I plan on maintaining this package within the ruby team, and will ask the team for sponsorship since I don't have DM or DD status yet.
Bug#939307: ITP: ruby-necromancer -- Conversion from one object type to another with a bit of black magic
Package: wnpp Severity: wishlist Owner: Gabriel Filion * Package name: ruby-necromancer Version : 0.5.0 Upstream Author : Piotr Murach * URL : https://github.com/piotrmurach/necromancer * License : Expat Programming Lang: Ruby Description : Conversion from one object type to another with a bit of black magic Necromancer provides independent type conversion component for TTY toolkit. Conversion between Ruby core types frequently comes up in projects but is solved by half-baked solutions. This library aims to provide an independent and extensible API to support a robust and generic way to convert between core Ruby types. This is a requirement for ruby-tty-prompt, which in turn is a requirement for puppet-development-kit, which I'm working to package. I intend to maintain this package within the ruby team, and will ask for a sponsor within the team.
Bug#940048: nagios-plugins-contrib: debsecan in the "recommends" should be moved to "suggests"
Package: nagios-plugins-contrib Version: 24.20190301 Severity: normal Hi, Ever since the package version in buster, debsecan gets installed automatically when you let "recommends" install. It also means that it gets installed automatically during a dist-upgrade to buster. This means that root starts receiving emails daily from that tool even though one is not using debsecan or expecting to use check_debsecan. I would argue that because of those automatic emails getting sent out by default, debsecan should be moved out to the "suggests" section of this package. -- System Information: Debian Release: 10.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled nagios-plugins-contrib depends on no packages. Versions of packages nagios-plugins-contrib recommends: ii bind9-host 1:9.11.5.P4+dfsg-5 ii binutils 2.31.1-16 ii curl 7.64.0-4 pn debsecan ii file 1:5.35-4 pn freeipmi-tools ii libc6 2.28-10 pn libdata-validate-domain-perl pn libdata-validate-ip-perl ii libdate-manip-perl 6.76-1 pn libdbd-mysql-perl ii libio-socket-ssl-perl 2.060-3 ii libipc-run-perl20180523.0-1 ii liblocale-gettext-perl 1.07-3+b4 pn liblwp-useragent-determined-perl pn libmail-imapclient-perl pn libmemcached11 pn libmemcachedutil2 pn libmonitoring-plugin-perl | libnagios-plugin-perl pn libnet-cups-perl ii libnet-dns-perl1.19-1 ii libnet-dns-sec-perl1.11-1 ii libnet-smtp-ssl-perl 1.04-1 pn libnet-smtp-tls-perl pn libnet-smtpauth-perl pn libnet-snmp-perl ii libnet-ssleay-perl 1.85-2+b1 ii libreadonly-perl 2.050-1 pn libredis-perl ii libsocket-perl 2.029-1 ii libtimedate-perl 2.3000-2 pn libvarnishapi2 pn libwebinject-perl ii libxml-simple-perl 2.25-1 pn libyaml-syck-perl ii lsof 4.91+dfsg-1 pn nagios-plugins-basic ii openssl1.1.1c-1 ii perl 5.28.1-6 ii python 2.7.16-1 pn python-pymongo ii ruby 1:2.5.1 ii snmp 5.7.3+dfsg-5 ii whois 5.4.3 Versions of packages nagios-plugins-contrib suggests: pn backuppc pn cciss-vol-status pn expect ii libsys-virt-perl 5.0.0-1 pn moreutils pn mpt-status pn nagios-plugin-check-multi pn percona-toolkit pn perl-doc ii python2.7 2.7.16-2 pn smstools
Bug#860264: similar bug with sshfs, maybe in systemd/ifupdown
Hi there, On 2019-01-29 9:26 p.m., Antoine Beaupre wrote: > We'd need an easier way to reproduce this however. Has anyone worked on > getting some virtual machine images up to try and orchestrate a > reproducer for this? That would be ideal but a step-by-step set of > minimal instructions starting from a clean install would be an > acceptable compromise. The bug is hard to reproduce since it's a run condition that might not happen sometimes. The simplest way to reproduce is to have an nfs (or maybe sshfs if it's possible to reproduce with this) server, then on a buster machine to add the nfs mount as a line to the fstab file, then reboot. when the mount does not work, it is quite apparent: the boot process hangs for some time before NFS decides to timeout. signature.asc Description: OpenPGP digital signature
Bug#917474: librarian-puppet: documentation included with binary and package mostly useless and lacking lots of information
Package: librarian-puppet Version: 3.0.0-1 Severity: normal Tags: upstream Hi there, Thanks for maintaining this package! it's super useful for us. I find it hard to know how to use and configure this ruby script. The main "binary" itself has some information with the "help" subcommand but it's far from touching all necessary subjects. The main man page for the package was probably auto-generated because upstream doesn't provide one, and the information in the man page is extremely basic and most incomplete. For one thing, the package doesn't ship the README.md file in /usr/shared/doc/librarian-puppet. This would help getting at least a good portion of information that upstream already has documented at least there. a man page could be based off of a lot of information in the readme. it would be best if upstream could provide a man page, though. The parts that are lacking even upstream are: * there is no documentation of what the Puppetfile format and syntax is * there is no documentation at all on configuration options that can be used cheers! -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages librarian-puppet depends on: ii puppet 5.5.8-1 ii ruby 1:2.5.1 ii ruby-json 2.1.0+dfsg-2+b1 ii ruby-librarian 0.6.4-1 ii ruby-puppet-forge 2.2.9-2 ii ruby-rsync 1.0.9-1 librarian-puppet recommends no packages. librarian-puppet suggests no packages. -- no debconf information
Bug#935313: missing ebtables dependency
Hello, On Wed, 21 Aug 2019 10:16:26 -0400 Antoine Beaupre wrote: > Vagrant, using the libvirt backend, started failing me recently, with > something like this: > > anarcat@curie:stretch64(master)$ vagrant up --provider libvirt > Bringing machine 'default' up with 'libvirt' provider... > ==> default: Checking if box 'debian/stretch64' version '9.9.0' is up to > date... > Error while activating network: Call to virNetworkCreate failed: internal > error: Failed to initialize a valid firewall backend. > [1]anarcat@curie:stretch64(master)$ > Restarting libvirtd, however, did provide some insightful input: > > [...] > aoû 21 10:10:05 curie systemd[1]: Started Virtualization daemon. > aoû 21 10:10:05 curie libvirtd[31223]: direct firewall backend requested, but > /usr/sbin/ebtables is not available: Aucun fichier ou dossier de ce type > aoû 21 10:10:05 curie libvirtd[31223]: internal error: Failed to initialize a > valid firewall backend fwiw I'm running vagrant + libvirt + vagrant-libvirt in debian sid and I don't have the ebtables package installed. networking is still functioning. Since buster, nftables is now used by default. the iptables package is now installing nftables wrappers so that one is not mixing nftables with iptables kernel subsystems. # update-alternatives --list ebtables /usr/sbin/ebtables-nft $ dpkg -S /usr/sbin/ebtables-nft iptables: /usr/sbin/ebtables-nft that would explain why the libvirt package does not depend on the ebtables package. is it possible that your "alternative" for ebtables was somehow blasted out? e.g. if you try removing the ebtables package and then running: # update-alternatives --set ebtables /usr/sbin/ebtables-nft does it make your libvirt setup function properly? if so, then maybe you might want to check other "alternatives" provided by iptables so that they use the nftables wrappers. Here's what I have on my system: $ ls -l /etc/alternatives/|grep -- -nft lrwxrwxrwx 1 root root 23 Dec 22 2018 arptables -> /usr/sbin/arptables-nft lrwxrwxrwx 1 root root 31 Dec 22 2018 arptables-restore -> /usr/sbin/arptables-nft-restore lrwxrwxrwx 1 root root 28 Dec 22 2018 arptables-save -> /usr/sbin/arptables-nft-save lrwxrwxrwx 1 root root 22 Dec 22 2018 ebtables -> /usr/sbin/ebtables-nft lrwxrwxrwx 1 root root 30 Dec 22 2018 ebtables-restore -> /usr/sbin/ebtables-nft-restore lrwxrwxrwx 1 root root 27 Dec 22 2018 ebtables-save -> /usr/sbin/ebtables-nft-save lrwxrwxrwx 1 root root 23 Dec 22 2018 ip6tables -> /usr/sbin/ip6tables-nft lrwxrwxrwx 1 root root 31 Dec 22 2018 ip6tables-restore -> /usr/sbin/ip6tables-nft-restore lrwxrwxrwx 1 root root 28 Dec 22 2018 ip6tables-save -> /usr/sbin/ip6tables-nft-save lrwxrwxrwx 1 root root 22 Dec 22 2018 iptables -> /usr/sbin/iptables-nft lrwxrwxrwx 1 root root 30 Dec 22 2018 iptables-restore -> /usr/sbin/iptables-nft-restore lrwxrwxrwx 1 root root 27 Dec 22 2018 iptables-save -> /usr/sbin/iptables-nft-save Cheers! signature.asc Description: OpenPGP digital signature
Bug#930562: Not migrated to testing yet
Hello! Thanks a bunch for the fix to the libtrapperkeeper-webserver-jetty9-clojure package. I'm wondering though why the package hasn't migrated to testing (and stable) yet. This info is completely uninformative about the situation: https://qa.debian.org/excuses.php?package=trapperkeeper-webserver-jetty9-clojure I was under the impression that packages uploaded to unstable were migrated automatically to testing after a while.. was there maybe some delays imposed since this was uploaded not long after buster's release? .. also the package in buster is still buggy, so I guess at this point it would be nice to see a push to stable to fix the issue Cheers, and thanks again for your work on this, I really appreciate what you do! signature.asc Description: OpenPGP digital signature
Bug#930562: Not migrated to testing yet
On 2019-08-23 11:07 p.m., tony mancill wrote: > On Fri, Aug 23, 2019 at 04:44:07PM -0400, Gabriel Filion wrote: > From the PTS page [1], I see the excuse as: > [1] https://tracker.debian.org/pkg/trapperkeeper-webserver-jetty9-clojure > testing migrations > excuses: > - 38 days old (5 needed) > - Piuparts tested OK - > https://piuparts.debian.org/sid/source/t/trapperkeeper-webserver-jetty9-clojure.html > - Checking build-dependency on amd64 > - Not built on buildd: arch all binaries uploaded by apoi...@dmesg.gr > - Not considered > > Starting with buster, uploads must be source only and the binary > packages built on the buildds in order to migrate to testing. ah! I had looked at this list of reasons for non-migration, but I couldn't understand that there was anything wrong from that text (e.g. it's just stating that it wasn't built by buildd but it's not mentioning that this is the reason for the auto migration not happening, one has to know this extra information to understand the implications). thanks for the explanation! > I'll have a look at uploading a source package. many thanks! signature.asc Description: OpenPGP digital signature
Bug#929515: smokeping: CSS and js files not found
On Thu, 11 Jul 2019 10:21:08 +0200 =?UTF-8?B?SmnFmcOtIEp1xZlpY2E=?= wrote: > I think I solvedthe Keith's problem. I had same issue when I yesterday > installed smokeping and after I read that smokeping has apache config I > tried another url then before. Firstly I tried url > host.tld/cgi-bin/smokeping.cgi where paths to js and css are really broken > but when try host.tld/smokeping everything works fine. Ah! Thanks for this info, Jiří! I was able to reproduce now on a new buster install. And indeed, this is caused because the links to css are relative. Keith, you can fix the interface by using the url: http(s)://host.tld/smokeping/ I'll still think of a way to fix this conveniently. signature.asc Description: OpenPGP digital signature
Bug#925444: smokeping: --pid-dir doesn't worj as expected
On Sat, 6 Jul 2019 13:01:12 -0400 Gabriel Filion wrote: > On Tue, 2 Apr 2019 10:46:38 -0400 Gabriel Filion > wrote: > > On 2019-03-26 3:26 p.m., BERTRAND Joël wrote: > > >> Did you recently upgrade smokeping? if so what version were you > > >> using before? (maybe check your dpkg logs for signs of upgrade of > > >> the smokeping package) > > > Yes, I have. > > > > > > -> 2019-03-17 03:26:38 upgrade smokeping:all 2.7.2-3 2.7.3-2 > > If this bug is still affecting your install, could you paste the > contents of the file /lib/systemd/system/smokeping.service ? > > also, which version of systemd are you running? > > Normally there should be a line like the following that tells systemd to > create the /run/somkeping directory: > > RuntimeDirectory=smokeping Ah! one more question. Now that I've spent a bit more time fixing bugs and reading the upstream mailing list another variable comes up to my mind: Have you configured smokeping as as "slave" on the server where you're missing the pid file? From what I read[0], smokeping does not create a pid file when running in slave mode. [0]: https://github.com/oetiker/SmokePing/issues/44 signature.asc Description: OpenPGP digital signature
Bug#924285: ITP: vagrant-librarian-puppet -- A Vagrant plugin to install Puppet modules using Librarian-Puppet
Here's a little progress report since this ITP was created a little while ago: I've had some help this week-end on the ruby-team IRC channel to figure out how to create the git repository with the correct branches after sorting out some issues with gem2deb for this particular gem. So the work has started to look like something more concrete and I'll continue working out the remaining details in the coming weeks to remove lintian errors: https://salsa.debian.org/ruby-team/vagrant-librarian-puppet On Sun, 10 Mar 2019 20:41:21 -0400 Gabriel Filion wrote: > Package: wnpp > Severity: wishlist > Owner: Gabriel Filion > > * Package name: vagrant-librarian-puppet > Version : 0.9.2 > Upstream Author : Vox Pupuli > * URL : https://github.com/voxpupuli/vagrant-librarian-puppet > * License : MIT > Programming Lang: Ruby > Description : A Vagrant plugin to install Puppet modules using > Librarian-Puppet > > vagrant-librarian-puppet is a plugin for Vagrant that will automatically > run librarian-puppet before any provisioning step. It looks for a > Puppetfile in the configured directory and uses that file with > librarian-puppet. > > More details: > - This plugin automates management of module dependencies when testing >puppet modules, or simply when maintaining your local test VM for >day-to-day puppet development. I removes the need to remember to >install new modules with librarian-puppet after having pulled in >other people's changes on the Puppetfile. > - It is not a dependency for another package > - I so far use it for testing individual puppet modules that I >maintain, and to make it easier to test changes before committing. I >also intend to use it at work to reduce friction around keeping >modules up to date in the local dev VMs. > - I don't know of another package that provides such functionality. >It's also the only vagrant plugin that I know can help automate this. > - Since I'm not a DD or a DM, I am planning on asking a friend who is >a Debian Developer to help me out with shaping the package so that >it's acceptable for debian. I would then intend to ask the ruby >packaging team if they are willing to make this one of the team >packages and I would continue maintaining it through the team. > > signature.asc Description: OpenPGP digital signature
Bug#995567: Can't handle cross-signed Let's Encrypt CA
Upstream hasn't yet made a release that includes the fix. Since this is currently affecting the software on certain hosts and making it impossible to connect to hosts using Let's Encrypt certificates (we're seeing this problem with a production host), I'm wondering if the patch could be included in the debian package in the curent package releases.
Bug#1004308: smokeping: New upstream version 2.8.2 needs to be packaged
Package: smokeping Severity: normal Upstream has released a new version of smokeping, 2.8.2 and it would be helpful to upgrade the debian package to this version since it contains a number of fixes, some of which would remove patches in the package. I've received two emails directly requesting the new version so I'm creating this bug report to reflect their wish to have this version. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages smokeping depends on: ii adduser 3.118 ii debianutils 5.5-1 pn fping pn libcgi-fast-perl pn libconfig-grammar-perl ii libdigest-hmac-perl 1.04+dfsg-1 pn libjs-cropper pn libjs-prototype pn libjs-scriptaculous ii librrds-perl1.7.2-4 pn libsnmp-session-perl ii liburi-perl 5.10-1 ii libwww-perl 6.60-1 ii lsb-base11.1.0 ii perl5.32.1-6 ii postfix [mail-transport-agent] 3.6.3-5 ii ucf 3.0043 Versions of packages smokeping recommends: pn apache2 | apache2 | httpd pn apache2 | httpd-cgi ii bind9-dnsutils [dnsutils] 1:9.17.22-1 ii dnsutils 1:9.17.21-1 pn echoping ii libsocket6-perl0.29-1+b3 Versions of packages smokeping suggests: ii curl 7.81.0-1 pn libauthen-radius-perl ii libio-socket-ssl-perl 2.074-2 ii libnet-dns-perl1.33-1 pn libnet-ldap-perl pn libnet-telnet-perl ii openssh-client 1:8.7p1-4
Bug#995952: undertime: Getting TypeError with any timezone
Package: undertime Version: 2.6.0 Severity: grave Justification: renders package unusable Hello, I'm currently getting stack traces consistently when using undertime. No matter the timezone that I request, I get a stack trace with a TypeError exception: $ undertime pt Traceback (most recent call last): File "/usr/bin/undertime", line 994, in main(args) File "/usr/bin/undertime", line 733, in main timezones += filter(None, [guess_zone(z) for z in args.timezones]) TypeError: 'NoneType' object is not iterable $ undertime PST WARNING: date provided cannot be parsed: PST Traceback (most recent call last): File "/usr/bin/undertime", line 994, in main(args) File "/usr/bin/undertime", line 733, in main timezones += filter(None, [guess_zone(z) for z in args.timezones]) TypeError: 'NoneType' object is not iterable If I run that last command with pdb, e.g. python3 -m pdb /usb/bin/undertime PST and then (r)un the program until the error, I can see that args.timezones is set to None: (Pdb) type(args.timezones) now from there, I tried using "undertime -t PST" and that actually worked. So there must be something off with the default value to -t -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages undertime depends on: ii python3 3.9.2-3 ii python3-dateparser 1.0.0-1 ii python3-ephem 4.1-1 ii python3-tabulate0.8.7-0.1 ii python3-termcolor 1.1.0-3 ii python3-tz 2021.3-1 ii python3-yaml5.3.1-5 undertime recommends no packages. undertime suggests no packages. -- no debconf information
Bug#906444: vagrant: New upstream version 2.1.2 available
Package: vagrant Version: 2.0.2+dfsg-3 Severity: normal Hello, There is currently a new version available upstream, 2.1.2. It would be nice to have access to this version in debian sid, and potentially soon afterwards in buster. The 2.1.x branch adds some interesting features like triggers for performing an action when something is done to a particular VM in a project. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vagrant depends on: ii bsdtar 3.2.2-3.1 ii curl 7.60.0-2 ii openssh-client 1:7.7p1-2 ii ruby 1:2.5.1 ii ruby-childprocess 0.5.9-1 ii ruby-erubis2.7.0-3 ii ruby-i18n 0.7.0-2 ii ruby-listen3.1.5-1 ii ruby-log4r 1.1.10-4 ii ruby-net-scp 1.2.1-5 ii ruby-net-sftp 1:2.1.2-4 ii ruby-net-ssh 1:4.2.0-2 ii ruby-rest-client 2.0.2-3 Versions of packages vagrant recommends: ii vagrant-libvirt 0.0.43-2 Versions of packages vagrant suggests: pn virtualbox -- no debconf information
Bug#905752: smokeping: FPing target supports and prefers IPv6, preventing IPv4 pings
tags 905752 + upstream forwarded 905752 https://github.com/oetiker/SmokePing/issues/95 thanks Hi there, On 2018-08-08 08:49 PM, Mark Kamichoff wrote: > It appears that as of 3.16, FPing is no longer a multi-call binary and > /usr/bin/fping and /usr/bin/fping6 act the same. This ultimately > prevents the FPing probe from working properly because if a target with > both A & records is used, FPing prefers the record and > initiates a ping using IPv6 and not IPv4, which is not the intention. > The FPing probe does not support an address-family option to pass -4 or > -6 to the FPing binary so there is no way to force IPv4 name resolution. > As a result, there is no way of adding dual-stack targets to be probed > over IPv4. it appears as though this was already reported upstream: https://github.com/oetiker/SmokePing/issues/95 The bug report does have a workaround: writing wrapper scripts that add the -4 or -6 parameters to the fping binary. In order to support this without the wrapper scripts, I believe a patch to the FPing.pm and FPing6.pm probe files would need to be written to add some option that can trigger adding the appropriate flags for forcing fping to use a certain protocol. I would help out with creating such a patch but I unfortunately have no IPv6 to test it out :\ Cheers signature.asc Description: OpenPGP digital signature
Bug#824712: RFH: smokeping
Hi there! I've been doing some work on the smokeping package in the past few weeks/months with anarcat. Namely, * a new upstream release was packaged and sent to experimental, and we're trying to get it into sid very soon. * I've written and submitted a patch upstream in response to a bug report in the BTS to make smokeping work better with newer versions of FPing (3.16+). It should make it so that the FPing probes doen't mix up IPv4 and IPv6 anymore with the recent versions of fping. This should land in a package real soon (it was merged upstream today) Future work that I intend to do is to get rid of as many lintian errors as possible, and then start working on the currently present bug reports in the BTS (from the easiest first). It is an invaluable learning experience for me since I'm new to debian packaging. Anarcat has marked myself as package maintainer, and I intend to continue work on the package. However, I'm not closing the door to collaboration with the Internet Measurement Packaging Team as was suggested by Iain. For now, pull requests on the git repository in salsa would be great, until I can feel more confident about how the package is holding things together. Cheers! signature.asc Description: OpenPGP digital signature
Bug#860264: Acknowledgement (nfs-kernel-server: NFS starts before DNS works, "exportfs: Failed to resolve ...")
Hi! I'm currently experiencing the exact same issue with an NFS mount for /home, and another nfs mount (from another server) that gets mounted under /srv/something: at boot, nfs mount times out, and afterwards when the boot is complete, if I ssh in and execute "mount -a" as root the mount points become available. On Mon, 17 Apr 2017 09:19:59 -0400 Greg Wooledge wrote: > wooledg:~$ systemctl list-dependencies network-online.target > network-online.target > * `-networking.service > > wooledg:~$ cat /lib/systemd/system/networking.service > [...] > [Service] > Type=oneshot > EnvironmentFile=-/etc/default/networking > ExecStartPre=-/bin/sh -c '[ "$CONFIGURE_INTERFACES" != "no" ] && [ -n > "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm settle' > ExecStart=/sbin/ifup -a --read-environment This seems to be problematic.. unfortunately if I understand correctly "allow-hotplug" is meant to make it possible to have the network interface be configured dynamically whenever it appears. So it might be useful for network interface dongles ... but if I try to reason why debian's installer configures interfaces as "allow-hotplug" by default, I would guess that it might also be useful for laptops that have wifi on/off physical switches to disable/enable the interface. I'm wondering why physical interfaces (previously known as ethN) would require this instead of using "auto", though.. Also just to add at least one data point that's more closely relevant to the paragraph above: the unit file for network-online.target is still the same in sid now, so the issue still exists! I'm not sure what would be the correct solution for this to avoid requiring ppl to manually change the definition of their interface when they want to use a mount point at boot that requires networking :\ signature.asc Description: OpenPGP digital signature
Bug#860264: Acknowledgement (nfs-kernel-server: NFS starts before DNS works, "exportfs: Failed to resolve ...")
On Sat, 1 Sep 2018 03:16:34 -0400 Gabriel Filion wrote: > > wooledg:~$ cat /lib/systemd/system/networking.service > > [...] > > [Service] > > Type=oneshot > > EnvironmentFile=-/etc/default/networking > > ExecStartPre=-/bin/sh -c '[ "$CONFIGURE_INTERFACES" != "no" ] && [ -n > > "$(ifquery --read-environment --list --exclude=lo)" ] && udevadm settle' > > ExecStart=/sbin/ifup -a --read-environment > > This seems to be problematic.. unfortunately if I understand correctly > "allow-hotplug" is meant to make it possible to have the network > interface be configured dynamically whenever it appears. So it might be > useful for network interface dongles ... but if I try to reason why > debian's installer configures interfaces as "allow-hotplug" by default, > I would guess that it might also be useful for laptops that have wifi > on/off physical switches to disable/enable the interface. > > I'm wondering why physical interfaces (previously known as ethN) would > require this instead of using "auto", though.. I've just tested changing "allow-hotplug enp0s25" to "auto enp0s25" as suggested by Greg as a workaround. Then I've rebooted the machine multiple times and I ended up seeing the problem again. So I believe that this workaround does not fix the issue after all. the bug lies somewhere else :\ is it possible that "udevadm settle" is the command that gets stuck sometimes? signature.asc Description: OpenPGP digital signature
Bug#908674: smokeping: fping is executed with a nonexistent argument
Hello Eduardo, On 2018-09-12 2:47 p.m., Eduardo Barros wrote: > after installing smokeping on a updated system i couldn't get it to print the > graphs with multiple targets and a "step=10" and "pings=10" on > /etc/smokeping/config.d/Database. > got this log: > "FPing: WARNING: smokeping took 27.0296120643616 seconds to complete 1 round > of polling. It should complete polling in 10 seconds. You may have > unresponsive devices in your setup." > the fping process was run as this command "/usr/bin/fping -C 10 -q -B1 -r1 - > -i10 localhost" > as we an see, after the "-r1" argument and before the "-i10" there is a minus > without an argument. > that minus appears as well on the fping command on a default installation. > on my system the command takes 27 seconds to be executed with that minus and > with the error "-: Name or service not known". > without the minus it takes only 9 seconds. oops! thanks for the bug report! I think I can see what's going wrong: the upstream patch that was accepted after the most recent version of the package was pushed also adds a default value for the new protocol parameter. I think this should fix the behaviour you're seeing. I'll update the patch that's currently deployed and send this in. in the meantime if you'd like to have a functional FPing probe, you could something like add this to your definitions in config.d/Probes: --- Probes.orig 2018-09-19 15:36:29.703560212 + +++ Probes 2018-09-19 15:36:39.035534800 + @@ -3,4 +3,5 @@ + FPing binary = /usr/bin/fping +protocol = 4 ... and if you also have IPv6 probes, you can add "protocol = 6" instead. those two values should be the defaults for the FPing and FPing6 probes, respectively. signature.asc Description: OpenPGP digital signature
Bug#891677: postfixadmin: New upstream release: 3.1
Package: postfixadmin Version: 3.0.2-2 Severity: normal Hello, A new release of postfix admin happened in june 2017 : 3.1. It would be nice to package this version in sid/testing Also, the code was officially (so I was told by cboltz on the #postfixadmin irc channel on freenode) moved to github now: https://github.com/postfixadmin/postfixadmin -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE=en_CA:en (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages postfixadmin depends on: ic apache2 [httpd] 2.4.25-3 ii dbconfig-common 2.0.8 ii debconf 1.5.61 ii default-mysql-client1.0.2 ii nginx-full [httpd] 1.10.3-1+deb9u1 ii php-fpm 1:7.0+49 ii php-imap1:7.0+49 ii php-mbstring1:7.0+49 ii php-mysql 1:7.0+49 ii php7.0-fpm [php-fpm]7.0.19-1 ii php7.0-imap [php-imap] 7.0.19-1 ii php7.0-mbstring [php-mbstring] 7.0.19-1 ii php7.0-mysql [php-mysqlnd] 7.0.19-1 ii wwwconfig-common0.3.0 Versions of packages postfixadmin recommends: ii dovecot-core1:2.2.27-3+deb9u1 ii mariadb-server 10.1.26-0+deb9u1 ii mariadb-server-10.1 [virtual-mysql-server] 10.1.26-0+deb9u1 ii php7.0-cli [php-cli]7.0.19-1 ii postfix-mysql 3.1.6-0+deb9u1 pn zendframework postfixadmin suggests no packages. -- debconf information: postfixadmin/internal/reconfiguring: false * postfixadmin/db/app-user: postfixadmin@localhost * postfixadmin/database-type: mysql * postfixadmin/dbconfig-reinstall: true postfixadmin/upgrade-backup: true postfixadmin/purge: false * postfixadmin/reconfigure-webserver: * postfixadmin/db/dbname: postfixadmin * postfixadmin/mysql/admin-user: debian-sys-maint postfixadmin/dbconfig-remove: postfixadmin/upgrade-error: abort postfixadmin/pgsql/admin-user: postgres postfixadmin/pgsql/manualconf: postfixadmin/missing-db-package-error: abort * postfixadmin/mysql/method: Unix socket postfixadmin/internal/skip-preseed: false postfixadmin/pgsql/authmethod-user: password postfixadmin/pgsql/changeconf: false postfixadmin/db/basepath: postfixadmin/remote/newhost: postfixadmin/pgsql/authmethod-admin: ident postfixadmin/pgsql/method: TCP/IP postfixadmin/dbconfig-upgrade: true postfixadmin/remote/port: * postfixadmin/dbconfig-install: true postfixadmin/remove-error: abort postfixadmin/pgsql/no-empty-passwords: postfixadmin/remote/host: localhost postfixadmin/passwords-do-not-match: * postfixadmin/install-error: ignore
Bug#892069: puppet-lint: rake task only runs lint on modules inside spec/fixtures
Package: puppet-lint Version: 2.3.3-1 Severity: normal Hello! I was trying to use puppet-lint from this package to run lint as a rake task to automate tests, and I found out that it would only run the lint checks on .pp files inside modules present in spec/fixtures/modules/* If I set the task's configuration to ignore some paths, it does not change anything. In my Rakefile I have: require 'puppet-lint/tasks/puppet-lint' PuppetLint.configuration.ignore_paths = ["spec/**/*.pp", "vendor/**/*.pp", "pkg/**/*.pp"] I've found out that configuration being ignored was already reported upstream: https://github.com/rodjek/puppet-lint/commit/0f2e2db90d5a14382eafbdfebff74048a487372f However, the fix in that commit is already present in the code deployed by the debian package. If I use the workaround proposed as a comment on that commit (instead of the above line starting with "PuppetLint.configuration"), then the lint checks run as expected with the ignored paths set as I want them: Rake::Task[:lint].clear PuppetLint::RakeTask.new :lint do |config| config.ignore_paths = ["spec/**/*.pp", "vendor/**/*.pp", "pkg/**/*.pp"] end So there must be something in the puppet-lint code that that makes it ignore configuration set in the Rakefile, but I'm not proficient enough in ruby to debug where this is happening. Cheers -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.utf8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages puppet-lint depends on: ii ruby 1:2.5~1 puppet-lint recommends no packages. Versions of packages puppet-lint suggests: ii rake 12.3.0-1 -- no debconf information
